ANS-2.3複雑なハイブリッドおよびマルチアカウント DNSアーキテクチャを実装する。

ヒントボタン

Route 53 Resolver のアウトバウンドエンドポイントは 1 つで 10,000 QPS を処理でき、2AZ に冗長配置すると RTO 5 分以内で自動フェイルオーバーが可能です。共有サービス VPC に中央集約し Transit Gateway で 8 VPC を接続すれば、Direct Connect 越しでも安定した転送が行え、EC2/BIND を各所に置くよりコストと運用が大幅に軽減されます。マネージドサービスなので OS パッチやスケール調整は不要、CloudWatch で健全性も可視化でき、Well-Architected Framework の運用優秀性にも合致します。

オンプレドメインを参照できる VPC を限定したい場合は、Route 53 Resolver で corp.example.com のフォワードルールを作成し、AWS Resource Access Manager で開発用 2 VPC のみに関連付ける方法がシンプルです。ルールをデフォルトにすると全 VPC が転送してしまうため要件を満たせません。RAM ならマルチアカウントでも一度の設定で共有でき、VPC が増減しても関連付けを更新するだけで統制が保てるため、運用負荷を最小限に抑えられます。

オンプレから Private Hosted Zone を解決させるには Route 53 Resolver インバウンドエンドポイントを 2AZ に設置し、その IP をオンプレ DNS の条件付き転送先に設定するのが推奨です。アウトバウンド転送で開発 VPC だけが corp.example.com を引き、インバウンド経由でオンプレが VPC 内レコードを引ける双方向モデルを中央集約で実現することで、10,000 クエリ毎秒・RTO 5 分・マルチアカウント対応・最小運用負荷という複数の要件を総合的に満たせると判断できます。

ヒントボタン

社内の 3 つの VPC をまたいで corp.example.com を解決しながら運用をまとめるには、Route 53 Resolver のアウトバウンドエンドポイントを shared-services VPC に 2 AZ 冗長で置き、corp.example.com への転送ルールを作成して AWS Resource Access Manager で prod・dev VPC に共有すると、設定箇所が 1 か所で済み料金も抑えられます。
オンプレミスから aws.internal.example.com など Private Hosted Zone を引けるようにするには、同じ VPC に Route 53 Resolver インバウンドエンドポイントを追加し、その ENI の IP をオンプレミス AD DNS の条件付きフォワーダー先に指定します。Transit Gateway でレイヤ 3 接続があるため UDP/TCP 53 だけで往復でき、BGP や DNS Suffix の調整は不要です。
1 万 QPS と 20 ms 以内という厳しい指標を考えると、EC2 上の BIND や NAT Gateway 越しの方式より Route 53 Resolver のマネージド自動スケールと 2AZ 配置が高可用・低遅延です。Transit Gateway の DNS オプションは AmazonProvidedDNS 透過用で条件転送に使えません。集中管理・性能・コストを俯瞰し、マネージドサービスを軸に設計するのが最も合理的でしょう。

ヒントボタン

20 以上のアカウントがある環境で Route 53 Resolver エンドポイントを各 VPC に個別設置すると、エンドポイントごとに ENI と料金が増え Direct Connect 帯域も圧迫します。Resolver ルールは AWS RAM でクロスアカウント共有できるため、共有サービス VPC にアウトバウンドとインバウンドを 1 セットだけ用意し全 VPC へルールを配布すれば、追加アカウント時に増設作業が発生せずコストと運用負荷を大きく抑えられます。

VPC 内の名前解決は基本的に AmazonProvidedDNS 169.254.169.253 を使い続けたい一方、corp.example.com だけをオンプレ AD DNS 10.0.0.10/11 に振り分けるには Route 53 Resolver の条件付き転送が最適です。アウトバウンドエンドポイントに該当ドメインと転送先を登録し、各 VPC は既定の DHCP オプションセットを維持すれば、EC2 の IMDS や SSM など AWS サービス向け通信に影響を与えずにハイブリッド DNS を実現できます。

オンプレから *.int.aws を解決させるには Direct Connect 経由で VPC へ問い合わせが届く必要があり、Resolver インバウンドエンドポイントの IP を AD DNS の条件付き転送先に設定する方法が確実です。DHCP オプションでプライマリ／セカンダリを切り替える案や Private Hosted Zone のゾーン転送は仕様面で要件を同時に満たせないため、三つの要件を俯瞰し集中管理・コスト効率・機能要件を総合的に満たす構成を選択することが最終判断のポイントとなります。

ヒントボタン

オンプレのAD DNSからProd側のFQDNを引かせるには、AWSに着信口を用意するのが核心です。Route 53 ResolverインバウンドエンドポイントをSharedSvc VPCにマルチAZで配置し、そのIPを条件付きフォワーダとしてADに登録すればDirect ConnectやTransit Gateway経由でapp.prod.awsクエリが到達し、プライベートホストゾーンの応答を返せます。BINDサーバをAuto Scalingで並べるよりパッチ管理・障害対応が不要で、単一点障害も避けやすい構成になります。

VPCからcontoso.localを引かせるには逆向きの経路が欠かせません。Route 53 Resolverアウトバウンドエンドポイントを同じSharedSvc VPCに2AZで置き、転送規則でcontoso.localをオンプレADにフォワードします。転送規則はAWS RAMでProd VPCへ共有すればマルチアカウントで共通利用でき、TerraformなどIaCでリージョンを追加する際もハブ構成を複製するだけです。各VPCに個別にアウトバウンドEPを作らずとも双方向解決が成立し、管理負荷を抑制できます。

最終的には「SharedSvcにインバウンド＋アウトバウンド＋転送規則、Prodにプライベートホストゾーン」という役割分担を採ることで、オンプレ→AWSとAWS→オンプレの名前解決、高可用性、リージョン拡張性という複数の要件を俯瞰しながら満たせます。Route 53 Resolverのマネージド性と2AZ冗長を活かし、最小構成で運用と拡張のバランスを最適化する視点が決め手となります。

ヒントボタン

Route 53 のサブドメイン委任機能を利用し、アプリケーションアカウント側で api.example.com のパブリックホストゾーンを新規作成して得られたネームサーバーを親ドメイン example.com の NS レコードに登録すると、子ゾーン内で A・CNAME・TXT などを自由に操作して ACM の DNS 検証まで自己完結できる一方、ネットワーク共有アカウントが扱うのは NS レコードのみとなるためルートレコードの誤操作リスクを抑えられ、DNS 標準に沿ったシンプルな運用が実現できます。

AWS RAM で example.com 全体を共有し IAM で api.* 以外を書き込み禁止に見せ掛けても ChangeResourceRecordSets にはレコード名を細粒度に制御する Condition が無く意図せぬ apex や MX の変更を招きやすく、5 億クエリが親ゾーンへ加算されることで Route 53 のクエリ課金も跳ね上がるため、サブドメインを独立ホストゾーンとして切り出してクエリ課金と運用権限を分離する設計の方が安全かつ経済的です。

Route 53 Resolver フォワーダールールは VPC 内のプライベート DNS 転送用でパブリックには効かず、リリース都度 CNAME 申請を挟む運用は DevOps の自律性を損ねるため、親ゾーン保護・ACM の自己完結・月間 5 億クエリ時のコスト最小化という複数要件を俯瞰するとサブドメインを独立ゾーン化し NS で委任する構成が最もバランスに優れています。

ヒントボタン

内部ドメインを多アカウント・多リージョンで一元管理するなら、Route 53 の Private Hosted Zone を中央に１つだけ作成し、AWS Resource Access Manager で 12 個の VPC へ共有する方式が王道です。ゾーンの書き込み権限は Shared Services 側の IAM に集約でき、他アカウントは参照専用となるため「単一の信頼ソース」と「変更主体の限定」を同時に実現できます。また Private Hosted Zone はリージョンをまたいでも同一オブジェクトとして機能し、Route 53 のエッジキャッシュが遅延を最小化してくれるので、重複ゾーンを複製する必要がなく運用もシンプルです。

オンプレミスからの毎秒 1,000 クエリを 2 秒以内で返すには、Direct Connect 経由のフォワーダが Route 53 Resolver インバウンドエンドポイントへ条件付き転送する構成が高性能かつ簡潔です。インバウンド EP は各リージョンで 2AZ に配置でき、背後でオートスケールするためクエリ量が増えても対応可能です。さらにリージョンを横断して複数の EP を設定しておけば、あるリージョンが停止しても他リージョンが応答を続けるため、高い可用性とレイテンシ要件の両立が図れます。

EC2 や BIND を自前で運用すると Auto Scaling、NLB、rsync など管理対象が急増しコストも跳ね上がりますが、Route 53 と Resolver はフルマネージドで従量課金のため最小構成でも冗長性が確保できます。Shared Services 内の PHZ を AWS RAM で共有し、各リージョンに Resolver 受け口だけを分散させる設計は、重複禁止・権限集中・高速応答・低運用負荷という複数要件を総合的に満たす最もバランスの取れたアプローチといえます。

ヒントボタン

IPv6 専用の EC2 から IPv4 しか持たないオンプレミスへ流すには NAT64 が不可欠です。VPC で DNS64 を有効にすると名前解決で 64:ff9b::/96 が付いたアドレスが返り、プライベート NAT Gateway はこのプレフィックス宛パケットだけを IPv4 に変換して Direct Connect へ転送でき、インターネットを経由しません。

マネージドサービスを使えば EC2 の運用が要らず簡潔です。プライベート NAT Gateway は AZ 単位で配置できるため、2 つのアベイラビリティーゾーンに用意すれば自動的に冗長化されます。Route Table に 64:ff9b::/96 だけを向ければ他の IPv6 トラフィックは Direct Connect や VPC 内でそのまま流れ、シンプルな経路制御で済みます。

パブリック NAT Gateway は IGW 経由、Egress-only Internet Gateway は IPv6→IPv6 専用であり、いずれも Direct Connect のプライベート宛先と合致しません。デュアルスタック化は追加 IPv4 管理とセキュリティ工数を招きます。レイテンシ許容 5 ms、運用負荷削減、AZ 冗長、経路の単純さという複数要件を俯瞰すると、DNS64 とプライベート NAT Gateway の組み合わせが最も整合します。

ヒントボタン

Interface Endpoint Service と NLB のデフォルト Private DNS 名を Route 53 の Private Hosted Zone に CNAME でマッピングすると、payments.api.corp.internal だけで 50 VPC 全てが接続できます。各 VPC は Private DNS によりエンドポイント ID を意識せず済み、プライベート通信のまま統一的に名前解決できるため管理が大幅に簡素化されます。

Hosted Zone をネットワークサービスアカウントで保持し、AWS RAM によってワークロード VPC と共有すると、レコード編集権限は IAM でそのアカウントだけに限定できます。共有先は読み取り専用で利用でき、追加 VPC が発生しても Zone Association を行うだけで即座に同じ FQDN が機能するため、DNS 運用と権限制御が一元化されます。

オンプレミスへ名前を公開しない要件と費用最適化を両立させるには、Route 53 Private Hosted Zone の VPC 内限定スコープを活用し、Resolver エンドポイントや自前 BIND を増やさない構成が有利です。AWS RAM の共有機能とマネージド DNS を組み合わせることで、セキュリティ、運用負荷、コストの各条件を総合的に満たす設計が浮かび上がるはずです。

ヒントボタン

運用負荷を抑えるには、3 アカウント10 VPC それぞれに Route 53 Resolver を置くより、共有サービス VPC を 1 か所用意し、そこへマルチ AZ で Resolver インバウンド／アウトバウンドエンドポイントを配置する設計が効果的です。エンドポイント・転送ルール・プライベートホストゾーンを AWS RAM で全 VPC へ共有すれば、更新は中央スタックだけで完結し運用を大幅に簡素化できます。

全 DNS クエリを 4000 QPS 規模で監査するには、Route 53 Resolver Query Logging を有効化し S3 や CloudWatch Logs へ一元出力する方法が最もシンプルです。Direct Connect 経由で流入するオンプレミスの問い合わせも同じログに集約でき、複数 VPC が共通アウトバウンドエンドポイントを通る設計にすれば、ログ取得点は 1 か所に固定され監査要件を確実に満たせます。

オンプレミスから AWS ドメインを解決するにはインバウンドエンドポイントが不可欠です。Direct Connect を介しオンプレ DNS から Route 53 Resolver へ問い合わせる流れを作り、corp.internal は共有 VPC に関連付けたプライベートホストゾーンで返答、legacy.local はアウトバウンド転送ルールでオンプレ DNS へフォワードする構成にすると、EC2 やアプライアンスなしで多 AZ 冗長と Terraform など IaC 管理が実現でき、複数要件を俯瞰した総合判断として最も合理的な選択となるでしょう。

ヒントボタン

オンプレの Active Directory DNS が既に corp.example.com を運用している状況で、同じ名前空間に追加レコードだけを置きたい場合は、Route 53 Private Hosted Zone を internal.corp.example.com のサブドメイン専用に作成し親ゾーンには手を触れません。ゾーン切り出しにより権威はオンプレと AWS で分担でき、他の SRV や A レコードには影響せず、金融系の厳格な変更管理でも差分を極小化できます。これが最小限の手間で実現できる基本方針です。

Interface Endpoint で PrivateLink を公開する際に Private DNS を有効にすると、Route 53 が service.internal.corp.example.com への自動 ALIAS を生成し、Network Load Balancer の DNS 名や ENI の IP 変化を吸収してくれます。さらに AWS RAM で前述の Private Hosted Zone を 3 つの VPC と共有すれば、各アカウントが別々にレコードを持つ必要がなく一元運用が可能です。Private DNS の自動化とゾーン共有を組み合わせることで、接続元がどこでも同一名で解決できる状態を維持できます。

オンプレミスからサブドメインを引けるようにするには Route 53 Resolver インバウンドエンドポイントを配置し、Active Directory に internal.corp.example.com だけを転送する条件付きフォワーダーを設定します。そうすれば他の corp.example.com クエリは従来どおり AD が回答し、指定サブドメインのみ AWS に委譲されます。Private Hosted Zone、PrivateLink の自動レコード、AWS RAM 共有、Resolver 条件付き転送の四要素を全体最適の観点で統合する構成が要件を俯瞰した最もバランスの取れた選択です。

ヒントボタン

ハイブリッド構成で VPC からオンプレの corp.example.internal を解決するには、Route 53 Resolver のアウトバウンドエンドポイントとドメイン転送ルールが必須です。各 VPC のクライアントは 169.254.169.253 に届いた問い合わせを Resolver が受け取り、ルールを参照してオンプレ DNS へ TCP/UDP 53 を転送します。アウトバウンドが無いと経路が途絶え、プライベートホストゾーンや NS 委任だけでは目的の内部ドメインは解決できない点を確認してください。

オンプレ側から VPC のプライベートホストゾーンを引けるようにするには Route 53 Resolver インバウンドエンドポイントを 2 AZ 以上で設置し、オンプレ DNS に条件付きフォワーダーとしてその IP を登録します。マネージド Resolver はパッチ管理不要で 2 万 QPS を処理でき、Direct Connect 経由で冗長に通信するため RTO 1 分の高可用性を EC2 や BIND を自前運用せずに実現できます。

ルール管理を最小化するには shared-svc の 1 箇所にインバウンドとアウトバウンドを集約し、転送ルールを AWS RAM で prod と dev の VPC に共有する方法が有効です。個別エンドポイントや複数フォワーダー設定は運用負荷を増やすだけでメリットが乏しく、マネージドサービスを中心に据えることで高可用性・双方向名前解決・運用簡素化という複数要件を同時に満たす設計を選ぶ総合判断が求められます。

ヒントボタン

オンプレAD DNSとVPC間で双方向に名前解決を行うには、Route 53 Resolverのインバウンドエンドポイントをオンプレからの問い合わせ窓口にし、アウトバウンドエンドポイントをVPCからADへの転送口にするのがAWSの推奨です。Direct Connectで流れるcorp.localの1万QPSも、エンドポイントを2AZに冗長配置すればスループットと可用性を両立でき、svc.aws.internalも条件付き転送で解決できます。エンドポイントはENI単位で水平スケールするため高負荷環境でも安心です。

将来VPCが増えるたびに各VPCへアウトバウンドエンドポイントや転送ルールを配置するとENI数と運用手順が爆発します。Route 53 Resolverは転送ルールやインバウンドエンドポイントをAWS RAMで共有できるので、Shared VPCに1セット置き、他アカウントや新規VPCへ権限共有するだけで自動的に全VPCが名前解決に参加します。2AZ冗長にすれば単一点障害も排除でき、コストも最小です。

リンクローカルアドレス169.254.169.253はBGP広告できずTransit GatewayのL3ルーティングだけではDNSフォワーディングを代替できません。またプライベートホストゾーンを複製しても外部転送は不可能です。DNSレイヤでの条件付き転送を理解し、冗長構成・高QPS対応・運用簡素化・将来拡張という複数要件を俯瞰すると、Shared VPCに集約したRoute 53 ResolverとAWS RAMの組み合わせが最も合理的と判断できます。

ヒントボタン

Route 53 のパブリックホストゾーンを子会社アカウントで api.example.com 名義に作成すると、自動で 4 つの NS レコードが払い出されます。これらを親アカウントの example.com ゾーンに一度だけ登録すればネームサーバ委任が完了し、以後の A・AAAA・TXT などは子会社が TTL 60 秒で自在に更新可能となり、親側の運用は初回登録のみで済みます。

AWS RAM で example.com 全体を共有すると子会社が apex や MX・SPF などまで編集できるためガバナンス上のリスクが高まります。Route 53 は個別レコード単位での権限委譲を提供していないので、サブドメインを独立したホストゾーンに分け NS で委任する設計が「自律運用したいがルートは親が守る」という要望を同時に満たす定石になります。

今回の要件はインターネット公開 ALB への A／AAAA 解決、TTL 60 秒以内の俊敏な切替、そして親の運用負荷最小化の三点です。プライベートホストゾーンや Route 53 Resolver 条件付き転送は公開 DNS では機能せず、親が ALIAS を都度更新する方式は負荷増となります。結果として子会社側にパブリックゾーンを置き NS で委任する方法が複数要件を俯瞰した総合判断でも最適と言えます。

ヒントボタン

Shared アカウントをハブにして Route 53 のプライベートホストゾーンを 1 箇所に集約し、AWS Resource Access Manager で Prod と Dev の VPC に共有すると、ゾーン情報は自動伝搬します。更新は一度の操作で済み、誤配布や人手コピーを排除できるため「集中管理」と「手作業禁止」の両方を満たせます。さらに IAM ポリシーで編集権限を絞れば監査も容易です。

オンプレミスからは media.corp.example.internal だけを解決したい場合、VPN で接続された Shared 側 VPC に Route 53 Resolver インバウンドエンドポイントを置き、社内 DNS に条件付きフォワーダとして登録する手法が有効です。親ドメインを公開せずに済み、他の名前は従来どおり社内 DNS が回答するため不要な通信を抑えつつ要件 3 を満たせます。追加ハードウエアも不要で運用が軽量です。

VPC 内クライアントが AmazonProvidedDNS へ直接問い合わせ、同じ VPC に関連付けたプライベートホストゾーンで応答させればネットワーク横断がなくレイテンシは 20 ms を大きく下回ります。ゾーンを複製したり Systems Manager でレコードを配布する方法は整合性と工数が増え最小構成の要件に反するため、集中管理・低遅延・限定公開を同時に達成できる構成を総合的に選択することが賢明です。

ヒントボタン

Direct Connect 経由でオンプレの DNS から AWS 内プライベート IP を 10 ミリ秒以内に引き当てたい場合、スケーラブルな Route 53 Resolver を経由して AWS バックボーンで応答させる構成が最もレイテンシに有利です。VPC 内の AmazonProvidedDNS はゾーン転送を受け付けず、EC2/BIND を置くと OS 運用やキャパシティ設計が発生するので、毎秒 12000 qps の増分を任せるには完全マネージドのサービスに委ねるほうが安心かつシンプルです。

マルチアカウント・マルチ VPC で名前を一元管理したいときは、共有サービス VPC にひとつだけ Route 53 プライベートホストゾーンを作成し、AWS RAM で他アカウントの VPC を関連付けると、レコード登録が一か所に集約され運用負荷を大幅に削減できます。各 VPC に同名ゾーンを個別配置すると競合が起き解決結果が不定となるため、ベストプラクティスはゾーンの集中とアタッチの共有である点を思い出してください。

オンプレ側の Active Directory DNS は条件付きフォワーダー設定だけで済ませたいという制約があるので、ゾーン転送やパブリック公開を伴う方式は除外されます。Route 53 Resolver 受信エンドポイントを 2 つの AZ に作り、その IP をフォワーダーに登録すれば可用性要件も満たせます。マネージドで AZ 冗長なエンドポイントを使うと障害時のフェイルオーバーやメンテナンスが自動化されるため、設計全体を俯瞰するとこの案が四つの要件を最もバランス良く充足すると判断できます。