複数VPCで名前解決を集約・共有する方法を試してみた
こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。
マルチアカウントや大量のVPCが存在する環境で名前解決の戦略がよくわからなくなりませんか。
私はなります。
今回はシングルアカウントに複数のVPCを用意してよい感じに名前解決の機能をまとめることができないか考えてみました。
やっていることは単独のアカウント内ですが、参考にしている記事はマルチアカウントのものであったり、そもそもの考え方はマルチアカウントに応用が効くかと思います。
名前解決の集約・そもそものやり方が良くわからない人への参考になればうれしいです。
先にまとめ
共通の名前解決を複数VPCでやる方法として以下2種類を試しました。
方法1: Route 53 Private Hosted Zoneを複数のVPCに関連付ける
- Route 53 Private Hosted Zoneを必要なすべてのVPCに関連づける
1の方法の構成イメージはこちらです。
想定されるメリット・デメリットはこちら。
- 今回はシングルアカウントですがマルチアカウントの場合こちらのようにPrivate Hosted Zone共有の承認作業が必要です
- そのためマルチアカウントでVPCが大量にある場合、作業のIaC化や自動化を考えなければ運用の手間がかかりそうです
方法2： Route 53 Resolver Endpointなどを使って1つのVPCに名前解決の機能を集約
- Route 53 Ressolver Inbound Endpointを使ってネットワーク的に解決する方法
- 集約用VPCにRoute 53 Private Hosted Zoneを関連付け
- 1の方法と異なり関連付けするVPCは集約用VPCのみ
- Route 53 Resolver Inbound Endpointを集約用VPCに作成
- DHCPオプションセットを作成し、ワークロード用VPCからの名前解決をRoute 53 Resolver Inbound Endpointに向ける
- 集約用VPCにRoute 53 Private Hosted Zoneを関連付け
2の方法の構成イメージはこちらです。
想定されるメリット・デメリットはこちら。
- マルチアカウント運用においても1の方法よりは運用の手間がかからないと思います
- 一方で名前解決を集約用VPCにすべて向けるため、そのあたりでトラブルが発生しないか懸念があります
- 特定のVPCだけで個別の名前解決させたい場合など
- また、Route 53 Resolver Endpointの分料金コストが1の方法よりかかります
参考にしたサイト
- 【レポート】名前解決はひとつの VPC にまとめよう（R53 resolver＆Transit Gateway） #AWSSummit | DevelopersIO
- こちらに書いてある2種類の方法を試しました
- 今回の記事ではシングルアカウントですが、この記事ではマルチアカウントを想定しています
- マルチアカウントのVPCエンドポイント(インターフェイス型)を1つに集約させる | DevelopersIO
- AWS Transit Gatewayに接続したShared VPCにVPCエンドポイントを集約してみた | DevelopersIO
- VPCエンドポイントを1つのVPCに集約しています
- この記事を参考に今回はVPCエンドポイントを1つのVPCに集約しています
- [Route 53]他のAWSアカウントのVPCにプライベートホストゾーンを関連付ける | DevelopersIO
2つの方法でやってみた
下準備 共通構成を立ち上げ
まずはAWS CDK（Go言語）を使って以下のような構成を立ち上げます。
この時点の構成では以下のようなことを確認しています。
- Transit Gatewayを介してShared VPCとSpoke VPCのEC2間で双方向に通信が疎通している
- pingで疎通確認しています
- Shared VPCのEC2にSystems ManagerのSession Managerで接続できるようにVPCエンドポイントを作成
com.amazonaws.ap-northeast-1.ssmcom.amazonaws.ap-northeast-1.ssmmessagescom.amazonaws.ap-northeast-1.ec2messages
- Route 53 Private Hosted Zoneを作成してShared VPCに関連付け。Shared VPCのEC2インスタンスから名前解決ができる
- 上記VPCエンドポイントとPrivate Hosted Zoneにより、Shared VPCのEC2インスタンスに対して、Session Managerで接続ができる
作成しているRoute 53 Private Hosted Zoneは以下のとおりです。
| ゾーン名 | 用途 | 備考 |
|---|---|---|
| sample.example.com | 適当にAレコードを設定して名前解決ができるか検証するため | |
| ssm.ap-northeast-1.amazonaws.com | ssmのVPCエンドポイントの名前解決のため | こちらを参照 |
| ssmmessages.ap-northeast-1.amazonaws.com | ssmmessagesのVPCエンドポイントの名前解決のため | こちらを参照 |
| ec2messages.ap-northeast-1.amazonaws.com | ec2messagesのVPCエンドポイントの名前解決のため | こちらを参照 |
なお、今回使用したCDKのコードは以下リポジトリに格納していますので、興味のある方はご参照ください。
1. Route 53 Private Hosted Zoneで作ったルールを複数のVPCに関連付ける方法
それでは1つ目の方法を試していきます。
再掲となりますが、構成イメージはこのような形です。
Shared VPCのEC2インスタンスから名前解決
まず名前解決ができるか確かめるために作成しているRoute 53 Private Hosted Zoneを見てみます。
以下のようにテスト用のPrivate Hosted Zoneを作成して、Shared VPCにのみ関連付けをしています。
名前解決のためShared VPCのEC2インスタンスにSession Managerで接続します。
digコマンドで試してみると、ちゃんと名前解決ができていることがわかります。
# Shared VPCのインスタンス dig test.sample.example.com # 略 ↓のように名前解決ができている test.sample.example.com. 300 IN A 10.10.0.8 # 略 ;; Query time: 1 msec ;; SERVER: 10.10.0.2#53(10.10.0.2) ;; WHEN: Thu Apr 06 05:46:03 UTC 2023 ;; MSG SIZE rcvd: 68
Spoke VPCにPrivate Hosted Zoneを関連付けてみる
次に、Spoke VPCにもRoute 53 Private Hosted Zoneを関連付けてみます。
※ 名前がWorkloadVPCとなっていますが、WorkloadVPC=SpokeVPCです。
この状態でSpoke VPCのEC2インスタンスを再起動してみると、Session Managerにより接続できるようになりました。
なお、Spoke VPCにはVPCエンドポイントがないので、この時点でShared VPCのエンドポイントへの接続および名前解決ができていることがわかります。
ですが、念の為Spoke VPCのEC2インスタンスに対してSession Managerで接続してみます。
digコマンドで試してみると、ちゃんと名前解決ができていることがわかります。
dig test.sample.example.com # 略 ↓名前解決ができている test.sample.example.com. 300 IN A 10.10.0.8 # 略 ;; Query time: 8 msec ;; SERVER: 10.20.0.2#53(10.20.0.2) ;; WHEN: Thu Apr 06 05:51:43 UTC 2023 ;; MSG SIZE rcvd: 68
これでRoute 53 Private Hosted Zoneの関連付けによる複数VPCでの名前解決の共有を確かめることができました。
2. Route 53 Ressolver Inbound Endpointを使ってネットワーク的に解決する方法
ということで次は以下のようにShared VPCにのみPrivate HostedZoneを関連付け、他のVPCからはResolver Endpointを介して名前解決をする方法を試してみます。
なお、Route 53 Resolverとは？Resolver Endpointとは？という方は以下のブログがわかりやすかったのでご参照ください。
環境は以下のようにRoute 53 Private Hosted ZoneはShared VPCにのみ関連付けするように戻しています。
これによりSpoke VPCのEC2インスタンスからShared VPCのVPCエンドポイントの名前解決ができないため、Session Managerによる接続はできなくなっています。
次にRoute 53 Resolver EndpointをShared VPCに作成します。
また、名前解決を↑で作成したResolver Endpoint（Inbound Endpoint）へ向ける設定をしたDHCPオプションセットを作成します。
Spoke VPCで作ったDHCPオプションセットを設定し、Spoke VPC内での名前解決をRoute 53 Resolver Endpoint（Inbound Endpoint）へ向けます。
これにより以下の構成ができ、Spoke VPCのEC2インスタンスにSession Managerで接続できるようになりました。
Spoke VPCにはVPCエンドポイントを作っていないため、この時点で名前解決は問題ないはずですが、念の為Spoke VPCのEC2インスタンスに接続して名前解決を試してみます。
digコマンドによりShared VPCのVPCエンドポイントの名前解決ができていることがわかります。
# VPC BのEC2インスタンスからVPC AのRoute53 Private HostedZoneで設定したレコードの名前解決ができている sh-4.2$ dig ssmmessages.ap-northeast-1.amazonaws.com ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13 <<>> ssmmessages.ap-northeast-1.amazonaws.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39895 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ssmmessages.ap-northeast-1.amazonaws.com. IN A ;; ANSWER SECTION: ssmmessages.ap-northeast-1.amazonaws.com. 60 IN A 10.10.1.249 ssmmessages.ap-northeast-1.amazonaws.com. 60 IN A 10.10.2.162 ;; Query time: 3 msec ;; SERVER: 10.10.1.100#53(10.10.1.100) #SERVERもShared VPCのものになっています ;; WHEN: Thu Apr 06 09:26:59 UTC 2023 ;; MSG SIZE rcvd: 90
これで双方の方法により名前解決を試せました！
最後に
今回は2種類の方法により複数VPCで共通の名前解決を試してみました。
最初にまとめたようにどちらの方法も一長一短だと思いますが、組織規模やコスト面と運用面のバランスを考慮して最適な方法を考えたいですね。
この記事がどなたかの参考になればうれしいです。以上今泉でした。
