自治体職員だけど AWSのネットワーク分からなすぎて カッとなって個人で環境作って試してみた話 Route 53インバウンドエンドポイントとプライベートホストゾーンの集約を例に 第4回 自治体システム標準化・ガバメントクラウド勉強会 2024/12/18 

今日お話ししたいこと 2 ⚫ ガバメントクラウドでAWSを使う場合、閉域ならではのネットワークの難し さってありますよね？ ⚫ 難しさについカッとなったので、個人AWSアカウントで環境作って試してブ ログ書いてたところ、「せっかくだから発表しませんか？」と言われてホイホ イこの場に来ました。 

今日お話ししたいこと 3 ⚫ 具体的に、Route 53による名前解決（DNS）を例に挙げて、オンプレミス の庁内ネットワークとAWS環境との名前解決の連携やネットワークの仕組み を解説します。 ⚫ 解説するのは、ほぼ知識ゼロのところからガバクラ担当になったためにイチ から勉強する羽目になったとある自治体職員ですので、どうぞお気軽に聴い てください！ 

今日お話ししたいこと 4 この後、みのるんさん（@minorun365）、名古屋市の高橋名人、GovTech 東京のすぎいさんによる、ガバクラのAWSネットワーク周りについてのパネル ディスカッションがありますので、お楽しみに！ 

自己紹介 5 だれ？ 北海道の某自治体の情シス部門の人 経歴 入庁18年目、情シス部門通算10年目 オンプレミスのネットワークはそれなりに経験あり パブリッククラウドはプライベートで少し触ったことが ある程度 →オンプレおじさん舐めるなの精神で勉強中 保有資格 情報処理安全確保支援士試験 ネットワークスペシャリスト AWS Certified Solutions Architect – Associate AWS Certified Advanced Networking – Specialty 令和のクラウドという乗合バスに乗る私 （Grokで出力したイメージです） 

ガバメントクラウドでのAWSのネットワーク周辺の難しさ 6 ガバメントクラウドでAWSを使う場合、以下の難しさがあると思ってます。 ⚫ パブリッククラウドなのに閉域内で使わなければならない ⚫ 同じく閉域の庁内ネットワークと連携しなければならない ⚫ 複数のシステムやベンダーが関わるケースで、異なるAWSアカウント間で 連携しなければならない場合がある 

ガバメントクラウドでのAWSのネットワーク周辺の難しさ 7 ⚫ 閉域内でのAWSの使い方は、インターネット接続を前提とした一般的な使 い方に比べて、ネット上でも解説記事があまり多くない印象 ⚫ そのため自治体職員がいちから勉強するのも一苦労…… 

そこで実際にAWSのネットワークを構築して試してみた 8 じゃあAWSに環境を構築して試した方が理解が深まるのでは？と思い、個人 のAWSアカウントで閉域ネットワーク周辺の検証をやってみました。その中か ら、ネットワークの中でも特に重要な名前解決（DNS）について、Route 53を 使って解説してみます。 ガバメントクラウドを想定したマルチアカウント間の Route 53 プライベートホストゾーンとインバウンドエンドポイントの共有について https://takeda-h.hatenablog.com/entry/2024/11/22/013529 

ガバメントクラウドでのRoute 53の名前解決のポイント 9 ガバメントクラウド環境でも、独自ドメインを使ってサーバーなどのリソースの 名前をDNSで管理したい場合はあると思います。このとき、閉域AWSの名前 解決には次のような課題があります。 

ガバメントクラウドでのRoute 53の名前解決のポイント 10 ⚫ オンプレミスの庁内ネットワークからもAWS上のリソースの名前解決が必要 ⚫ EC2など自分達が管理するサーバーのリソースだけでなく、AWSが管理す るマネージドサービスなどのエンドポイントの名前解決も必要 ⚫ そのため、自前でAWS側にDNSサーバーを立てて管理するのは負荷が大 き過ぎる 

ガバメントクラウドでのRoute 53の名前解決のポイント 11 これらの課題を解決するには、Route 53インバウンドエンドポイントと、プラ イベートホストゾーンを使うことが推奨されます。 Route 53 プライベートホストゾーン 閉域内からのみ名前解決させたいDNSレコードを登録できる仕組み。 Route 53 インバウンドエンドポイント VPCに関連付けたプライベートホストゾーンやAWSのマネージドサービスなど をVPCの外から名前解決させるためのエンドポイント。エンドポイントのIPアド レスに名前解決要求を投げると解決してくれる。 

ガバメントクラウドでのRoute 53の名前解決のポイント 12 ⚫ Route 53プライベートホストゾーンにAWS環境上で使用したいホスト名をDNSレコード として登録し、VPCに関連付ける。 ⚫ Route 53インバウンドエンドポイントをVPCに設置し、庁内ネットワークにいるクライアン トからオンプレミスのDNSサーバーに対する、AWS環境上で使用する特定のドメインに対 する名前解決要求をエンドポイントへ転送（条件付きフォワーダ）させる。 インバウンドエンドポイントのあるVPCに関連付けたプライベートホストゾーンのレコードを VPCの外から名前解決できるようになる。→文字だと分かりづらいので図を見てみましょう 

13 AWS Account 1 VPC Route 53 Private subnet (10.1.0.0/24) EC2 Private Hosted zone R53 Inbound Endpoints ホスト名 IPアドレス ap1.gov1.intra.city.hoge.hokkaido.jp 10.1.0.1 db1.gov1.intra.city.hoge.Hokkaido.jp 10.1.0.2 TGW Route 53 Private Hosted zone ホスト名 IPアドレス ap1.gov2.intra.city.hoge.hokkaido.jp 10.2.0.1 db1.gov2.intra.city.hoge.Hokkaido.jp 10.2.0.2 VPCにホストゾーンを関連付け VPCにホストゾーンを関連付け AWS Account 2 VPC Private subnet (10.2.0.0/24) EC2 Direct Connect DXGW Customer gateway NaaS Router NaaS Router NaaS拠点 庁舎ネットワーク DNS Server Client gov1.intra.city.hoge .hokkaido.jp の名前 解決要求をR53インバウ ンドエンドポイントへ転送 する R53 Inbound Endpoints gov2.intra.city.hog e.hokkaido.jp の名前 解決要求をR53インバウ ンドエンドポイントへ転送 する 

VPCごとにR53インバウンドエンドポイントを置くと…… 14 ⚫ Route 53インバウンドエンドポイントは利用料金が高額なため、VPCごと にエンドポイントを置いてしまうとコストが高くなる。 ⚫ オンプレミスのDNSサーバーからAWS上のドメインに対する条件付きフォ ワーダをエンドポイントの数だけ設定する必要があり、管理の手間が増える。 エンドポイントを一つのVPCのみに置き、他のVPCやオンプレミスからは当該 エンドポイントのみを参照するようにすれば効率的。 

15 AWS Account 1 VPC Route 53 Private subnet (10.1.0.0/24) EC2 Private Hosted zone R53 Inbound Endpoints ホスト名 IPアドレス ap1.gov1.intra.city.hoge.hokkaido.jp 10.1.0.1 db1.gov1.intra.city.hoge.Hokkaido.jp 10.1.0.2 TGW Route 53 Private Hosted zone ホスト名 IPアドレス ap1.gov2.intra.city.hoge.hokkaido.jp 10.2.0.1 db1.gov2.intra.city.hoge.Hokkaido.jp 10.2.0.2 VPCにホストゾーンを関連付け AWS Account 2 VPC Private subnet (10.2.0.0/24) EC2 Direct Connect DXGW Customer gateway NaaS Router NaaS Router NaaS拠点 庁舎ネットワーク DNS Server Client Gov[1|2].intra.city. hoge.hokkaido.jp の 名前解決要求をR53イ ンバウンドエンドポイント へ転送する R53インバウンドエンド ポイントのあるVPCにプ ライベートホストゾーンを 関連付ける EC2などからのDNSの 参照先をTransit Gatewayで接続した別 のVPCのR53インバウ ンドエンドポイントに向け る。 

R53インバウンドエンドポイントをまとめる利点 16 ⚫ DNSの参照先を一つにまとめられるので、管理しやすい。 ⚫ 複数アカウントでプライベートホストゾーンを管理している場合も、各アカウ ント側でプライベートホストゾーンをメンテナンスできる。→マルチベンダで インバウンドエンドポイントを共有する時に作業責任範囲を分解しやすい（と 思う）。 

17 AWS Account 1（事業者Aが管理するアカウント） VPC Route 53 Private subnet (10.1.0.0/24) EC2 Private Hosted zone R53 Inbound Endpoints ホスト名 IPアドレス ap1.gov1.intra.city.hoge.hokkaido.jp 10.1.0.1 db1.gov1.intra.city.hoge.Hokkaido.jp 10.1.0.2 TGW Route 53 Private Hosted zone ホスト名 IPアドレス ap1.gov2.intra.city.hoge.hokkaido.jp 10.2.0.1 db1.gov2.intra.city.hoge.Hokkaido.jp 10.2.0.2 VPCにホストゾーンを関連付け AWS Account 2（事業者Bが管理するアカウント） VPC Private subnet (10.2.0.0/24) EC2 Direct Connect DXGW Customer gateway NaaS Router NaaS Router NaaS拠点 庁舎ネットワーク DNS Server Client インバウンドエンドポイン トは事業者A側にあるが、 事業者Bは自アカウント のプライベートホスト ゾーンにDNSを登録す れば全体で名前解決でき るようになる。 

その他のAWSのネットワーク周辺にも目を向けてみよう 18 ⚫ 今日はお話ししませんが、Route 53以外にも、S3のインターフェイスエン ドポイントやその他のVPCエンドポイントを一つに集約できる場合もあるの で、気にしてみてみましょう。 

最後に注意点 19 ⚫ VPCエンドポイントの集約など、効率的ではありますが、例えばマルチベン ダーでガバメントクラウド環境を運用しているケースでは、責任分界点の問 題から、集約はできないケースもあると思います。 ⚫ AWS利用料の削減よりも、ベンダーの保守のやりやすさの観点が重要な場 合もあると思います。この場合、敢えて集約しない方がトータルの保守コスト がかからないこともあるかもしれません。（要はケースバイケース。） 

ご清聴ありがとうございました 20 ⚫ AWSのネットワークに限らず、ガバメントクラウド・標準化は大変なことが多 いですが、みんなでこの難局を乗り越えましょう。 ⚫ 自治体職員の方へ……ついカッとなって自分でAWS触るのは正直お勧めし ません（誤ったメッセージになりませんように）。勉強方法は、例えばアドバイ ザーの派遣を受けたり、信頼できる事業者の方に相談したり、色々あります ので、どうか気負わずに一緒にがんばりましょう！