Transit Gateway / RAMリソース共有難易度 標準無料
ある企業はAWS Organizationsで50個のメンバーアカウントを運用しており、各アプリケーションチームがそれぞれ自分のアカウントでVPCを作成している。ネットワーク部門は単一のTransit Gateway（TGW）を中央のネットワークアカウントで一元管理しつつ、各アプリケーションチームが自分のアカウントから自分のVPCをそのTGWへアタッチできるようにしたい。TGW自体のルートテーブル管理は引き続き中央のネットワーク部門が行いたい。この要件を最小の運用負荷で満たす設計として最も適切なものを選べ。（単一選択）
- A中央のネットワークアカウントでTGWを作成し、AWS RAMでOrganizations配下の対象アカウント（またはOU）へ共有する。各アプリケーションチームは自分のアカウントから自分のVPCをTGWへアタッチする。TGWのルートテーブル操作は引き続き中央のネットワークアカウントのみが行う
- B各アプリケーションアカウントに個別のTGWを作成し、それらすべてを中央のネットワークアカウントのTGWとピアリング接続する
- C中央のネットワークアカウントのTGWに対するフルアクセスのIAMロールを各アプリケーションアカウントへ発行し、各チームがそのロールを引き受けてTGWのルートテーブルを直接編集できるようにする
- D各アプリケーションVPCと中央のネットワークアカウントのVPCとの間でVPCピアリングを個別に確立し、TGWは使用しない
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
複数アカウントにまたがってTGWのようなリージョナルリソースを使わせたい場合の標準的な仕組みはAWS Resource Access Manager（RAM）である。
- 中央のネットワークアカウントがTGWを所有したまま、RAMでそのTGWをOrganizations配下の対象アカウント（または特定OU）に共有する。
- Organizationsとの統合を有効にしておけば、共有された各アカウントは招待の個別承認なしに自動的に共有リソースを受け取れる。
- 各アプリケーションチームは自分のアカウントから、自分が所有するVPCを共有されたTGWへVPCアタッチメントとして作成できる（ここは各アカウントの権限で実行可）。
- 一方、TGWのルートテーブルの作成・関連付け・伝播設定はTGWの所有アカウント（中央のネットワークアカウント）側でのみ操作可能であり、中央管理のガバナンスを維持できる。
これによりTGW自体は1つのまま、アタッチメントの作成権限だけを各チームに委譲でき、TGWを人数分複製する必要がない。
- BTGWを50個複製することになり運用負荷が増大する。中央で単一のTGWを一元管理したいという要件にも反する。
- C各チームにルートテーブル編集権限まで渡すことになり、中央でルートテーブルを一元管理したいというガバナンス要件に反する。RAM共有はアタッチメント作成権限のみを委譲でき、ルートテーブルは所有アカウント限定のままにできる。
- D50本のピアリング接続をフルメッシュまたはハブ型で個別管理することになり、TGWが解決しようとしているスケーラビリティ課題（N:N接続の複雑化）を再現してしまう。
ひっかけ： TGWはリージョナルの単一リソースであり、アカウントごとに複製するものではない。「各アカウントに個別のTGWを作りピアリングする」という発想は運用が煩雑化し、
本問が求める「単一のTGWを中央管理」という要件にも反する。RAM共有ならTGW本体は1つのまま、アタッチメント作成権限だけを配ることができる点を区別する。
公式ドキュメント・関連Transit Gateway ― Working with transit gateways (RAM sharing)↗AWS RAM User Guide ― Shareable AWS resources↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）