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 はグローバルネットワークを可視化・監視するためのサービスでリソースを他アカウントへ共有する機能は持ちません。
新規アカウントへのベースライン自動適用と共有ネットワークの提供
動画配信サービスを運営するメディア企業が、AWS Control Tower でランディングゾーンを構築済みです。番組・企画ごとにアカウントを新設する方針のため、毎月 5〜10 個のアカウントが特定の OU に追加されます。プラットフォームチームは次の 2 点を、アカウント追加のたびの手作業なしで実現したいと考えています。1 つ目は、新規アカウントが OU に追加された時点で監査用の IAM ロールと AWS Config ルールが 3 つのリージョンに自動展開されること。2 つ目は、各アカウントの VPC がネットワークアカウントにある Transit Gateway と Route 53 Resolver ルールを利用できることです。要件を満たす対応を 2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、B）
AWS Organizations 環境でベースラインを配布する標準的な手段が CloudFormation StackSets です。サービスマネージド型のアクセス許可を選ぶと、StackSets が Organizations と連携して必要な IAM ロールを自動的に扱い、さらに自動デプロイを有効にしておけば、対象 OU にアカウントが追加された時点でスタックインスタンスが自動作成され、OU から外れた際には削除されます。ターゲットリージョンを複数指定できるため、3 リージョンへの同時展開もそのまま実現できます。一方、ネットワークリソースの共有には AWS RAM を使い、Transit Gateway や Route 53 Resolver ルールを組織単位・OU 単位で共有すると、共有先アカウントは自 VPC のアタッチメントや関連付けを作成するだけで利用できます。
したがって A と B の組み合わせが、アカウント追加時の手作業を排除しつつ、監査ベースラインの展開と共有ネットワークの利用という 2 つの要件を満たします。
C は、セルフマネージド型では各アカウントに実行ロールを手動で用意する必要があり、自動化という前提に反します。D は、アカウント数の増加に対して VPC ピアリングが線形に増え、Transit Gateway と Resolver ルールを共有するという要件も満たしません。E は StackSets の自動デプロイで標準機能として提供される内容を独自実装するもので、保守すべきコードとエラー処理の負担が増えるだけです。F は各チームによる手動起動が前提であり、手作業なしという要件に反します。
VPC 共有と低帯域ハイブリッド接続のコスト最適化
ある医療機器メーカーには 8 つの研究開発チームがあり、それぞれが独立した AWS アカウントを保有しています。すべてのチームは同一の AWS リージョンだけで作業する方針です。各チームのワークロードは社内データセンターにある治験データベースを参照する必要があるため、オンプレミスネットワークと接続された VPC 環境が求められます。ネットワーク部門の試算では、オンプレミスとの間でやり取りされるトラフィックは全チームを合計しても 40 Mbps を超えないと見込まれています。
この要件を最もコスト効率よく満たす手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: B、D）
同一リージョン内の複数アカウントへネットワークを提供する方法には、アカウントごとに VPC を作る方法と、1 つの VPC のサブネットを AWS Resource Access Manager (RAM) で配布する VPC 共有の 2 つがあります。VPC 共有では所有者アカウントが VPC とサブネットを一元管理し、参加者アカウントは共有されたサブネットに自分の EC2 インスタンスやデータベースを配置できます。この方式ならオンプレミスへの接続点を 1 か所に集約でき、接続数に比例して課金される VPN や Transit Gateway を増やさずに済みます。
正解の B は、共有サービスアカウントに 1 つの VPC を作成して RAM でサブネットを配布するため、テンプレートの重複デプロイもアカウント間の相互接続も不要になり、8 チームへ最も安価にネットワークを提供できます。D は、合計 40 Mbps という小さな帯域要件に対して初期費用が不要で従量課金の AWS Site-to-Site VPN を使う選択であり、単一 VPC からオンプレミスへ接続する手段として十分かつ最安です。
A は VPC が 8 個生まれ、それぞれにオンプレミス接続が必要になるため接続コストがおよそ 8 倍に膨らみます。C は Transit Gateway のアタッチメント料金とデータ処理料金が上乗せされますが、VPC を共有すれば VPC は 1 つで済むため Transit Gateway 自体が不要であり、純粋な追加費用にしかなりません。E の AWS Direct Connect は物理回線費とポート料金が高額で、開通にも時間がかかるため、40 Mbps 程度のトラフィックには明らかに過剰投資です。