AWS Route 53 Resolver で複数のドメインを扱うときは、「ドメインごとに転送ルールを作り、どの VPC にどのルールを関連付けるか」で管理します。社内 DNS で解決する corp.example.com はオンプレミスへ、AWS 内部の名前はプライベートホストゾーンで、それ以外はインターネットへ、という振り分けを、ルールと関連付けの組み合わせで表現するのが基本です。この記事では、ドメインが増えても見通しを保てるルールの分け方、優先順位の考え方、複数の VPC やアカウントへの配り方を説明します。
AWS のサービス仕様とコンソールの表記は更新が多いため（2026年10月現在）、コマンドは例として、実行前に AWS の公式ドキュメントで引数を確認してください。料金は扱いません。
Route 53 Resolver が担当するもの、しないもの
最初に役割を整理しておきます。Route 53 Resolver は、VPC 内の EC2 などが名前を問い合わせたときに答える「VPC 用のキャッシュ DNS（リゾルバ）」です。VPC の CIDR の先頭アドレスに2を足したアドレスや 169.254.169.253 で利用できる、いわゆる AmazonProvidedDNS がこれにあたります。
一方、example.com のレコードをインターネットに公開する「権威 DNS」は、Route 53 のホストゾーンの役割です。公開サイトのドメインを複数管理したいだけなら、Resolver ではなくドメインごとに公開ホストゾーンを作ります。
Resolver で「複数ドメインを管理する」とは、VPC の中からの問い合わせを、ドメインごとに正しい答えの出どころへ振り分けることを指します。たとえば次のような状況です。
- VPC 上の WordPress が、オンプレミスの社内 DNS でしか引けない社内システムの名前を参照する
- 複数の社内ドメイン（corp.example.com、legacy.example.net など）が、別々の DNS サーバーで管理されている
- AWS 内部の DB には、プライベートホストゾーンで db.internal.example.com のような名前を付けている
振り分けを決める3つの仕組み
転送ルール（FORWARD）
指定したドメインとそのサブドメインへの問い合わせを、指定した IP アドレスの DNS サーバーへ転送するルールです。転送はアウトバウンドエンドポイント経由で行われるため、先にアウトバウンドエンドポイントを作成しておきます。
システムルール（SYSTEM）
指定したドメインは転送せず、Resolver 自身で解決させるルールです。「corp.example.com は全体をオンプレミスへ転送するが、その下の aws.corp.example.com だけは AWS 側のプライベートホストゾーンで答えたい」といった例外を作るときに使います。
プライベートホストゾーン
VPC に関連付けた非公開のゾーンです。関連付けた VPC の中からだけ引ける名前を定義できます。プライベートホストゾーンを使うには、VPC の DNS 解決（enableDnsSupport）と DNS ホスト名（enableDnsHostnames）の設定を有効にしておく必要があります。
優先順位：いちばん具体的なルールが勝つ
一つの問い合わせに複数のルールが当てはまる場合、Resolver はドメイン名が最も具体的に一致するルールを使います。
ルール1 corp.example.com FORWARD → 10.10.0.10, 10.10.0.11（社内DNS）
ルール2 aws.corp.example.com SYSTEM（Resolver が自分で解決）
ルール3 legacy.example.net FORWARD → 10.20.0.53（別の社内DNS）
問い合わせ 使われるルール
app.corp.example.com ルール1（社内DNSへ転送）
db.aws.corp.example.com ルール2（プライベートホストゾーン等で解決）
www.legacy.example.net ルール3
www.example.org どれにも当たらない → 通常のインターネット向け解決この性質を使うと、ドメインの階層ごとに「大きく転送して、例外だけ SYSTEM で戻す」設計ができます。逆に、同じ範囲を指すルールがアカウントや担当者ごとにばらばらに作られると、どれが効いているかが分かりにくくなります。ドメインと転送先の一覧を表にして、ルールの名前にもドメインを含めておくと管理しやすくなります。
なお、同じドメインに転送ルールとプライベートホストゾーンの両方がある場合は、転送ルールが優先されると公式ドキュメントで説明されています。意図せず重ねると、プライベートホストゾーンのレコードが引けなくなるので、重複は避けるか、SYSTEM ルールで明示的に切り分けます。
設定の流れ（AWS CLI の例）
アウトバウンドエンドポイントを作る
エンドポイントには2つ以上の IP アドレスが必要で、異なるアベイラビリティーゾーンのサブネットに置くのが基本です。セキュリティグループでは、転送先 DNS への TCP と UDP の 53 番の通信を許可します。
aws route53resolver create-resolver-endpoint \
--name outbound-corp \
--creator-request-id outbound-corp-001 \
--direction OUTBOUND \
--security-group-ids sg-0123456789abcdef0 \
--ip-addresses SubnetId=subnet-aaaa1111 SubnetId=subnet-bbbb2222ドメインごとに転送ルールを作る
# corp.example.com を社内DNS（2台）へ転送するルール
aws route53resolver create-resolver-rule \
--name fwd-corp-example-com \
--creator-request-id fwd-corp-001 \
--rule-type FORWARD \
--domain-name corp.example.com \
--resolver-endpoint-id rslvr-out-0123456789abcdef0 \
--target-ips "Ip=10.10.0.10,Port=53" "Ip=10.10.0.11,Port=53"
# aws.corp.example.com だけは転送せず Resolver で解決するルール
aws route53resolver create-resolver-rule \
--name sys-aws-corp-example-com \
--creator-request-id sys-aws-corp-001 \
--rule-type SYSTEM \
--domain-name aws.corp.example.comID や IP アドレスは自分の環境のものに置き換えます。ドメインが増えたら、同じ形でルールを1つずつ足していきます。
ルールを VPC に関連付ける
ルールは作っただけでは効きません。使わせたい VPC に関連付けて初めて、その VPC からの問い合わせに適用されます。
aws route53resolver associate-resolver-rule \
--resolver-rule-id rslvr-rr-0123456789abcdef0 \
--vpc-id vpc-0123456789abcdef0 \
--name corp-to-prod-vpc「ある VPC ではこのドメインを引けるが、別の VPC では引けない」という差は、この関連付けの有無で生まれます。引けない VPC があるときは、まず関連付けを確認します。
複数の VPC・アカウントへ配る
AWS RAM でルールを共有する
アカウントが分かれている場合、ルールを各アカウントで作り直すと、転送先が変わったときに修正漏れが起きます。ネットワーク管理用のアカウントでルールを作り、AWS Resource Access Manager（RAM）でほかのアカウントへ共有すると、ルールの定義は一か所に保ったまま、各アカウントで自分の VPC へ関連付けられます。
プライベートホストゾーンを別アカウントの VPC に関連付ける
プライベートホストゾーンを別アカウントの VPC で使う場合は、ゾーンを持つアカウントで関連付けを許可し、VPC を持つアカウントで関連付けを行う、という二段階の手順になります。
# ゾーンを持つアカウントで実行
aws route53 create-vpc-association-authorization \
--hosted-zone-id Z0123456789EXAMPLE \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-0fedcba9876543210
# VPC を持つアカウントで実行
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id Z0123456789EXAMPLE \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-0fedcba9876543210Route 53 Profiles も選択肢
VPC やアカウントが多い環境向けに、Resolver のルール、プライベートホストゾーン、DNS Firewall の設定などをまとめて VPC に適用する Route 53 Profiles という機能も提供されています。対応している設定の範囲や制約は更新されているため、採用前に公式ドキュメントで確認してください。
引けないときの確認手順
VPC 内の EC2 から、Resolver 経由で問い合わせて確認します。
# VPC の Resolver に問い合わせる
dig app.corp.example.com @169.254.169.253 +noall +answer
# 転送先の社内DNSに直接問い合わせて、答えそのものがあるかを見る（到達できる場合）
dig app.corp.example.com @10.10.0.10 +noall +answer原因として多い順に確認します。
- ルールが VPC に関連付けられていない: 対象 VPC の関連付け一覧にルールがあるか。
- 通信が通っていない: アウトバウンドエンドポイントのセキュリティグループ、ネットワーク ACL、VPN や Direct Connect の経路、社内 DNS 側のファイアウォールで、TCP と UDP の 53 番が許可されているか。
- より具体的なルールに吸われている: 上位や下位のドメインに別のルールがないか。
- 社内 DNS が答えていない: 転送先に直接問い合わせても答えが無い場合は、DNS サーバー側のレコードや再帰問い合わせの許可範囲を確認します。
Resolver のクエリログを有効にすると、どの問い合わせがどう処理されたかを CloudWatch Logs などに記録でき、原因の切り分けに役立ちます。
まとめ
- Route 53 Resolver は VPC 用のキャッシュ DNS で、公開ドメインのレコード管理はホストゾーンの役割です。
- 複数ドメインは「ドメインごとの転送ルール」と「VPC への関連付け」で管理し、例外は SYSTEM ルールで切り出します。
- 一つの問い合わせには最も具体的なルールが適用されます。転送ルールとプライベートホストゾーンの重複は避けます。
- アカウントが分かれている場合は、ルールを RAM で共有して定義を一か所にまとめると修正漏れを防げます。
- 引けないときは、関連付け、53 番の通信、ルールの重なり、転送先の答えの順に確認します。