マルチアカウント環境におけるAmazon Route 53 Resolver エンドポイントの集約構成（複数リージョン対応）
2025.02.19はじめに
本記事では、マルチアカウント環境における Route 53 Resolver のインバウンドおよびアウトバウンドエンドポイントの集約方法について解説します。特に、複数リージョンにまたがる環境 を考慮した設計を紹介します。
以前、東京リージョンのみを対象とした集約構成について解説しました。今回は、複数リージョンに対応した構成を紹介します。
なお、組織の要件や環境によって最適な構成は異なるため、本記事の内容は参考としてご利用ください。
Route 53 Resolver の基本的な仕組みについては、以下の資料が分かりやすく解説しています。
集約構成
本記事で紹介する集約構成は、以下のとおりです。
- 管理アカウントにインバウンドエンドポイントとアウトバウンドエンドポイントを集約
- メンバーアカウントではインバウンド/アウトバウンドエンドポイントを作成せず、管理アカウントのエンドポイントを利用
- アウトバウンドエンドポイントは、リージョンごとに作成
- インバウンドエンドポイントは、1つのリージョンにのみ作成
- メンバーアカウント同士のVPCピアリングやTransit Gatewayによる接続は不要
この構成により、管理アカウントでの一元管理とコスト削減を実現できます。
次に、集約したインバウンドエンドポイントとアウトバウンドエンドポイントでの名前解決の経路と構築方法を解説します。
インバウンドエンドポイントの集約
オンプレミスのサーバーから AWS 環境内のプライベートドメインで名前解決を行う場合、インバウンドエンドポイントを利用します。
管理アカウントの東京リージョンで Route 53 プライベートホストゾーン（以降、プライベートホストゾーン）を作成し、プライベートドメインを定義します。
集約構成は以下のとおりです。
なお、管理アカウントの大阪リージョンは利用しません。
具体的な名前解決の経路は次のとおりです。
- オンプレミスサーバー → フォワーダー
- フォワーダー → 東京リージョンのインバウンドエンドポイント
- インバウンドエンドポイント → 東京リージョンのプライベートホストゾーン
インバウンドエンドポイントの集約を実現するために必要な構築手順は以下のとおりです。
- 管理アカウントの東京リージョンでプライベートホストゾーンを作成
- 東京リージョンの VPC のみ関連付け
- ドメイン名は
aws.local（任意の名称で可）
- 作成したプライベートホストゾーンでレコードを作成
- 例1：EC2 インスタンスの場合
- 設定内容:
- レコード名:
a-ec2.aws.local - レコードタイプ:
A - 値:
1.1.1.1（EC2 インスタンスのプライベート IP）
- レコード名:
- 設定内容:
- 例2：Amazon RDSの場合
- 設定内容:
- レコード名:
a-rds.aws.local - レコードタイプ:
CNAME - 値:
dev.xxx.ap-northeast-3.rds.amazonaws.com（RDS のエンドポイント）
- レコード名:
- 設定内容:
- 例1：EC2 インスタンスの場合
- 管理アカウントの東京リージョンで、インバウントエンドポイントとエンドポイント用のセキュリティグループを作成
- オンプレミスのフォワーダー設定
aws.localを転送対象に追加- 転送先としてインバウンドエンドポイントの IP アドレスを登録
構築手順は、こちらの記事が参考になります。
この構成では、オンプレミスサーバーから複数リージョンに存在するリソースの名前解決を AWS 側で行う場合、インバウンドエンドポイントが存在する東京リージョンのプライベートホストゾーンにレコードを追加することで実現できます。
インバウンドエンドポイントは複数リージョンに作成する必要はありません。
レコードタイプ
東京リージョンにインバウンドエンドポイントを作成している場合、メンバーアカウントの別リージョン（例: 大阪リージョン）で作成された EC2 インスタンスに対して、以下のようにプライベート IP の DNS 名を設定しても名前解決できません。
- レコード名:
a-ec2.aws.local - レコードタイプ:
CNAME - 値:
ip-1-1-1-1.ap-northeast-3.compute.internal
理由は、Route 53 Resolver（AWSのDNSサーバー）は、デフォルトで同一リージョン内のプライベートDNS名のみを解決するためです。東京リージョンの EC2 インスタンスは名前解決可能ですが、別リージョンの EC2 インスタンスは解決できません。
プライベート IP DNS 名 (IPv4 専用) のホスト名は、同じ VPC 内のインスタンス間の通信に使用できます。インスタンスが同じ AWS リージョンにあり、他のインスタンスのホスト名が RFC 1918 によって定義されたプライベートアドレス空間の範囲内にある限り、他の VPC 内の他のインスタンスのプライベート IP DNS 名 (IPv4 のみ) のホスト名を解決できます
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/AmazonDNS-concepts.html
そのため、大阪リージョンのEC2 インスタンスでは、プライベート IP を直接指定する必要があります。
- レコード名:
a-ec2.aws.local - レコードタイプ:
A - 値:
1.1.1.1（EC2 インスタンスのプライベート IP）
ただし、Amazon RDS や内部 Application Load Balancer（ALB）などの場合、RDS エンドポイントおよび内部 ALB の DNS 名はいずれもインターネット経由で名前解決され、プライベート IP が返ります。
そのため、RDS のエンドポイントや内部 ALB の DNS 名については、別リージョンであっても CNAME レコードを設定すれば名前解決が可能です。
- レコード名:
a-rds.aws.local - レコードタイプ:
CNAME - 値:
dev.xxx.ap-northeast-3.rds.amazonaws.com
RDS のインスタンスの IP は動的に変わるため、CNAMEレコードタイプで名前解決ができるのは利点です。
一方、EC2 インスタンスのプライベート IP は基本的に固定されているため、IP アドレスを直接指定してレコードを作成しても問題になりにくいと考えられます。
大阪リージョンでもEC2 インスタンスのプライベート DNS 名の指定が必須の場合、管理アカウントの大阪リージョンでインバウンドエンドポイントを作成する必要があります。
アウトバウンドエンドポイントの集約
AWS 側のリソース（EC2 など）からオンプレミスのネームサーバーで名前解決を行う場合、アウトバウンドエンドポイントと Resolver Rule を利用します。
AWS Resource Access Manager（以降、RAM）を利用することでResolver Ruleをメンバーアカウントにも共有できます。
集約構成は以下のとおりです。
具体的な名前解決の経路は次のとおりです。
- メンバーアカウントの EC2 インスタンス → Route 53 Resolver
- Route 53 Resolver → アウトバウンドエンドポイント
- アウトバウンドエンドポイント → オンプレミスのネームサーバー
アウトバウンドエンドポイントの集約を実現するために必要な構築手順は、下記の通りです。
- 管理アカウントで、セキュリティグループとアウトバウンドエンドポイントを作成します。
- 管理アカウントで、Route 53 Resolver Ruleを作成します。
- ドメイン名：
example.org - Resolver RuleをVPC：任意（管理アカウントのVPC上のリソースには適用不要であれば、選択しない）
- アウトエンドポイント：作成したアウトエンドポイントを選択
- ターゲット IP アドレス：転送先であるオンプレミスのネームサーバーのIPアドレス
- ドメイン名：
- 管理アカウントで作成したResolver Ruleをメンバーアカウントでも利用できるように、Resolver Ruleを共有するRAMを作成します。
- メンバーアカウント側で、メンバーアカウントのVPCにResolver Ruleを関連付けます
以下の記事を参考にしてください。
[補足1] アウトバウンドエンドポイントのセキュリティグループの設定は、インバウンドルールが不要で、アウトバウンドルールは以下の通りです。
対して、インバウンドエンドポイントのセキュリティグループの設定は、アウトバウンドルールが不要で、インバウンドルールは以下の通りです。
| タイプ | プロトコル | ポート範囲 | ソース（CIDR） | 備考 |
|---|---|---|---|---|
| DNS(TCP) | TCP | 53 | x.x.x.x/32 | ネームサーバー |
| DNS(UDP) | UDP | 53 | x.x.x.x/32 | ネームサーバー |
[補足2] インバウンド/アウトバウンドエンドポイントを作成したサブネットに関連付けられたルートテーブルには、オンプレミスへのルートを設定してください。
| 送信先 | ターゲット | 備考 |
|---|---|---|
| x.x.x.x/32 | vgw-xxxxx | 送信先はネームサーバーのIPアドレス |
別リージョン
RAM はリージョナルサービスのため、東京リージョンの Route 53 Resolver Rule を大阪リージョンに共有することはできません。
AWS RAM はリージョナルサービスです。共有するプリンシパルは、リソース共有が作成された AWS リージョン でのみリソース共有にアクセスできます。
https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/getting-started-sharing.html
そのため、大阪リージョンの EC2 インスタンスからオンプレミスのネームサーバーで名前解決を行う場合、管理アカウントの大阪リージョンでアウトバウンドエンドポイントを作成します。
先ほどの 4 つの手順を実施することで、リージョン単位での集約が可能です。
複数のドメイン名
メンバーアカウントによっては、example.org だけでなく、別のドメイン名（example.com）もオンプレミスのネームサーバーで名前解決を行いたい場合、以下の手順で追加します。
- 管理アカウントで、Route 53 Resolver Rule を作成します。
example.orgとは異なるオンプレミスのネームサーバーの場合、ターゲット IP が異なるため、アウトバウンドエンドポイントのセキュリティグループにルールを追加し、ルートテーブルにもルートを追加します。- 既存のアウトバウンドエンドポイントを利用します。
example.orgの Resolver Rule を共有した既存の RAM にexample.comの Resolver Rule を追加するか、新規の RAM を作成して Resolver Rule を共有します。- メンバーアカウント側で、メンバーアカウントの VPC に Resolver Rule を関連付けます。
最後に
本記事では、マルチアカウント環境における複数リージョンでの Route 53 Resolver エンドポイントの集約方法について解説しました。
インバウンドエンドポイントは 1 つのリージョンに集約し、プライベートホストゾーンを活用することで、オンプレミスからの名前解決を効率化できます。
一方、アウトバウンドエンドポイントはリージョンごとに作成し、Resolver Rule を RAM で共有することで、メンバーアカウントのリソースも統一的に管理できます。
組織の要件に応じて適切な構成を選択するにあたり、参考になれば幸いです。
