Transit Gateway によるマルチアカウントネットワークの集約とセグメンテーション
自動車部品メーカーが、国内 3 工場と海外 2 拠点の生産管理システムを AWS 上の 12 アカウント・約 40 の VPC で運用しています。現在は VPC 間を必要な組み合わせごとに VPC ピアリングでフルメッシュ接続しており、VPC を 1 つ増やすたびに数十本のピアリングとルートエントリを追加する作業が発生しています。オンプレミスとの接続は Direct Connect の Private VIF を VPC ごとに個別に作成しています。ネットワークチームは、接続の一元管理と新規 VPC 追加時の作業削減に加え、生産系 VPC と開発系 VPC が相互に通信できないセグメンテーションを維持し、さらに 1 本の Direct Connect 接続からすべての VPC に到達できることを求めています。最も適切な構成はどれですか。
解説を読む（正解: C）
VPC ピアリングは 1 対 1 の接続であり、推移的ルーティング (peering を経由して 3 つ目の VPC やオンプレミスへ抜けること) をサポートしません。そのため VPC 数が増えると接続数が N×(N-1)/2 で爆発し、ルートテーブルの管理が破綻します。AWS Transit Gateway はリージョン内のハブとして機能し、VPC・VPN・Direct Connect Gateway のアタッチメントを 1 か所に集約したうえで、複数のルートテーブルを持てる点が重要です。アタッチメントをどのルートテーブルに関連付け、どのルートテーブルへ伝播させるかを制御することで、ルーティングレベルでのネットワークセグメンテーションを実現できます。
C は、Transit Gateway をネットワーク専用アカウントに置いて AWS RAM で組織に共有するため各アカウントは自 VPC をアタッチするだけで済み、新規 VPC 追加時の作業が最小化されます。生産系と開発系で別のルートテーブルを用いることで相互到達性そのものを排除でき、Direct Connect Gateway と Transit VIF を使えば 1 本の接続から全 VPC へ到達できるため、すべての要件を満たします。
A は、VPC ピアリングが推移的ルーティングをサポートしないため、ハブ VPC を経由した VPC 間通信もオンプレミス中継も成立しません。B は、Transit Gateway を使うものの単一ルートテーブルではすべてのアタッチメントが相互に到達可能になり、セキュリティグループはインスタンス単位の制御であってネットワークセグメンテーションの代替にはなりません。また VPC ごとの Private VIF を残す構成は Direct Connect の一元化という要件に反します。D は、PrivateLink が特定のサービスエンドポイントを一方向に公開する仕組みであり、汎用的な VPC 間ルーティングやオンプレミス接続の集約には適さず、VPC ごとの VPN も管理負荷を増やします。
RAM で共有した Transit Gateway によるセルフサービス接続
あるフィンテック企業は AWS Organizations で複数の AWS アカウントを管理しており、共有サービスアカウントの VPC で社内向けの共通アプリケーション群をホストしています。この VPC にはすでに AWS Transit Gateway がアタッチされています。同社は新機能の開発にあたり専用の開発アカウントを新設しました。開発アカウントのリソースは共有サービスアカウントのアプリケーションへ接続する必要があります。開発チームは検証のたびにリソースを削除して作り直す予定であり、そのたびに共有サービスアカウントの管理者へ依頼することなく、開発チーム自身で接続を再作成できるようにしたいと考えています。運用オーバーヘッドを最小限に抑えてこの要件を満たすソリューションはどれですか。
解説を読む（正解: B）
AWS Transit Gateway は AWS Resource Access Manager (AWS RAM) を使って組織内の他アカウントに共有でき、共有を受けたアカウントは自分の VPC を対象としたアタッチメントをいつでも自分で作成・削除できます。さらに Transit Gateway 側で共有アタッチメントの自動受け入れを有効にしておけば、アタッチメント作成時に所有者アカウントでの承認操作が不要となり、開発チームは完全にセルフサービスで接続を張り直せます。選択肢 B はこの構成そのものであり、リソースを頻繁に作り直す開発アカウントに対して追加の運用作業を発生させないため正解です。選択肢 A は誤りで、Transit Gateway をもう 1 つ作ると時間課金とアタッチメント課金が余分に発生するうえ、Transit Gateway 間のピアリングアタッチメントには自動受け入れの設定が存在せず、必ず相手側での手動承認が必要になります。選択肢 C も誤りで、AWS PrivateLink のエンドポイントサービスを公開するには Network Load Balancer もしくは Gateway Load Balancer が必要であり、Transit Gateway の自動受け入れ設定とは無関係です。加えて、公開したいアプリケーションごとにエンドポイントサービスを用意する運用が発生します。選択肢 D も誤りで、EventBridge と Lambda による独自の自動承認は Transit Gateway の標準機能で代替できる不要な作り込みであり、AWS Network Manager はグローバルネットワークを可視化・監視するためのサービスでリソースを他アカウントへ共有する機能は持ちません。
複数アカウントから共有 Aurora クラスターへの接続
ある損害保険会社は AWS Organizations で開発環境を管理しており、アクチュアリーの各チームに専用の AWS アカウントを 1 つずつ割り当てています。各アカウントには VPC が 1 つだけあり、CIDR ブロックは互いに重複しないよう設計されています。同社は共有サービスアカウントに Amazon Aurora PostgreSQL DB クラスターを構築しており、すべての開発チームがこのクラスターのライブデータに対してクエリを実行する必要があります。運用オーバーヘッドを最小限に抑えながら、DB クラスターへの必要な接続性を提供するソリューションはどれですか。
解説を読む（正解: B）
AWS Transit Gateway は、多数の VPC やオンプレミスネットワークをハブアンドスポーク型で相互接続するリージョナルなルーターです。AWS Resource Access Manager (AWS RAM) を使うと Transit Gateway を組織内の他アカウントへ共有でき、共有を受けたアカウントは自分の VPC を自身でアタッチできます。CIDR が重複していない前提であれば、ルートテーブルを整えるだけで全開発アカウントの VPC から共有サービスアカウントの Aurora エンドポイントへ通常の TCP 接続が可能になり、チーム数が増えても構成が複雑化しません。選択肢 B はこの標準的なマルチアカウント接続パターンであり、最小の運用負荷で要件を満たすため正解です。選択肢 A は誤りで、AWS RAM で RDS 関連リソースを共有できる範囲はクロスアカウントクローンなど限定的な用途であり、他アカウントの VPC からライブデータへ接続するためのネットワーク経路を提供するものではありません。選択肢 C も誤りで、Application Load Balancer はレイヤー 7 の HTTP/HTTPS 専用であり PostgreSQL のワイヤプロトコルをそのままプロキシできません。加えて、DB のフェイルオーバー時にエンドポイントの IP アドレスが変わるため、ターゲットを追随させる自動化を別途作り込む必要があります。選択肢 D は各開発アカウントにサードパーティ製 VPN アプライアンスを構築し、パッチ適用と監視を続ける必要があり、アカウント数に比例して運用負荷が増えるため最適ではありません。