ある企業はAWS Transit Gatewayに以下の4種類のVPCをアタッチしています。 ・本番環境VPC（Production）：機密性の高い顧客データを処理 ・開発環境VPC（Development）：テスト・開発用途 ・共有サービスVPC（Shared Services）：DNS・パッチ配信・ログ収集サーバーを集約 ・検査VPC（Inspection）：AWS Network Firewallを配置したトラフィック検査用 以下のセキュリティポリシーをすべて実装する必要があります。 ・本番VPCと開発VPCは互いに通信できない ・本番VPCと開発VPCはそれぞれ共有サービスVPCに接続できる ・共有サービスVPCから本番VPCおよび開発VPCへの通信開始は禁止 ・すべてのVPC間トラフィックは検査VPCのAWS Network Firewallを必ず経由する これらの要件をすべて満たす最も適切なTransit Gatewayの設計はどれですか？
Transit Gateway複数ルートテーブル（集中検査アーキテクチャ）が最適です。スポークVPC（本番・開発・共有サービス）の各ルートテーブルには0.0.0.0/0を検査VPCへ向けるデフォルトルートを設定し、検査VPCのルートテーブルには各スポークVPCへの具体的なルートを定義します。共有サービスVPCのルートテーブルには本番・開発VPCへのルートを持たせないことで、通信開始を一方向に制限できます。4つの要件をすべて同時に満たせる唯一の設計です。 選択肢Aのデフォルトルートテーブル＋ブラックホールルートでは本番・開発間の遮断はできますが、すべてのトラフィックを検査VPC経由に強制するルーティングを単一ルートテーブルで実現することは困難です。 選択肢CのVPCピアリングは推移的ルーティングをサポートしないため、検査VPCを中継した集中検査を実現できず、スケールも大幅に悪化します。 選択肢Dの2ルートテーブル構成では共有サービスVPCからの通信方向制御や検査VPC強制経由を同時に満たす設計が実現できません。