無限ノック › SAP 練習問題一覧 › 問題
SAP組織の複雑さに対応する設計

あるグローバル製造企業は、AWS Organizations 配下の単一の「共有サービスアカウント」で社内向けの在庫管理 API を運用している。この API は、買収を繰り返した結果として相互に CIDR が重複している 90 以上の消費者 VPC(複数アカウント・複数事業部)から HTTPS で呼び出される。セキュリティ部門は『API への通信は消費者 VPC からプロバイダー方向への一方向のみを許可し、消費者 VPC 同士は相互に到達できてはならない』『将来 VPC が増えてもプロバイダー側のルートテーブル変更を不要にしたい』と要求している。運用チームはルーティング管理の負荷を最小化したい。これらを満たす接続方式はどれか。

A
AWS Transit Gateway を共有サービスアカウントに作成して RAM で各アカウントに共有し、消費者 VPC をすべてアタッチして集約ルートテーブルで API へルーティングする
Transit Gateway はアタッチされた VPC の CIDR をルートテーブルで識別して転送するため、相互に重複する CIDR を持つ 90 以上の VPC を集約できず、集約ルートでは消費者 VPC 同士も相互到達してしまい要件に反する。
B
共有サービスアカウントで API の前段に Network Load Balancer を配置して VPC エンドポイントサービス(AWS PrivateLink)を作成し、各消費者 VPC にインターフェイス VPC エンドポイントを作成して接続する
✓ 正解
Network Load Balancer をエンドポイントサービスとして公開する PrivateLink は ENI 経由で接続し IP 空間が独立するため CIDR 重複に影響されず、消費者→プロバイダーの一方向のみで消費者間到達もなく、VPC 追加時のルート変更も不要で要件を全て満たす。
C
各消費者 VPC と共有サービス VPC の間に VPC ピアリングを設定し、プロバイダー側のルートテーブルに各消費者 VPC の CIDR へのルートを追加して双方向到達性を確保する
VPC ピアリングは接続する両 VPC の CIDR が重複していると確立できず、相互に重複する 90 以上の VPC では成立しない。さらに VPC ごとにルートテーブル更新が必要で双方向到達性も生じ、すべての要件に反する。
D
共有サービスアカウントに Application Load Balancer を配置して Transit Gateway 経由で接続し、各消費者 VPC では Route 53 Resolver のインバウンドエンドポイントで名前解決して到達させる
PrivateLink のエンドポイントサービスは Network Load Balancer または Gateway Load Balancer が前提で Application Load Balancer を直接指定できず、Transit Gateway 経由も CIDR 重複で破綻するため、この構成では要件を満たせない。

解説

AWS PrivateLink はインターフェイス VPC エンドポイントとエンドポイントサービス間を ENI 経由で接続するため、消費者とプロバイダーの IP アドレス空間が独立し、CIDR が重複していても通信できる。 通信は消費者→プロバイダーの一方向のみで、消費者 VPC 同士は到達できず要件に合致する。 プロバイダー側のルートテーブル変更も不要で、VPC が増えてもエンドポイント追加だけで拡張できる。 選択肢0の Transit Gateway はルーティングに IP が用いられ、CIDR が重複する VPC を同一ルートテーブルで扱えず、消費者間の到達性も生まれるため不適。 選択肢2の VPC ピアリングは CIDR 重複環境で機能せず、VPC ごとにルート追加が必要で運用負荷も高い。 選択肢3は PrivateLink のエンドポイントサービスに ALB を直接指定できず(NLB が必要)、TGW も CIDR 重複で破綻する。

ドメイン別正答率・予想スコアでリアルタイムに実力把握

無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。

無料で演習を始める →
← SAP の問題一覧に戻る