地方自治体が使うガバメントクラウドの内、AWS で構築する環境については、本番環境アカウント、検証環境アカウント、ネットワークアカウントなど、複数の AWS アカウントで運用されることが多く、特に一つの自治体が複数のベンダ（マルチベンダ）に AWS 環境を構築してもらう場合、一つの自治体の AWS 環境の中に複数のアカウント（マルチアカウント）が運用されることは珍しくありません。
ここで、AWS 環境での名前解決には Route 53 を使うことが一般的で、地方自治体がガバメントクラウドとして AWS 環境の名前解決（DNS）を考える時は、閉域ネットワークであるという特性上、オンプレミス（庁内ネットワーク）と AWS 環境の DNS の連携のため、VPC にインバウンドエンドポイントを置くことがほぼ必須となります。
また、マルチベンダの場合、各アカウントの運用管理補助者となるベンダが異なるため、Route 53 のプライベートホストゾーンは各アカウント側で管理したいという要望もあると思います。
プライベートホストゾーンを各アカウントで管理してもそこまで AWS の料金はかかりませんが、インバウンドエンドポイントの料金はそこそこいいお値段（エンドポイント 1 つにつき 1 時間当たり 0.125USD。1 ドル 160 円とすると 1 か月で約 90 USD = 14,400 円。エンドポイントは最低 2 個以上要るので 28,800 円程度。）となります。そのため、庁内ネットワークからの名前解決のために各アカウントの VPC でそれぞれ Route 53 のインバウンドエンドポイントを置くとすると、コストがかかってしまいますし、管理工数もばかになりません。
そこで、ガバメントクラウドのような閉域の AWS 環境でかつマルチアカウント運用の名前解決を考える場合で、マルチアカウントの VPC 間が Transit Gateway などでネットワークが繋がっている場合は、以下のような Route 53 の運用が効率的かと思います。
- Route 53 インバウンドエンドポイントは、各 VPC と相互接続する共通用 VPC にのみ設置し、庁内ネットワーク及び各 VPC からはルーティングで Route 53 インバウンドエンドポイントにアクセスさせる。
- 各アカウントで管理するプライベートホストゾーンは、上記の共通用 VPC に関連付けし、共通用 VPC の Route 53 インバウンドエンドポイントで名前解決できるようにする。
この Route 53 の設定を試すため、個人の AWS 環境で次の通り検証してみました。
- 前提条件
- 検証環境の構成図
- マルチアカウント間のプライベートホストゾーンの関連付け
- インバウンドエンドポイントの作成
- アカウント B の EC2 からアカウント A の VPC のインバウンドエンドポイントで名前解決する
- インバウンドエンドポイントの削除
- まとめ
- 参考
前提条件
- 2 つの AWS アカウント（アカウント A、B とします）で、それぞれ東京リージョンにプライベートサブネットのみの VPC を一つずつ作成する。また、それぞれの VPC に一つずつ検証用の EC2 を立てる。
- 2 つの AWS アカウントに、それぞれ別のサブドメインで Route 53 のプライベートホストゾーンを作成し、それぞれのプライベートホストゾーンには、自アカウントの EC2 の A レコードのみ登録する。
- 2 つの VPC は Transit Gateway で接続し、互いのサブネットへルーティングできるようにする。
- アカウント B のプライベートホストゾーンをアカウント A の VPC に関連付け、アカウント A の EC2 でアカウント B のプライベートホストゾーンの A レコードを引けるようにする（1 つめのゴール）。
- アカウント A の VPC に Route 53 インバウンドエンドポイントを作成し、アカウント B の EC2 からインバウンドエンドポイントを指定して名前解決することでアカウント A のプライベートホストゾーンの A レコードを引けることを確認する（2 つめのゴール）。
検証環境の構成図
構成図を簡単にまとめました。
VPC の作成、EC2 の作成、Systems Manager のエンドポイントを作成して Session Manager 経由での閉域 EC2 へのアクセス、Transit Gateway の接続の手順は省略します。これは別途改めて記事にしたいと思います。
マルチアカウント間のプライベートホストゾーンの関連付け
プライベートホストゾーンの作成
アカウント A の Route 53 のマネジメントコンソールから「ホストゾーン」→「ホストゾーンの作成」から、プライベートホストゾーンを作成します。適当なサブドメイン（test01.intra.morori.jp）で作成しました。
関連付けるアカウント A の VPC を選択します。
アカウント A の VPC の EC2 の IP アドレスをプライベートホストゾーンに A レコードで登録します。
同様の手順でアカウント B にもプライベートホストゾーン（test02.intra.morori.jp）を作成しておきます。
アカウント B のプライベートホストゾーンはこのような状態になりました。
プライベートホストゾーンの作成が終わったら、それぞれのアカウントの EC2 にログインし、登録した A レコードを名前解決できるか確認します。
当然まだプライベートホストゾーンの関連付けをしていないので、名前解決できるのは自分のアカウントのプライベートホストゾーンのレコードのみです。
アカウント B のプライベートホストゾーンをアカウント A の VPC に関連付ける
アカウント B のプライベートホストゾーンのレコードをアカウント A の EC2 から名前解決できるよう、アカウント B のプライベートホストゾーンをアカウント A の VPC に関連付けます。これはマネジメントコンソールからでは操作できないため、AWS CLI で実施することにします。
関連付けの許可設定
まずはアカウント B のプライベートホストゾーンを、アカウント A の VPC に関連付ける許可設定をします。コマンドは以下の通りで、成功したら JSON が返ってきます。
コマンドの詳細は公式のドキュメントを参照。
関連付けの適用
今度はアカウント A の VPC に実際にアカウント B のプライベートホストゾーンを関連付けます。コマンドは以下の通りで、同様に JSON が返ってきます。
AWS CLI の操作は以上で完了です。マネジメントコンソールを見ると関連付けられた VPC が追加されていることが分かります。
アカウント A の EC2 からアカウント B のプライベートホストゾーンの A レコードを引けるか確認
アカウント A の EC2 にログインして、アカウント B の EC2 の A レコード（test02.test02.intra.morori.jp）を引けるか確認します。
関連付けたプライベートホストゾーンの A レコードが返ってきました！一つ目のゴールはクリアです。
ここで、逆にアカウント B の EC2 からアカウント A のプライベートホストゾーンのレコードは引けないことを確認しておきます。アカウント A のプライベートホストゾーンをアカウント B の VPC に関連付けは今回していないので、当然名前解決は失敗します。
この状態で、アカウント A に Route 53 インバウンドエンドポイントを作成し、アカウント B の EC2 がインバウンドエンドポイントを使って名前解決すれば、アカウント A のプライベートホストゾーンのレコードが引けるようになるか、確認します。
インバウンドエンドポイントの作成
アカウント A のマネジメントコンソールから、Route 53 のインバウンドエンドポイントを作成していきます。
初めに注意！
上記の通り、Route 53 インバウンドエンドポイントは料金が高いので、検証した後は速やかに削除しましょう。放っておくと、ひと月で 3 万円近くかかってしまいます。
セキュリティグループの作成
インバウンドエンドポイントに適用するセキュリティグループを事前に作ります。検証用のため、全ての範囲から TCP 及び UDP 53 番ポートへの通信を許可するルールを作ります。詳細は割愛。
インバウンドエンドポイントの作成
Route 53 のマネジメントコンソールから、「インバウンドエンドポイント」→「インバウンドエンドポイントの作成」に進みます。注意点として、インバウンドエンドポイントの作成には異なる AZ に跨る 2 つ以上の IP アドレスが必要なため、VPC には 2 つ以上の AZ のサブネットが必要です。
インバウンドエンドポイントの IP アドレスが作成されました。
アカウント B の EC2 からアカウント A の VPC のインバウンドエンドポイントで名前解決する
ここまで来たら最後です。アカウント B の EC2 にログインし、アカウント A の Route 53 インバウンドエンドポイントを指定してアカウント A の EC2 の A レコード（test01.test01.intra.morori.jp）を引いてみます。
レコードが返ってきました！これで二つ目のゴールもクリアです。
インバウンドエンドポイントの削除
料金が高いため、インバウンドエンドポイントは速やかに削除しましょう。
まとめ
以上でマルチアカウント間でプライベートホストゾーンとインバウンドエンドポイントを共有する方法について検証できました。本当はオンプレから VPC に VPN で接続してオンプレからもインバウンドエンドポイントで名前解決できるか試したかったのですが、VPN は料金的に簡単にはできない感じなので諦めました……。
AWS 環境の名前解決は非常に重要ですので、運用が楽でかつコストメリットのある方法を採用するのがよいと思います。
