Transit Gateway ルートテーブルによるセグメンテーション難易度 高無料
Transit Gateway配下に「本番」「開発」「共有サービス（AD・監視等）」の3種類のVPCが多数アタッチされている。要件は次の通り。
- 本番VPC同士・開発VPC同士はそれぞれ相互に通信できる
- 本番VPCと開発VPCの間は一切通信させない
- 本番・開発どちらのVPCからも共有サービスVPCへは通信できる（逆方向も可）
この要件を、ルーティングレイヤーで確実かつスケーラブルに実現する設計として最も適切なものを選べ。（単一選択）
- AすべてのVPCアタッチメントを単一のデフォルトTGWルートテーブルに関連付け、本番⇔開発間の通信はセキュリティグループとNACLだけで拒否する
- B本番用・開発用の2つのTGWルートテーブルを作成し、それぞれに対応するVPCアタッチメントを関連付ける。共有サービスVPCのルートは両方のルートテーブルに伝播させ、共有サービスVPC側のルートテーブルには本番・開発双方への経路を伝播させる。本番ルートテーブルには開発VPCのルートを、開発ルートテーブルには本番VPCのルートをそれぞれ伝播させない
- C本番VPCと開発VPCそれぞれに個別のTGWを新規作成し、共有サービスVPCだけを両方のTGWにアタッチする
- D本番VPCと開発VPCのCIDRをあえて重複させ、TGWが重複CIDR宛のルートを自動的にドロップする挙動を利用して分離する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・独立検証済
解説
TGWは複数のルートテーブルを作成し、各アタッチメントを任意のルートテーブルに関連付ける（association）ことができ、 さらに伝播（propagation）先のルートテーブルもアタッチメントごとに個別に選べる。これによりVRF（仮想ルーティングフォワーディング）に似た論理的な分離＝セグメンテーションを構成できる。
- 本番ルートテーブル：本番VPCアタッチメントを関連付け、本番VPC同士のルートと共有サービスVPCのルートだけを伝播/追加する（開発VPCのルートは伝播させない）。
- 開発ルートテーブル：開発VPCアタッチメントを関連付け、開発VPC同士のルートと共有サービスVPCのルートだけを伝播/追加する（本番VPCのルートは伝播させない）。
- 共有サービス側：共有サービスVPCのアタッチメントは本番・開発の双方のルートテーブルへルートを伝播させ、また共有サービスVPC自身のルートテーブルには本番・開発両方への経路を持たせる。
この構成により、本番と開発の間には（どちらのルートテーブルにも相手のルートが存在しないため）そもそも到達可能な経路自体が存在せず、 SGやNACLに頼らずルーティングレイヤーで確実に分離できる。大量のVPCがあってもルートテーブルの関連付け・伝播ルールで一括管理できるためスケーラブルである。
- A単一ルートテーブルでは本番・開発双方の経路が互いに見える状態になり、SG/NACLの設定漏れがあれば越境してしまう。ルーティングレイヤーでの確実な分離になっていない。
- CTGWを複数作成すると管理対象が増え運用が複雑化する。単一TGW内のルートテーブル分離だけで同じ隔離要件を満たせるため過剰な設計である。
- DTGWは重複するCIDRを持つVPC同士のアタッチメント自体は作成できる。ただし同一ルートテーブルに双方のルートを伝播させても、より具体的な一致（最長プレフィックス一致）が優先されて一方の経路しか有効にならず、「自動的にドロップされる」わけでもない。挙動が不確定・宛先次第であり、意図的なセグメンテーション手段として成立しない。
ひっかけ： 「セキュリティグループやNACLで本番⇔開発間の通信をブロックすればよい」という発想は誤りではないが、
本問が求める「ルーティングレイヤーで確実に」を満たさない。SG/NACLはIPベースのアクセス制御であり設定漏れ・変更リスクが残るのに対し、
TGWルートテーブル分離は経路自体が存在しないため設定ミスによる越境が構造的に起こりえないという違いを理解しているかが問われる。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）