この記事は「2026 Japan AWS Jr.Champions 真夏のQiitaリレー」の12日目の記事となります。
過去の投稿（リンク集）はこちらからご覧ください。
https://qiita.com/ys-yoshida/private/6f7c7f85155a993e2c86
あくまで個人検証の結果になります。
必ずしも本記事の構成が最適とは限りませんのでご注意ください。
はじめに
オンプレからVPCへの名前解決においてオンプレのフォワーダー先（条件付きフォワーダーも含む）をなるべく一つに向けるという観点で設計・検証をしてみました。
前程知識
前程知識としてVPCが単体の場合です。
VPCが単体の時はとても単純でInboundEndpointにフォワーダーを向けるだけで名前解決が可能です。
AWSに向ける名前の種類
オンプレからAWSに向ける名前の種類として主に2種類あります。
それぞれ対応方法が変わってくるので、次の項から順番に解説します。
1. AWSサービス接続時に使用する名前
xxxxxxxxxxxx.s3.ap-northeast-1.amazonaws.com 等
2. 独自ドメイン名
1. AWSサービス接続時に使用する名前
AWSサービスの名前解決を行いたいときはRoute53 ResolverのResolver Ruleを使用します。
Resolver Ruleを設定することでDNSクエリの転送を行い、他VPCへの振分けを行います。
各VPCにInbound Endpointと転送元のVPC（画像ではVPC-A）にOutbound Endpointが必要です。
Resolver Ruleでは転送元と先のVPC間で直接接続を行う経路を確保する必要があります。
各VPC間の直接通信が問題ないか要件やポリシーを確認することをお勧めします。（設計方針が変わるため）
接続の選択肢としてVPC Peeringの接続やTransit Gatewayでの接続等があります。
Transit Gateway（TGW）のルートについて（おまけ）
検証時にTGWルートテーブルの作り方によるVPC間の接続不可に遭遇しました。
当初、下記のようにVPC用のルートテーブルを共同利用するような構成をとっていました。
この構成だと各TGWアタッチメントに自分以外のVPCへの経路がないためオンプレ-VPC間の接続しかできません。
（これがTransit Gatewayのいいところでもありますが...）
各TGWアタッチメントに自分以外のVPCへのルートを持たせるために、TGWルートテーブルを各VPCごとに作成・関連付けし、それらを伝播させる構成へと変更しました。
このような構成にすることで、VPC間の経路上全てにVPCへのルートが入るため経路が確保・Resolver Ruleの転送も成功できます。
2. 独自ドメイン名
独自ドメイン名の名前解決では、Inbound EndpointとPrivate Host Zone（PHZ）を使用します。
今回はHUB用のVPCを用意し各VPCのPHZをHUBにも関連付けるという構成を採用してみました。
この構成をとることでトータルのInbound Endpointの数を1つに抑えられるためコスト的にもメリットがあるのではと考えています。
2案の比較
| AWSサービスの名前解決を集約 | 各VPCの複数独自ドメイン（PHZ）を集約 | |
|---|---|---|
| 選ぶ案 | Resolver Ruleでの転送 | PHZをHUB用VPCに集約 |
| オンプレのフォワーダー先 | 1つ（VPC側で転送） | 1つ |
| VPC間経路の確保 | 必要（Peering / TGW等） | 不要（PHZ関連付けのみ） |
| Inbound Endpoint | VPCごとに必要 | HUB用VPCに1つのみ |
| 新VPC追加時の手間 | 経路とルール追加が必要 | PHZをHubに関連付け+新しい独自ドメインへのフォワーダーを追加 |
まとめ
オンプレのフォワーダー先を1つにまとめるという観点でDNS設計・検証を行ってみました。
Resolver Rule案についてはVPC間の直接通信が必要になるので、組織をまたいでいる場合だとセキュリティ要件にもよりますがあまり現実的ではないと感じました。
複数VPC間でのDNS共有はマルチアカウントでの実現の方が多いかもしれないですが、DNS・NW設計の基本として参考になれば幸いです。