【Route53】Resolver機能を使ったマルチアカウントでのプライベートホストゾーン利用

Amazon Web Services,AWS Route53

こんにちは。プラットフォーム技術部の越地です。

今回はマルチアカウント・マルチリージョン環境での名前解決の方法を紹介します。

突然ですが、
「ベストプラクティスに従って部署ごとに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/16ap-northeast-1(tokyo)A
vpc-test0110.1.0.0/16ap-northeast-1(tokyo)B
vpc-test0210.2.0.0/16ap-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での制御をおすすめします。

TransitGatewayを利用した場合の全体構成図
TransitGatewayを利用した場合の全体構成図

設定

設定の流れ

それでは、さっそく設定していきます。

設定の大まかな流れとしては、

  • 管理用アカウントにプライベートホストゾーンを設定
  • 管理用アカウントにRoute53 Resolverを設定
  • メンバーアカウントのVPCのDHCPオプションセットを設定

です。それぞれの概要を以下に記載します。

管理用アカウントにプライベートホストゾーンを設定

まずは管理用アカウントにプライベートホストゾーンを設定します。既存のホストゾーンがある場合、そちらを利用してもOKです。既存のものを利用する場合、集約する環境を含めエンドポイントの利用などAWS内部の名前解決機能を利用していないか、実影響がないかは十分検証の上設定してください。

プライベートホストゾーンの設定
プライベートホストゾーンの設定

管理用アカウントにRoute53 Resolverを設定

今回の構成の中心となる設定です。管理用アカウントの名前解決用VPC上に、他のVPCから名前解決用VPCの名前解決機能を利用できるよう受け口(Route53 Resolver Inbound Endpoint)を用意します。

Route53 Resolverの設定
Route53 Resolverの設定

メンバーアカウントのVPCのDHCPオプションセットを設定

最後に、メンバーアカウントのVPCのDHCPオプションセットをデフォルトから変更します。ドメインネームサーバーをデフォルトのメンバーアカウントのVPC内から、名前解決用VPCのRoute53 Resolver Inbound Endpointを参照するように設定します。

DHCPオプションセットの設定
DHCPオプションセットの設定

管理用アカウント設定

名前解決用VPC設定

はじめに、Route53プライベートホストゾーンを置くVPC(以下、名前解決用VPC)を設定します。
プライベートホストゾーンを置く要件として必要なため(プライベートホストゾーンを使用する場合の考慮事項)、デフォルトで無効になっているDNSホスト名を有効に設定します。
[アクション]-[DNSホスト名を編集]で設定の編集ができます。

DNSホスト名の有効化1
DNSホスト名の有効化1

[有効化]にチェックを入れたら変更を保存します。

DNSホスト名の有効化2
DNSホスト名の有効化2

この後設定するRoute53 Resolver Inbound Endpointで利用するため、サブネットも作成しておきます。AZを2つ以上、メンバーアカウントのVPCと通信できる設定で作成します。検証では東京リージョンを利用したので、AZ-aとAZ-cの2AZでサブネットを作成しました。

名前解決用VPC サブネット作成
名前解決用VPC サブネット作成

Route53 プライベートホストゾーン設定

続けて、Route53を設定します。
プライベートホストゾーンですが、作成時にVPC関連付けを1つする必要があります。この時のVPCは、先ほど作成した名前解決用VPCを設定します。

Route53 プライベートホストゾーン作成1
Route53 プライベートホストゾーン作成1
Route53 プライベートホストゾーン作成2
Route53 プライベートホストゾーン作成2
Route53 プライベートホストゾーン作成3
Route53 プライベートホストゾーン作成3

Route53 Resolver Inbound Endpoint 設定

いよいよ、今回の構成の肝であるRoute53 Resolver Inbound Endpointを設定していきます。

まずはエンドポイントに設定するセキュリティグループを作成します。
Route53 Resolver Inbound Endpointを利用させたいVPCのCIDRが決まっている/既存VPCを利用する場合は、このセキュリティグループのインバウンドルールに以下設定を追加します。あとでVPCを追加/削除したい場合は、このセキュリティグループのルールを変更すればOKです。

タイププロトコルポート範囲ソース
DNS(TCP)TCP53<エンドポイントを利用するVPCのCIDR>
DNS(UDP)UDP53 <エンドポイントを利用するVPCのCIDR>

今回の検証ではRoute53 Resolver Inbound Endpoint用のセキュリティグループに対して、vpc-test01とvpc-test02のCIDRからの通信を許可しています。

Route53 Resolver Inbound Endpoint用セキュリティグループ設定
Route53 Resolver Inbound Endpoint用セキュリティグループ設定

Route53 Resolverの設定画面に移動します。
サービス一覧から[Route53]を選択します。左ペインの[リゾルバー]配下に[インバウンドエンドポイント]があるので、これをクリックします。はじめて作成する場合は下記のような画面になるので、[エンドポイントの設定]をクリックします。

Route53 Resolver Inbound Endpointの作成1
Route53 Resolver Inbound Endpointの作成1

エンドポイント名などの入力ができる作成画面に遷移するので、以下のように設定します。
[送信]をクリックするとエンドポイントの作成が開始されます。

項目設定値
エンドポイント名任意の名前
当該リージョンのVPC名前解決用のVPC
このエンドポイントのセキュリティグループ作成したエンドポイント用のセキュリティグループ
IPアドレスAZを最低2つ設定。ここで設定したIPアドレスはのちほど使用するため、控えておく。
Route53 Resolver Inbound Endpointの作成2
Route53 Resolver Inbound Endpointの作成2
Route53 Resolver Inbound Endpointの作成3
Route53 Resolver Inbound Endpointの作成3
Route53 Resolver Inbound Endpointの作成4
Route53 Resolver Inbound Endpointの作成4
Route53 Resolver Inbound Endpointの作成5
Route53 Resolver Inbound Endpointの作成5
Route53 Resolver Inbound Endpointの作成6
Route53 Resolver Inbound Endpointの作成6

ステータスが「実行中」になれば作成完了です。

メンバーアカウント設定

メンバーアカウント側の設定も行います。

DHCPオプションセット設定

Route53 Resolver Inbound Endpointを設定する、DHCPオプションセットを作成します。この設定で、メンバーアカウントのVPCが名前解決をする際に利用するドメインネームサーバーとして、Route53 Resolver Inbound Endpointを設定します。
サービス一覧から[VPC]を選択、左ペインの[DHCPオプションセット]をクリックします。[DHCPオプションセットを作成]から、新規に作成を開始します。

DHCPオプションセット作成1
DHCPオプションセット作成1

設定画面で以下設定で作成します。ドメイン名など、今回使用しないものは空欄のままで大丈夫です。

項目設定値
DHCPオプションセット名任意の名前
ドメインネームサーバー Route53 Resolver Inbound Endpoint で設定したIPアドレスのリスト。コンマ区切り。
DHCPオプションセット作成2
DHCPオプションセット作成2

DHCPオプションセットを作成したら、エンドポイントを利用したいVPCに設定します。
設定したいVPCを選択した状態で、[アクション]-[DHCPオプションセットを編集]をクリックします。

メンバーVPC設定1
メンバーVPC設定1

作成したDHCPオプションセットを選択後、変更を保存します。

メンバーVPC設定2
メンバーVPC設定2
メンバーVPC設定3
メンバーVPC設定3

大阪リージョンに作成したvpc-test02についても、同様に設定しておきます。

メンバーVPC設定4
メンバーVPC設定4
メンバーVPC設定5
メンバーVPC設定5

これですべての設定が完了しました!

動作テスト

さっそく、名前解決できるか確認してみます!

テスト用に以下のレコードセットtest01.master.comを作成しました。名前解決ができれば、設定したAレコード(IPアドレス:10.10.0.13)が返却される想定です。

動作テスト レコードセット1
動作テスト レコードセット1

まずは東京リージョンから確認します。以下テスト用に起動したEC2インスタンスにSSM接続、digコマンドで確認します。

動作テスト 東京1
動作テスト 東京1
動作テスト 東京2
動作テスト 東京2

無事名前解決ができました!問い合わせ先も設定したエンドポイントを参照しています。

大阪リージョンも、同様に名前解決できることを確認しました。

動作テスト 大阪1
動作テスト 大阪1
動作テスト 大阪2
動作テスト 大阪2

まとめ

今回はRoute53プライベートホストゾーンをマルチアカウント・マルチリージョン下で集約する方法を紹介しました。同じ名前解決を利用するような環境構成の場合、よりシンプルに、管理しやすい構成にできます。

またRoute53 Resolver Outbound Endpointを追加設定することで、オンプレミス環境と接続した場合でも、同じように名前解決機能を利用できます。従来のように冗長性などを気にしながらDNSフォワーダーを作成する必要がないため、ハイブリッド構成でAWS内部の名前解決を行いたい場合には、特に有用な構成です。

2018年のGA当初は英語版のみのコンソール表示なこともあり、なかなかとっつきにくいイメージのRoute53 Resolverでしたが、現在(2022年1月)は日本語対応もされています。比較的少ない作業で設定もできるので、利用してみてはいかがでしょうか?

  • 株式会社アークシステムの予約・来訪管理システム BRoomHubs
  • 低コスト・短納期で提供するまるごとおまかせZabbix