ある製造業のグローバル企業は、AWS Organizationsで管理された80のAWSアカウントを保有しています。NetworkAccount という専用ネットワーク管理アカウントには、東京（ap-northeast-1）とバージニア北部（us-east-1）それぞれに1Gbps AWS Direct Connect接続があります。 [現状の課題] ・各 Workload アカウントがオンプレミスへの Site-to-Site VPN（合計80本）を個別に管理しており、BGP（Border Gateway Protocol：ネットワーク間のルーティングプロトコル）ルートテーブルが肥大化している ・SharedServices アカウント（Active Directory・DNS・監視ツール）へのアクセスが非効率 ・一部の Workload アカウント VPC 間で意図しない通信が発生している [要件] ① ネットワーク管理を NetworkAccount に完全集中化する ② 全 Workload アカウントの VPC がオンプレミスの東京・NY両拠点に到達できること ③ Workload アカウントの VPC 同士は直接通信不可（SharedServices アカウントの VPC 経由のみ許可） ④ SharedServices アカウントの各サービスは全 Workload アカウントの VPC からアクセス可能 ⑤ Workload アカウント側への設定変更を最小化する これらの要件を満たす最も適切なネットワーク設計はどれですか？
正解： NetworkAccount に Transit Gateway を作成し、AWS RAM（Resource Access Manager）で Transit Gateway を全 Workload アカウントおよび SharedServices アカウントと共有する。NetworkAccount に Direct Connect Gateway を作成して両リージョンの Direct Connect 仮想インターフェース（VIF）を関連付け、さらに Direct Connect Gateway を Transit Gateway に関連付ける。Transit Gateway に「Workload 用ルートテーブル」（オンプレミスと SharedServices VPC へのルートのみ）と「SharedServices 用ルートテーブル」（全宛先へのルート）の2種類を作成する。Workload アカウントの VPC アタッチメントを Workload 用ルートテーブルに関連付け、ブラックホールルートで Workload 間の直接通信を遮断する。 Transit Gateway を AWS RAM（Resource Access Manager）で Workload アカウントと共有することで、Workload アカウント側の変更は VPC アタッチメント追加のみに限定され、要件⑤（設定変更の最小化）を満たします。Direct Connect Gateway を Transit Gateway に関連付けることで単一の Direct Connect 接続から複数リージョン・複数 VPC へのルーティングが可能となり、要件②を実現します。2種類の TGW ルートテーブル（Workload用・SharedServices用）とブラックホールルートの組み合わせにより、Workload 間の直接通信を遮断しつつ SharedServices への双方向アクセスを許可できます（要件③④）。 選択肢B（アカウントごとの TGW Peering）: アカウントごとに Transit Gateway を作成して Peering 接続する構成は、管理対象の Transit Gateway 数が倍増し運用が複雑になります（要件①⑤不適合）。 選択肢C（VPC Peering メッシュ）: VPC Peering は推移的ルーティングに非対応であり、80 アカウント規模でのフルメッシュ構築はスケールしません。SharedServices 経由のみの通信制御も実装が困難です（要件③不適合）。 選択肢D（PrivateLink + 個別 Site-to-Site VPN）: PrivateLink はサービスごとにエンドポイント設定が必要で管理が煩雑になります。また Workload アカウントごとに VPN を維持する点は現状の課題（80 本の VPN 管理）を解決しません（要件①不適合）。