Zenn
🌏

マルチアカウント×ハイブリッドクラウド構成におけるRoute53

2025/02/21に公開
AWS
Route53
VPC
JAWS-UG
nw
tech

対象読者

  • AWSでマルチアカウント構成を検討している方
  • AWSを含むハイブリッドクラウド構成を検討している方
  • マルチアカウント×ハイブリッドクラウド構成のDNSに関する検討をされている方

はじめに

本記事ではサンプルシステムを用いて、ハイブリッドクラウド構成やマルチアカウント構成におけるRoute53の機能や、その設計パターンについてご紹介し、実装手順や検証内容を記載します。

なお、本記事の内容はNW-JAWS #15での発表を包含します。
10分間のLTではポイントを絞ってご説明しましたが、詳細情報を補足するために記事を執筆しています。
https://jawsug-nw.connpass.com/event/343703/

前提となるシステム構成

今回はAWSとオンプレミス環境をDirect Connectでつないだハイブリッドクラウド構成とします。
AWS上にはマルチアカウントの共通基盤が構成されており、1アカウント・1システムを搭載するような構成とします。
AWS、オンプレミスそれぞれにネームサーバが設置されており、AWS上はaws.homeドメイン、オンプレはonp.homeドメインのレコードを管理しています。

検証を行った疑似環境

自宅環境とDirect Connectをつなぐわけにはいかない&今回の記事において重要なポイントではありません。
なので、本記事では1つVPCを用意し、該当VPCをオンプレミス環境に見立て、EC2上にBINDを構築することで構築・検証していきます。

ハイブリッドクラウド構成におけるRoute53

まずはじめにハイブリッドクラウド構成で活用できるRoute53の機能について紹介していきます。

AWSからオンプレドメインを引く場合

AWS環境からオンプレドメインを引く場合について解説します。
この方向の名前解決で重要になるRoute53の機能は転送ルールとOutbound Endpointです。

転送ルールとOutbound Endpoint

転送ルールはオンプレのコンテンツサーバにフォワードするためのルールを管理します。
コンテンツサーバにフォワードする条件となる「ドメイン名」と、フォワード先コンテンツサーバのIP、AWSからの送信元となる「Outbound Endpoint」を指定します。

トラフィックフロー

トラフィックフローは以下の通りです。

  1. VPC上のEC2から、Route53 Resolverへ名前解決要求が送信されます。
  2. Route53 Resolverは自身が所属するVPCに割り当たっている転送ルールに基づき、Outbound Endpointに転送します。
  3. Outbound Endpoitから、オンプレミスのコンテンツサーバへ名前解決を要求します。
  4. コンテンツサーバから結果が返却されます。

実装

参考までに実装手順を記載します。
必要な方だけ読んでいただければと思います。

Outbound Endpoit作成

まずOutbound Endpointを作成します。
デプロイ先のVPCとサブネットを選択し、タイプとプロトコルを選択します。
タイプはIPv4/6、デュアルスタックを選択可能です。
プロトコルは追加の暗号がない従来のDNS（Do53: DNS over UDP/TCP port 53）、暗号化通信によりセキュアなDNS over HTTPS（DoH: DNS通信をHTTPS上で行うプロトコル）とその両方を設定することができます

転送ルールの作成

次に転送ルールを作成します。
転送元のエンドポイントに、先ほど作成したアウトバウンドエンドポイントを設定し、ルールタイプ、ドメイン名、関連付けるVPCを選択します。
ターゲットIPアドレスには、名前解決要求の転送先DNSサーバのIPアドレスとポート、プロトコルを選択します。

動作確認

NWアカウントのVPCにCloud Shell環境を作成し、digでBINDがホストしているレコードを解決します。
画面上部が割り当てている転送ルールで、
CloudShellの左側がオンプレのコンテンツサーバ、
右側がNWアカウントVPC上のCloudShellです。

NWアカウントVPC上のCloudShellでBINDがホストしているレコードが返却できていることが確認できます。
紹介しているDNSサーバのIPがVPCのCIDR+2になっていることからも、Route53 Resolver経由でBINDに到達していることがわかります。

オンプレミスからAWSドメインを引く場合

次にオンプレミス環境からAWSドメインを引く場合について解説します。
この方向の名前解決で重要になるRoute53の機能はPrivate Hosted ZoneとInbound Endpointです。

Private Hosted Zone

Private Hosted ZoneはDNSレコードを管理します。
先ほどのオンプレ環境でいうBINDサーバ相当の役割を担います。ゾーンの作成およびレコードの追加の後、該当のDNSレコードを解決させたいVPCに関連付けることで機能します。
Private Hosted Zoneは関連づいたVPCのRoute53 Resolverからのみリクエストを受け付けます。

Inbound Endpoint

次にInbound Endpointについて解説します。
外部NWを経由してVPCに関連づいているPrivate Hosted Zoneを名前解決するために、Inbound Endpointを利用します。
Inbound Endpointはリクエストを受け付けたのち、Route53 Resolver経由でPrivate Hosted Zoneで管理しているレコードを名前解決します。

トラフィックフロー

トラフィックフローは以下の通りです。

  1. まずオンプレミス環境のクライアントから、キャッシュサーバに名前解決要求が送信されます。
  2. キャッシュサーバは自身の転送設定に基づき、Inbound Endpointに転送します。
  3. Inbound Endpoint は自身の所属するRoute53 Resolverに転送し、
  4. Route53 ResolverがVPCに関連付いているPrivate Hosted Zoneで名前解決します

実装

参考までに実装手順を記載します。
必要な方だけ読んでいただければと思います。

Private Hosted Zone作成

ホストゾーンを作成を選択

ドメイン名とタイプ（プライベートホストゾーン）を設定し、関連付けるVPCを選択する

Inbound Endpoint作成

デプロイ先のVPCやサブネット、エンドポイントタイプやプロトコル、SG等を選択して作成

動作確認

疑似オンプレVPC上のEC2から、digでInbound EndpointのIPを指定してPHZ上のレコードを解決します。
画面上部が宛先のInbound Endpointの情報で、
CloudShellの左側がオンプレVPC上のEC2
右側が、NWアカウントVPC上のCloudShellです。

疑似オンプレVPC上のEC2からInbound EndpointのIPを指定してwww.aws.homeが解決できていることが確認できます。

マルチアカウント構成におけるRoute53

ここからはAWSの共通基盤上で、マルチアカウント構成における設計ポイントについてご紹介します。

今回の構成では以下の2点の設計ポリシーの実現を通して、マルチアカウントにおけるRoute53の機能をご紹介します。

  1. Private Hosted Zoneは各システムごとではなく一元管理する
  2. 各種Endpoint（Inbound/Outbound、VPC Endpoint）はNWアカウントに集約し、コストを削減する

PHZの共有

PHZは複数のVPCに関連付けることができます。
アカウントをまたいで関連付けることも可能ですが、RAMを利用することはできません。
共有はマネコンからはできず、AWS CLI、SDKもしくはRoute53 APIを利用する必要があります。
AWS CLIを利用する際のフローを以下に示します。


https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html

実装

参考までに実装手順を記載します。
必要な方だけ読んでいただければと思います。

1.Private Hosted Zone共有

共有元アカウントでaws route53 create-vpc-association-authorizationコマンドを発行して、共有先アカウントのVPCに共有します。

aws route53 create-vpc-association-authorization --hosted-zone-id [PHZのID] --vpc VPCRegion=[共有先VPCのRegion],VPCId=[共有先VPC ID]

2.Private Hosted Zoneの共有を承諾する　3. 割り当てを確認する

次に共有先アカウントでaws route53 associate-vpc-with-hosted-zoneコマンドを発行して、共有を受け入れます。
承諾の前後で、list-hosted-zones-by-vpcコマンドを発行し、状態を比較します。

aws route53 associate-vpc-with-hosted-zone --hosted-zone-id [PHZのID] --vpc VPCRegion=[共有先VPCのRegion],VPCId=[共有先VPC ID]

正しく割り当てられていることが確認できました。

4.Private Hosted Zone共有削除

最後に1.で作成した共有リソースを削除します。

aws route53 delete-vpc-association-authorization --hosted-zone-id [PHZのID] --vpc VPCRegion=[共有先VPCのRegion],VPCId=[共有先VPC ID]

動作確認

動作確認をしてみます。
今回、Aシステム相当のAWSアカウント上のVPCにPHZを関連付けしました。
digでwww.aws.homeを名前解決してみます。

無事に回答が得られていることが確認できました。

Endpointの集約

Inbound Endpointに関しては、PHZ上に必要なレコードを追加して、Inbound Endpointを設置するVPCに関連付けるだけで集約可能なので詳細は割愛します。

Outbound Endpointを共用するためには、転送ルールを共用する必要があります。
転送ルールに関してはRAMが活用できますので、特別な手順は必要ありません。

実装

参考までに実装手順を記載します。
必要な方だけ読んでいただければと思います。

RAMによる転送ルールの共有

共有したい転送ルールを選択

共有先を設定（今回はAWSアカウントを指定）

リソースの共有が作成される

転送ルールの割り当て

RAMで共有された後、Route53のコンソール上転送ルールが表示されるようになります。

表示された転送ルールを選択し、VPCを関連付けます。

動作確認

共有された転送ルールの動作確認として、AシステムVPCからdigでwww.onp.homeを名前解決しました。

きちんと名前解決できています。
右上のAWSアカウントIDと転送ルールの所有者の末尾が異なることから、クロスアカウントで共有されたルールが割り当てられていることが確認できます。

なお、今回の構成ではAシステムVPCとNWアカウントVPCの間にNW疎通性はありません。
これにより、転送ルールを設定したVPCとOutbound Endpointを設置しているVPCの間にNWの疎通性が必要ないことがわかります。

VPCEを集約

今回はあくまでRoute53に関連する話を中心にしてきましたが、VPCEの集約についても少しご紹介します。
VPCEを作成する際、「プライベートDNS名を有効化する」というオプションがあります。
通常、VPC内からDNS名を使ってVPCEにアクセスしたい場合は有効化すると思いますが、共有する場合には該当オプションは使用できません。

↓の記事で紹介していますが、VPCEは内部的にサービスのエンドポイントと同名のPrivate Hosted Zoneを作成し、Route53 ResolverがPrivate Hosted Zoneのレコードを解決することで、VPCE経由でサービスに接続します。
https://zenn.dev/hanabusashun/articles/833a0f591d01a1

VPCEを共用するためには、該当のPrivate Hosted Zoneを各VPCに関連付ける必要があるのですが、「プライベートDNS名を有効化する」オプションを使って作成されたPrivate Hosted Zoneは共有することができません。
こちらも先の記事で触れていますが、サービスごとにPrivate Hosted Zoneを自身で作成し、共有する必要があります。

Route53 Profilesについて

実装

プロファイルの作成

プロファイル名を指定して作成

作成されたプロファイルにPrivate Hosted Zoneとリゾルバールールを関連付ける


プロファイルの共有

【共有元アカウント操作】共有したいRoute53プロファイルを指定

【共有元アカウント操作】共有先のプリンシパルを指定（今回はOUを指定）して共有

【共有先アカウント操作】共有されていることを確認

プロファイルの割り当て

共有されているプロファイルをVPCに割り当てる

検証

PHZの共有確認としてwww.aws.homeドメインの名前解決を、
転送ルールの共有確認として、www.onp.homeドメインの名前解決を行いました。

問題なく名前解決できました。

まとめ

ハイブリッドクラウド×マルチアカウントのRoute53についてご説明しました。
そんなにしょっちゅう設計することはないと思いますが、設計する際にはぜひご参考にしていただければと思います。

Discussion