【Route53】Resolver機能を使ったマルチアカウントでのプライベートホストゾーン利用
こんにちは。プラットフォーム技術部の越地です。
今回はマルチアカウント・マルチリージョン環境での名前解決の方法を紹介します。
突然ですが、
「ベストプラクティスに従って部署ごとにVPCを分けたり、マルチアカウント構成にしたけれども、同じ名前解決機能を利用したい！でもVPC関連付けめんどくさい！」
と思ったこと、ありませんか？
AWS CLI経由でしかVPC関連付けができないので、VPCが増えるたびに運用サーバーを起動してスクリプトをたたいたり、VPCを削除するときに関連付けを削除し忘れて謎の設定がずっと残っていたり…VPC関連付けを利用したプライベートホストゾーンの利用は、管理が煩雑になりがちです。
そこで今回は、VPC関連付けを増やすことなく、複数のVPCで同じプライベートホストゾーンを利用できる構成を紹介します。もちろんクロスアカウント・クロスリージョンでも変わらず利用できます！
構成
構成の概要
今回紹介する構成（集約型）では、プライベートホストゾーンとの関連付けを特定のリージョンの1カ所のVPCに集約、他のVPCもこのVPCのAmazon Provided DNS（AWS内部の名前解決機能）を利用するように設定しています。利用したいプライベートホストゾーンにVPCごとに関連付けをおこなう方法（個別型）と比較すると、変更管理やコスト面で下表のとおり、いくつかのメリットがあります。
| 個別型 | 集約型（今回紹介する構成） | |
|---|---|---|
| 変更管理面 | × VPC追加の都度 VPC関連付けも追加する必要あり。 | 〇 VPC追加の際に VPC関連付けを追加する必要なし。 |
| × VPCを削除するときに関連付けを削除し忘れると 不要な設定が残る。個別にAWS CLIで関連付けの削除が必要。 | 〇 各VPCからの関連付けが不要なので、VPC削除時に 関連付け削除も不要。 | |
| × AWS CLIでのみ設定可能なため、CLIを利用するための サーバー構築・管理が必要。 | 〇 AWSコンソールだけで設定・一元管理が可能。 | |
| 〇 送信元IPアドレスをもとに名前解決機能をカスタムしたい といった、VPCごとに異なる動作をさせたい場合に有効。 | × VPCごとに異なる動作をさせたい場合には不向き。 | |
| コスト面 | × Interface型のVPCエンドポイントを利用する場合、 各VPCでエンドポイントの作成が必要となり、 その分費用が増大。 | 〇 集約先VPCのエンドポイントを共用でき、 VPCが多い場合費用削減効果が期待できる。 ※ただしRoute53 Resolverを使用するため、 時間ごとの従量課金が発生する。（Route53の料金） エンドポイントと合わせたトータルコストでの 考慮が必要。 |
検証環境の構成
今回の検証で使用する構成は以下のとおりです。
今回の検証環境では、各部署などが利用するメンバーアカウントの集約先として、管理用アカウントを設定しています。管理用アカウントには、名前解決用のVPC、Route53を設定します。他のVPCがRoute53を利用できるよう、Route53 Resolver Inbound Endpointを設定します。
また、各メンバーアカウントVPCのドメインネームサーバーを名前解決用VPCのRoute53 Resolver Inbound Endpointに設定することで、VPC関連付けを追加することなくプライベートホストゾーンを利用できるようにしています。
| VPC名 | CIDR | リージョン | アカウント |
|---|---|---|---|
| vpc-master（名前解決用VPC） | 10.0.0.0/16 | ap-northeast-1(tokyo) | A |
| vpc-test01 | 10.1.0.0/16 | ap-northeast-1(tokyo) | B |
| vpc-test02 | 10.2.0.0/16 | ap-northeast-3(osaka) | B |
なお、今回は接続するVPCが少ないため各VPC間の接続はVPC Peeringを利用していますが、Transit Gatewayなどで接続してもOKです。
VPC Peeringはデータ転送料だけで利用できるコストメリットがありますが、VPCそれぞれについて1対1の関係でピアリング接続を設定する必要があり、VPCが増減するごとにルーティング設定を行わなければなりません。
VPCをまたいだ接続もできない（VPC A⇔B、B⇔C間でピアリング接続しているとき、A⇔C間での通信はできない）ため、接続したいVPCが増えると必要なピアリング接続が倍々に増えていくデメリットもあります。また、AWSコンソール上で視覚的にピアリング接続を確認できないため、通信要件が複雑な場合、どのVPC間でピアリング接続するべきか、構成変更時にはどのピアリング接続を変更するべきかを把握しておくのはかなり骨の折れる作業です。
Transit Gatewayの場合、クラウドルーターとして機能してくれるので、VPCごとに個別の接続を増やす必要はありません。また専用のルートテーブルを利用できるため、VPC間の通信制御も一元的に管理できます。上記のようにVPCが多い場合、通信要件が複雑な場合にはTransit Gatewayでの制御をおすすめします。
設定
設定の流れ
それでは、さっそく設定していきます。
設定の大まかな流れとしては、
- 管理用アカウントにプライベートホストゾーンを設定
- 管理用アカウントにRoute53 Resolverを設定
- メンバーアカウントのVPCのDHCPオプションセットを設定
です。それぞれの概要を以下に記載します。
管理用アカウントにプライベートホストゾーンを設定
まずは管理用アカウントにプライベートホストゾーンを設定します。既存のホストゾーンがある場合、そちらを利用してもOKです。既存のものを利用する場合、集約する環境を含めエンドポイントの利用などAWS内部の名前解決機能を利用していないか、実影響がないかは十分検証の上設定してください。
管理用アカウントにRoute53 Resolverを設定
今回の構成の中心となる設定です。管理用アカウントの名前解決用VPC上に、他のVPCから名前解決用VPCの名前解決機能を利用できるよう受け口（Route53 Resolver Inbound Endpoint）を用意します。
メンバーアカウントのVPCのDHCPオプションセットを設定
最後に、メンバーアカウントのVPCのDHCPオプションセットをデフォルトから変更します。ドメインネームサーバーをデフォルトのメンバーアカウントのVPC内から、名前解決用VPCのRoute53 Resolver Inbound Endpointを参照するように設定します。
管理用アカウント設定
名前解決用VPC設定
はじめに、Route53プライベートホストゾーンを置くVPC（以下、名前解決用VPC）を設定します。
プライベートホストゾーンを置く要件として必要なため（プライベートホストゾーンを使用する場合の考慮事項）、デフォルトで無効になっているDNSホスト名を有効に設定します。
[アクション]-[DNSホスト名を編集]で設定の編集ができます。
[有効化]にチェックを入れたら変更を保存します。
この後設定するRoute53 Resolver Inbound Endpointで利用するため、サブネットも作成しておきます。AZを2つ以上、メンバーアカウントのVPCと通信できる設定で作成します。検証では東京リージョンを利用したので、AZ-aとAZ-cの2AZでサブネットを作成しました。
Route53 プライベートホストゾーン設定
続けて、Route53を設定します。
プライベートホストゾーンですが、作成時にVPC関連付けを1つする必要があります。この時のVPCは、先ほど作成した名前解決用VPCを設定します。
Route53 Resolver Inbound Endpoint 設定
いよいよ、今回の構成の肝であるRoute53 Resolver Inbound Endpointを設定していきます。
まずはエンドポイントに設定するセキュリティグループを作成します。
Route53 Resolver Inbound Endpointを利用させたいVPCのCIDRが決まっている/既存VPCを利用する場合は、このセキュリティグループのインバウンドルールに以下設定を追加します。あとでVPCを追加/削除したい場合は、このセキュリティグループのルールを変更すればOKです。
| タイプ | プロトコル | ポート範囲 | ソース |
|---|---|---|---|
| DNS(TCP) | TCP | 53 | <エンドポイントを利用するVPCのCIDR> |
| DNS(UDP) | UDP | 53 | <エンドポイントを利用するVPCのCIDR> |
今回の検証ではRoute53 Resolver Inbound Endpoint用のセキュリティグループに対して、vpc-test01とvpc-test02のCIDRからの通信を許可しています。
Route53 Resolverの設定画面に移動します。
サービス一覧から[Route53]を選択します。左ペインの[リゾルバー]配下に[インバウンドエンドポイント]があるので、これをクリックします。はじめて作成する場合は下記のような画面になるので、[エンドポイントの設定]をクリックします。
エンドポイント名などの入力ができる作成画面に遷移するので、以下のように設定します。
[送信]をクリックするとエンドポイントの作成が開始されます。
| 項目 | 設定値 |
|---|---|
| エンドポイント名 | 任意の名前 |
| 当該リージョンのVPC | 名前解決用のVPC |
| このエンドポイントのセキュリティグループ | 作成したエンドポイント用のセキュリティグループ |
| IPアドレス | AZを最低2つ設定。ここで設定したIPアドレスはのちほど使用するため、控えておく。 |
ステータスが「実行中」になれば作成完了です。
メンバーアカウント設定
メンバーアカウント側の設定も行います。
DHCPオプションセット設定
Route53 Resolver Inbound Endpointを設定する、DHCPオプションセットを作成します。この設定で、メンバーアカウントのVPCが名前解決をする際に利用するドメインネームサーバーとして、Route53 Resolver Inbound Endpointを設定します。
サービス一覧から[VPC]を選択、左ペインの[DHCPオプションセット]をクリックします。[DHCPオプションセットを作成]から、新規に作成を開始します。
設定画面で以下設定で作成します。ドメイン名など、今回使用しないものは空欄のままで大丈夫です。
| 項目 | 設定値 |
|---|---|
| DHCPオプションセット名 | 任意の名前 |
| ドメインネームサーバー | Route53 Resolver Inbound Endpoint で設定したIPアドレスのリスト。コンマ区切り。 |
DHCPオプションセットを作成したら、エンドポイントを利用したいVPCに設定します。
設定したいVPCを選択した状態で、[アクション]-[DHCPオプションセットを編集]をクリックします。
作成したDHCPオプションセットを選択後、変更を保存します。
大阪リージョンに作成したvpc-test02についても、同様に設定しておきます。
これですべての設定が完了しました！
動作テスト
さっそく、名前解決できるか確認してみます！
テスト用に以下のレコードセットtest01.master.comを作成しました。名前解決ができれば、設定したAレコード（IPアドレス:10.10.0.13）が返却される想定です。
まずは東京リージョンから確認します。以下テスト用に起動したEC2インスタンスにSSM接続、digコマンドで確認します。
無事名前解決ができました！問い合わせ先も設定したエンドポイントを参照しています。
大阪リージョンも、同様に名前解決できることを確認しました。
まとめ
今回はRoute53プライベートホストゾーンをマルチアカウント・マルチリージョン下で集約する方法を紹介しました。同じ名前解決を利用するような環境構成の場合、よりシンプルに、管理しやすい構成にできます。
またRoute53 Resolver Outbound Endpointを追加設定することで、オンプレミス環境と接続した場合でも、同じように名前解決機能を利用できます。従来のように冗長性などを気にしながらDNSフォワーダーを作成する必要がないため、ハイブリッド構成でAWS内部の名前解決を行いたい場合には、特に有用な構成です。
2018年のGA当初は英語版のみのコンソール表示なこともあり、なかなかとっつきにくいイメージのRoute53 Resolverでしたが、現在（2022年1月）は日本語対応もされています。比較的少ない作業で設定もできるので、利用してみてはいかがでしょうか？
