Transit Gateway / RAMリソース共有（サブネット共有）難易度 標準無料
プラットフォーム部門が中央のネットワークアカウントで1つのVPCとサブネット群を集中管理しており、30個のアプリケーションチーム（各自別アカウント）がそれぞれ独自のVPC/CIDRを持たずに、そのVPC内のサブネットへ直接EC2やRDSといったリソースを配置できるようにしたい。IPアドレス空間の消費を抑え、ネットワーク設定（ルーティング・NACL等）は中央で一元管理を続けたいが、リソースの請求・IAM権限はチームごとのアカウントに分離しておきたい。この要件を満たす設計として最も適切なものを選べ。（単一選択）
- A中央のネットワークアカウントが所有するVPCの特定サブネットを、AWS RAMで各アプリケーションアカウントへ共有する。各チームは自分のアカウントの権限で共有サブネットへリソースを起動する。VPC/ルートテーブル/NACLの管理は所有アカウント側に一元化されたままにする
- B各アプリケーションアカウントに個別のVPC/CIDRを作成させ、それぞれをTGW経由で中央のネットワークアカウントのVPCと接続する
- C中央のネットワークアカウントのVPCへリソースを起動できるクロスアカウントIAMロールを各チームに発行し、各チームはそのロールを引き受けて中央アカウント名義でリソースを起動する
- D各アプリケーションチームにVPCピアリングを個別に確立させ、中央VPCのサブネットCIDRへの経路だけを提供する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
これはVPCサブネット共有（VPC sharing）が想定するユースケースそのものである。VPCサブネット共有はAWS RAMを利用して実現する。
- VPC所有アカウント（中央のネットワークアカウント）が、特定のサブネットをRAM経由で他のアカウント（参加者アカウント）に共有する。
- 参加者アカウントは、共有されたサブネットへ自分のアカウントのIAM権限でEC2・RDS等のリソースを起動できる。リソースの課金は起動したアカウント側に計上される。
- 各参加者アカウントは、同じ共有サブネット内であっても他の参加者が作成したリソース（ENI等）を参照・変更することはできない（可視性・権限は自分が所有するリソースに限定される）。
- VPCそのもの・ルートテーブル・NACL・サブネットCIDRの管理は引き続き所有アカウント側で一元管理される。これにより新規VPC/CIDRを都度払い出す必要がなく、IPアドレス空間の消費とネットワーク設定の分散を防げる。
- Bアカウント数分のVPC/CIDR払い出しが発生しIPアドレス空間を消費する。ネットワーク設定も各VPCで分散し、要件の「独自のVPC/CIDRを持たない」「中央で一元管理」に反する。
- Cリソースが中央アカウント名義で作成されるため、チームごとの請求・IAM権限の分離という要件を満たせない。VPCサブネット共有ならリソース所有権はリソースを起動したアカウント側に残る。
- Dピアリングでは相手のVPC内へ直接リソースを起動することはできず（あくまで別VPC間のネットワーク到達性の話）、要件である「共有サブネットへ直接リソースを配置する」を実現できない。
ひっかけ： 「各アカウントに個別のVPCを作りTGWまたはピアリングで接続する」という発想は一見自然だが、アカウント数分のVPC/CIDR払い出しが必要になりIPアドレス空間を消費し、
ネットワーク設定（ルーティング等）もアカウントごとに分散してしまう。本問の「独自のVPC/CIDRを持たずに」「中央で一元管理」という条件からはサブネット共有が正解筋であると読み取る。
公式ドキュメント・関連Amazon VPC User Guide ― Share your VPC with other accounts↗AWS RAM User Guide ― Shareable AWS resources↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）