アカウント分離戦略 / ネットワーク接続設計難易度 高無料
Organizationsで30アカウント規模のマルチアカウント環境を構築中で、各アカウントのVPC同士を相互接続し、かつ将来のアカウント追加に対しても接続構成の変更を最小限にしたい。VPCピアリングをフルメッシュで構成する初期案に対し、アーキテクトから懸念が示された。この状況を踏まえた最も適切な代替設計を選べ。（単一選択）
- Aネットワーク専用アカウントにAWS Transit Gatewayを構築し、各アカウントのVPCをTransit Gatewayにアタッチするハブアンドスポーク型構成へ変更する。新規アカウント追加時は新しいVPCをアタッチするだけで済む
- B当初案通りVPCピアリングのフルメッシュを維持しつつ、ルートテーブルの管理をInfrastructure as Codeで自動化して運用負荷だけを下げる
- C各VPCにNATゲートウェイを配置し、インターネット経由で他アカウントのVPCへパブリックIP経由でアクセスさせる
- D全アカウントのVPCを単一の巨大なVPCに統合し、サブネットだけでアカウントを区別する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・AIで再検証済
解説
VPCピアリングは1対1の接続であり、n個のVPCを相互接続しようとするとフルメッシュでは
n(n-1)/2 本の接続が必要になる（30 VPCなら435本）。この本数はアカウント/VPCの追加のたびに指数的に増大し、
経路制御・セキュリティグループ・ルートテーブルの管理が破綻しやすい。加えてVPCピアリングは推移的ルーティング
（transitive routing）を許さないため、A-B、B-Cがピアリングされていても、AからCへは直接到達できない
（追加でA-Cのピアリングが必要）という制約もある。
- この課題に対する標準的な解決策がAWS Transit Gatewayである。Transit Gatewayを ネットワーク専用アカウント（Infrastructure/Network account）に構築し、各VPCをTransit Gatewayに アタッチする「ハブアンドスポーク型」構成にすることで、接続本数はVPCの数に比例（n本）で済み、 新規アカウント追加時も新しいVPCをTransit Gatewayにアタッチするだけで済む。
- Transit Gatewayはルートテーブルを使ってVPC間・オンプレミス（Direct Connect/VPN経由）との経路を柔軟に制御でき、 本番/非本番の分離のようなセグメンテーションもTransit Gatewayのルートテーブル単位で実現できる。
- B自動化しても接続本数自体はn(n-1)/2で増大し続け、推移的ルーティングができない制約も解消されない。根本課題（アーキテクチャのスケーラビリティ）には対処できていない。
- Cインターネット経由の通信はプライベートなアカウント間接続として不適切でセキュリティ上のリスクが大きく、コスト・レイテンシの面でも非効率。
- DVPCはアカウント境界をまたいで統合する概念ではない。各アカウントは独立したVPCを持ち、それらを接続するのがTransit Gateway等の役割である。
ひっかけ： 「VPCピアリングは追加コストがかからないので常に最適（誤答の1つ）」という早合点に注意。接続数のスケーラビリティと
推移的ルーティング不可という制約を踏まえると、多数アカウント規模ではTransit Gatewayによるハブアンドスポーク構成が
Well-Architectedな設計として推奨される。
公式ドキュメント・関連Amazon VPC Peering Guide ― VPC peering limitations↗AWS Transit Gateway ― What is Transit Gateway?↗
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）