複数VPCへのDNS設計について考える

Transcript

1. サーカスLT会 #1 @大阪 複数VPCへのDNS設計について考える オンプレ側をいかにシンプルにするかを考え、Resolver Rule と Private Hosted Zone の2案で検証してみた 2026.08.07
2. ABOUT 自己紹介 北島 海叶 @kaiton 株式会社石川コンピュータ・センター 社会人 3年目 21歳 2026 Japan AWS Jr.Champions 2026 Japan All AWS Certifications Engineers 情報処理安全確保支援士 第031611号 @kaiton5tech @kaiton-ton
3. 検証のきっかけ VPCが増えても、オンプレ側をなるべくシンプルに保ちたい 今回は「オンプレDNSのフォワーダー先を1つのVPCに集約する」という観点で検証した VPC A オンプレ DNS ? VPC B VPC C …
4. 前提 単一VPCなら、フォワーダー先は素直に1つで済む オンプレDNS ⇔ Route 53 Resolver（Inbound / Outbound）で双方向に解決できる オンプレ DNS Inbound Active Directory / 条件付きフォワーダで AWS の名前を引く Outbound ⇄ AWS（VPC） .2 リゾルバがVPC内のリソース名を解決／Endpoint で双 方向に橋渡し
5. 検証してわかったこと 先に結論：フォワーダー先は1つに固定し、AWS側で振り分 ける 案 A 案 B Resolver Rule で転送する PHZ を Hub に集約する AWSサービスの名前を引きたいとき。転送はIP到達 独自ドメインを複数VPCで共有したいとき。経路が を伴うので、VPC間の経路が前提。 要らず、新VPCは関連付けるだけ。
6. 案 A 検証 ① → 指針 ① 外部の名前は、VPC側の Resolver Rule で転送する オンプレからは1つのVPCに聞かせ、そこから対象VPCの Inbound Endpoint へ Forward する オンプレ DNS（ 問い合わせ元） フォワーダー先は VPC B の1つだけ → VPC A（受け口） Inbound Endpoint で受け、.2 リゾル バが Resolver Rule に従う Resolver Rule 対 象ドメイン → 転送 → 一見これで複数VPCでも解決できそう — 実際に組んでみると、次の1点でつまずいた。 VPC B（解決先） Inbound Endpoint = 転送先 Target IP 。ここが引きたい名前を持つ
7. 検証 ① の結果 転送を選ぶなら、経路とSGを先に用意する 転送はIP到達を伴う。オンプレ⇔VPC が通っていても、VPC間が通っていなければ timeout した Before：VPC間の経路がない After：VPC間の直接経路を確保する オンプレ ⇔ VPC の通信だけが通る状態。VPC A → VPC Peering を作る、または TGW のルートテーブルで VPC B（Inbound EP）には届かない dig <S3> @.2 → timeout dig amazon.com @.2 → 即 OK VPC間を疎通させる → 両側のルートに相手CIDRを追加 → SG で UDP/TCP 53 を許可 → 名前解決が成立（S3 も解決） 切り分けのコツ：amazon.com が引ければ .2 は正常。転送先の経路とSGだけを疑えばいい。
8. 案 A 検証 ① おまけ（TGWのルート）
9. 案 A 検証 ① おまけ（TGWのルート） こいつらもお互いに伝播させる
10. 案 B 検証 ② → 指針 ② 独自ドメインは、PHZ を Hub に集約して1つの入口にする 各VPCの PHZ を Hub にも関連付け。フォワーダー先＝Hub の Inbound Endpoint 1つで完結 VPC A phz-a.internal オンプレ DNS フォワーダ先は Hub の1 つだけ → Hub VPC Inbound Endpoint × 1 各VPCの PHZ を関連付け 関連付けは経路不要。新VPCが増えても、Hub に関連付けるだけで済む。 ⇠ VPC B phz-b.internal VPC C … phz-c.internal
11. 2案の比較 AWSサービスの名前解決を集約 （xxx.s3.ap-northeast-1.amazonaws.com等） 複数独自ドメイン（PHZ）を各VPC で使用したい 選ぶ案 案 A：Resolver Rule（転送） 案 B：PHZ を Hub に集約 オンプレのフォワーダー先 1つのまま（VPC側で転送） Hub の1つだけ VPC間の経路 必要（Peering / TGW） 不要（関連付けだけ） Inbound Endpoint 解決先ごとに必要 Hub に1つで済む 新VPC追加の手間 経路とルール追加が必要 PHZ を Hub に関連付け＋新しい独自ドメ インへのフォワーダーを追加
12. おすすめの進め方 検証を踏まえると、この順番が迷わない 01 オンプレDNSのフォワーダー先は1つに固定すると決めてから設計に入る 02 引きたい名前を仕分け、独自ドメインは Hub VPC に PHZ を関連付けて入口を1つに寄せる 03 04 外部の名前が必要な分だけ、経路（Peering / TGW）と SG の 53 番 を用意してから Resolver Rule を 作る つながらないときは dig amazon.com @.2 から。引ければリゾルバは正常、疑うのは経路とSG
13. まとめ オンプレの入口を1つに集約する時、解決した い対象でAWS側の受け方を選ぶ IP転送で聞かせる（VPC間の経路が要る）か、PHZの関連付けで聞かせる（経路が要らない）か 案 A：Resolver Rule で転送 案 B：PHZ を Hub に集約 AWSサービスの名前解決。VPC間の直接経路とSGの53番 複数独自ドメインを各VPCで使う。経路不要、Inbound が前提。 Endpoint は Hub に1つ。