@takeda_h です。地方自治体のガバメントクラウドに関わる仕事をしています。オンプレミスのネットワーク基盤は少し分かるのですが、パブリッククラウドにはこれまで業務でほとんど触れたことがなく、プライベートで少し触る程度でした。今回ガバメントクラウドで AWS を使わざるを得なくなってしまい、なんとか乗合バスに遅れまいと必死に勉強しているところです。
しかし、AWS のネットワークの部分でいまいちピンと来ないこともあり、これは実際に手を動かして環境を作ってみた方が早く理解できるのでは？と思い、個人の AWS アカウントで色々ネットワークの検証をやってブログにいくつか記事を書いてきました。
同じような状況の方もいるかもしれないので、何かの参考になるかもと思い、今回アドベントカレンダーの機会を使わせてもらってこれらのブログ記事をまとめて紹介したいと思います。
本記事は ガバメントクラウド Advent Calendar 2024 の 9 日目の投稿となります。
さて、地方自治体が使うガバメントクラウド環境は、主に住民情報を扱う基幹業務システムが運用されるため、基本的に閉域ネットワークの中で運用することになります。
そのため、ガバメントクラウド環境として AWS を利用する場合、プライベートサブネットのみの VPC と地方自治体の庁内オンプレミス環境を Direct Connect で接続して使うことになり、VPC のリソースがインターネットへアクセスできる通常の環境と比べて、特にネットワーク周りで考慮しなければならないポイントがいくつかあります。
具体例を挙げてみます。
- 別の VPC のリソースにアクセスするには、Transit Gateway または VPC ピアリングで VPC 間をルーティングするか、PrivateLink でサービスを開放してもらう
- VPC にグローバル IP アドレスがないため、AWS の各サービスにアクセスするためには VPC エンドポイントが必要
- VPC のリソースから S3 にアクセスするにはゲートウェイエンドポイントを使えるが、オンプレミスや別リージョンの VPC リソースから S3 にアクセスするにはインターフェイスエンドポイントが必要
- オンプレミスから AWS 環境の名前解決をするためには、Route 53 インバウンドエンドポイントを使うのが効率的
- VPC 間で プライベートな DNS レコードの名前解決をを共有するには、Route 53 プライベートホストゾーンを VPC 間で関連付けるのが効率的
- etc
しかも、地方自治体のガバメントクラウド環境では、同一の地方自治体の環境の中でシステムごとに別のベンダーが環境を運用管理することもあり、複数の AWS アカウント（マルチアカウント）にある複数の VPC 同士を閉域で接続することも多々あります。
言ってしまえば AWS で泥臭いインフラの調整が要る場面は意外とあります。
一方でデジタル庁から出ているリファレンスではどうなっているかというと、デジタル庁 Web サイト 地方公共団体の基幹業務システムの統一・標準化 > ガバメントクラウドへの移行に向けた検証 の中に「ガバメントクラウド利用における推奨構成」があるのですが、内容を見ると SaaS をイメージしているのか、現場の実態とは少し離れた構成例になっており、正直あまり参考になりませんでした（個人の意見です）。
そこで、マルチアカウントでかつ閉域網として AWS を使う場合に頻出となる、ネットワーク周りの考慮ポイントのいくつかを、実際に検証してみて紹介したいと思います。
Transit Gateway でマルチアカウントの VPC 同士を相互接続
まずは VPC 同士をルーティングできるようにするのが一番手っ取り早いので、Transit Gateway (TGW) で VPC を繋いでみました。
TGW と VPC を結ぶ TGW アタッチメントに料金がかかるのですが、PrivateLink よりもシンプルな形で VPC をネットワーク接続できるので、複数のサービスを VPC 間で連携するのであれば TGW の方が良いと思っています。なお、VPC ピアリングの方が料金は安いですが、VPC ピアリングは推移的ルーティングをサポートしていないため、相互接続する VPC が多くなると接続が複雑になるためお勧めできません。
マルチアカウントで TGW を使う時のポイントは、TGW を作るアカウントから共有したいアカウントに対して、Resource Access Manager (RAM) で TGW を共有すること、別アカウントからの TGW アタッチメントの接続には承認が要ることで、共有するアカウント間で互いに操作が必要になることです。他ベンダー同士の AWS アカウント間で TGW と接続する作業は、同じタイミングで互いに連絡を取り合いながら作業するとスムーズかと思います。
Route 53 プライベートホストゾーンとインバウンドエンドポイントを複数 VPC 間で共有
AWS 環境では名前解決がとても重要で、Route 53 を使うのが効率的です。また、地方自治体のガバメントクラウド環境のように、閉域オンプレミス環境から AWS 環境のリソースを名前解決してアクセスさせるには、Route 53 インバウンドエンドポイントを立てるのがお勧めです。
また、複数 VPC 間でプライベートな DNS レコードの名前解決を共有したい場面も多いと思いますが、この場合、Route 53 プライベートホストゾーンを VPC に関連付けることで実現できます。
そこで、複数の VPC のうちの一つに Route 53 インバウンドエンドポイントを立てて、この VPC に他の VPC のプライベートホストゾーンを関連付けることで、複数の VPC 間でプライベートホストゾーンを共有する方法を検証してみました。
なお、これは事前に VPC 同士が TGW などでルーティング可能となっており、Route 53 インバウンドエンドポイントへアクセスできることが前提となっています。
VPC エンドポイントを複数 VPC 間で共有
プライベートサブネットのリソースから AWS の各サービスにアクセスするには、NAT Gateway を介するなどの方法がありますが、地方自治体の基幹業務システムのあるプライベートサブネットに NAT Gateway を置くことはできないため、VPC エンドポイント経由でアクセスするしかありません。
ここで、検証用に作った VPC も同様であるため、VPC 内の EC2 などにアクセスするには Direct Connect 経由でなければならないのですが、さすがに個人で DX は無理なので、Systems Manager の Session Manager (SSM) で EC2 へアクセスすることにしました。
残念ながらガバメントクラウド環境では SSM は使えないのですが、個人の検証用閉域 VPC にアクセスするには簡単で使いやすいサービスです。
話を戻すと、VPC エンドポイントを各 VPC に作ると、その分費用がかかってしまいます。そこで、前述の Route 53 インバウンドエンドポイントと同様に、ひとつの VPC にエンドポイントを作成し、他の VPC からこのエンドポイントにアクセスする方法を検証しました。
検証では一つの VPC に SSM のエンドポイントを作成し、別の VPC からアクセスさせることで、別の VPC には SSM のエンドポイントを作らなくても SSM が使えることを確認しています。
S3 のゲートウェイエンドポイントとインターフェイスエンドポイント
ガバメントクラウドで地方自治体の基幹業務システムはオブジェクトストレージでデータ連携をする場面があるため、AWS だと S3 を使うことが多いと思います。
プライベートサブネットからの S3 へのアクセスには、ゲートウェイエンドポイントかインターフェイスエンドポイントのいずれかを経由してアクセスする必要がありますが、それぞれのエンドポイントのメリットデメリットを考えながら検証してみました。
費用はゲートウェイエンドポイントの圧勝（無料）なのですが、インターフェイスエンドポイントを使うとセキュリティグループでアクセス制限できるなどの利点がありました。
実際に AWS 環境を作ってやってみた感想
理解は深まるも新たな課題も見つかる
ドキュメントを読んだだけだといまいちピンと来ていなかった部分も、実際に動く所を見るとしっくりきました。やはり自分にとっては手を動かすのが一番理解の助けになりました。
また、これらの構成の中で、Route 53 のインバウンドエンドポイントのようなものはコストを削減するために集約できそうに思える一方、運用の責任分界点などの問題から、複数のベンダーが運用管理する環境間では集約ができないと言われてしまう部分もありそうだと分かり、新たな課題感もありました。単独利用方式で地方自治体が AWS 環境をコントロールしているような所は複数ベンダーでもこういった調整はできそうですが、多くの地方自治体はそうではないと思われます。
検証を自分でやってみる難しさ
ただ、実際に検証をやってはみましたが、検証には多少のお金がかかりますし、設定を誤ると高額な請求が来てしまうリスクもあり、誰にでも勧められるものではありません。自分もこれまでのオンプレミスでの経験と、多少でも AWS に触ったことがあったから、今回も大した内容ではありませんが何とかやれたと思っていて、そうではない方にとっては少しハードルが高いかもしれません。
本来は業務としてこういった検証を、できれば AWS を分かる方の援助を得ながらやれるのがベストですが、中々そうもいかないと思います（特に地方自治体は）。
そこで、ハンズオンの機会があればぜひやってみることをお勧めします。例えば、地方自治体の職員の方なら、地方公共団体の経営・財務マネジメント強化事業 でアドバイザーの派遣を受けることができるのですが、アドバイザーの一人であるヴイエムウェア株式会社の中島淳之介氏は、多くの自治体でハンズオンを含むガバメントクラウドに関わる支援を行っており、もしかしたら相談に乗ってもらえるかもしれません（支援の内容は 自治体システム標準化・ガバメントクラウド勉強会 の中島さんの講演資料を参照）。
おわりに
ベンダーの方、地方自治体の方、その他いろいろな立場でガバメントクラウドに関わる方も多いと思いますが、この難局を乗り越える一助に本記事がなれば幸いです。ここまでお読みいただきありがとうございました。