ある金融サービス企業は、AWS Organizations 配下の 80 個の AWS アカウントにわたるハブアンドスポーク型ネットワークアーキテクチャを構築しています。Networking アカウントがハブとして Transit Gateway（TGW）を所有しています。以下の要件があります。 【要件】 1. すべてのワークロード VPC（スポーク）は、Networking アカウントで終端する AWS Direct Connect を経由してオンプレミスデータセンターと接続する。 2. ワークロードアカウント間の VPC 間通信はすべて、Shared-Services アカウントに配置した AWS Network Firewall による一元的な検査レイヤーを必ず経由してから宛先に到達する。デフォルトで VPC 間通信はすべてブロックし、検査後に明示的に許可されたトラフィックのみ疎通させる。 3. Shared-Services アカウントで稼働する Route 53 Resolver を使用した内部 DNS 名前解決サービスを全ワークロードアカウントで利用可能にする。 4. 新規ワークロードアカウントがアカウント払い出しプロセスでプロビジョニングされると、ネットワーク接続が 2〜3 週間ではなく数分以内に自動確立される。 【現状の課題】 ネットワークアタッチメント・ルートテーブル設定・DNS リゾルバールール共有は現在すべて手作業で実施されており、複数チーム間のハンドオフにより新規アカウントあたり 2〜3 週間を要している。 すべての要件を最もよく満たすソリューションはどれですか？
選択肢AがRAMでTGWを組織全体に共有し、専用インスペクションアタッチメント経由でNetwork Firewallにスポーク間通信を通すハブアンドスポーク設計で全要件を満たします。Route 53 ResolverルールのRAM共有でDNSを一元管理でき、Service CatalogによるCloudFormation製品の自動実行でオンボーディングを数分に短縮できます。 選択肢BのVPCピアリングは80アカウント規模ではフルメッシュになり管理が不可能です。NACLはステートレスなパケットフィルタであり、Network Firewallによるインライン検査の代替にはなりません。 選択肢CのGWLB＋サードパーティアプライアンス方式は各VPCへのGWLBエンドポイント追加とアプライアンス管理の運用負荷が高く、アカウントごとの個別Route 53 ResolverではShared-ServicesアカウントによるDNS集中管理を満たせません。 選択肢Dの各ワークロードアカウントへの個別TGW作成はコストと管理複雑性が著しく高く、80アカウント規模では非現実的です。 選択肢EのPrivateLinkはインライントラフィック検査には不向きであり、Route 53 ResolverルールのRAM共有が標準アプローチであるためPrivateLink経由のDNS共有は非標準かつ構成が複雑になります。