ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。
採点する
20問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数20
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 20
1. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-145】本社の DevOps チーム 500 名がリモートから AWS 環境にアクセスする。
Transit Gateway で接続された以下 2 つの VPC のみへ到達させ、それ以外のトラフィックは各 PC の既存インターネット回線を使わせたい。
・Prod VPC: 10.0.0.0/16
・Shared-Svc VPC: 10.1.0.0/16
オンプレ DC (172.16.0.0/16) には誤ってルーティングしないことが必須要件である。
クライアント OS 変更なしで実現する最適な Client VPN 構成はどれか。正解不正解ヒントボタン
リモート開発者のノート PC からは普段のブラウジングは各自のインターネット回線に逃がし、AWS への接続だけを暗号化した経路に載せたいので、Client VPN では split-tunnel を有効にしてクライアントへ渡すルートを必要最小限の CIDR に絞ります。full-tunnel で 0.0.0.0/0 を配布すると全通信がトンネルに吸い込まれ、ローカルブレークアウトの要件を満たせなくなる点を思い出してください。
アクセス対象は 10.0.0.0/16 と 10.1.0.0/16 の二つだけですから、Client VPN のルートテーブルにこの 2 本を静的登録し、ターゲットに Transit Gateway を指定すれば 1 エンドポイントで両 VPC へ届きます。ここに 172.16.0.0/16 や広い 10.0.0.0/8 を含めなければオンプレ DC へ向かう経路は配布されず、誤ルーティングを防止できます。
すなわち、split-tunnel を使った Client VPN に必要 CIDR のみを設定し Transit Gateway 経由でルーティングする構成は、500 名の利用者を単一エンドポイントでまとめ、各クライアント OS に追加設定を要求せず、オンプレ CIDR を排除した経路制御で誤配送を抑えつつローカルインターネット接続も確保するという複数要件をバランス良く満たす最適解と判断できます。
-
質問 2 of 20
2. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-146】国内外に拠点を持つ医療機器メーカーは、AWS Cloud WAN でコアネットワークを運用している。
リージョンごとにエッジが配置され、セグメントは「corp」と「dev」に分離されている。
現状はセグメント間のルート伝播を禁止しているが、本社管理システム (10.50.0.0/16, dev) へ社内端末 (corp) からのみアクセスできるようにしたい。
動的ルート伝播は許可されておらず、VPC ルートテーブルの個別変更も避けたい。
最少変更で要件を満たすコアネットワークポリシーの変更はどれか。正解不正解ヒントボタン
要件を整理すると、AWS Cloud WAN の corp と dev という 2 つのセグメントは現在完全にルートが分離されていますが、社内端末が属する corp からのみ dev 側の 10.50.0.0/16 へ到達させたい状態です。動的ルート伝播は全体方針で禁止され、各 VPC の Route Table も触りたくないので、調整できるのはコアネットワークポリシーのみとなります。双方向通信や他 CIDR まで広げてしまうとコンプライアンス的にも過剰な権限付与となるため「片方向かつ限定 CIDR」という粒度での例外設定がカギになります。
Cloud WAN には segment-route ポリシーという仕組みがあり、sources に送信元セグメント、destinations に宛先セグメント、さらに destinationCidrBlocks で CIDR を細かく指定することで、例外的なスタティックルートを注入できます。ここで propagate を false にすると、そのルートはコアネットワークの内部処理に閉じたまま各セグメント間にのみ適用され、既存の「ルートは相互伝播しない」というグローバル設定を変えずに済みます。つまり corp から dev へ特定 CIDR だけを許可し、逆方向の伝搬や他 CIDR への影響を防ぎながら最小変更で目的を達成できます。
代替案としては Connect アタッチメントを追加して BGP で CIDR を広告したり、セグメント共有を有効にして両セグメントを統合する方法も考えられますが、それらはオンプレミス機器や全ルートの自動伝播を伴い運用コストとリスクが高まります。求められているのは「ルート伝播は許可されていない」「VPC ルートテーブルにも触らない」「最小の設定変更」という複数要件をすべて満たす解決策であり、最もシンプルに条件を満たせるのは Cloud WAN の segment-route ポリシーで片方向かつ個別 CIDR を静的に許可するアプローチだと総合的に判断できます。
-
質問 3 of 20
3. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-147】製造業A社は AWS Cloud WAN で prod・dev・sec・dc の 4 セグメントを運用している。
要件は
①dc からの通信は必ず sec を経由して prod へ到達し dev へは不可、
②dev は sec のみへ到達可能で prod・dc へは不可、
③Route Analyzer で確認できる静的ルートを Core Network Policy で定義すること。
最小構成変更で要件を満たす Core Network Policy のアクションはどれか。正解不正解ヒントボタン
Cloud WAN で dc からのトラフィックを必ず sec を通して prod に流すには、Core Network Policy で sec を share-segment しつつ dc のルートテーブルに prod 側 CIDR 10.0.0.0/16 を sec アタッチメント向け static-route として登録し、動的伝播だけに頼ると dc と prod が直接経路を学習してしまうリスクがある点を Route Analyzer で確かめ、監査要件にも応える形で経路を固定化するのが重要です。
dev は検証用の隔離環境なので他セグメントと分離しながら sec のみへ到達させるには、Core Network Policy で sec を share-segment しつつ dev 側の propagate を Disabled に設定して余計な経路を吸わないようにし、Cloud WAN のルート優先度を活用して Network Firewall を追加せずとも通信範囲を制限し、ルート数を最小に保って運用簡素化を図るのが効果的です。
最小変更で三つの要件──sec 経由の強制ルート、dev の一方向到達性、静的ルートによる可視化──を同時に満たす観点で比較すると、Cloud WAN の share-segment と propagate 無効化、static-route 設定のみで完結する Core Network Policy 案が、Transit Gateway や ACL など他サービスを足すプランより変更範囲と複雑度が小さく総合判断の決め手になります。 -
質問 4 of 20
4. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-148】グローバル製造企業は4つのAWSアカウントでCloud WANを運用し、CoreとDevの2セグメントを定義している。
要件は次のとおり：
1) tag:Environment=Prod が付いた VPC Attachment は Core のみに接続させる
2) それ以外は Dev へ接続させる
3) us-east-2 で作成された VPN Attachment はどのセグメントにも接続させない
4) 誤設定防止のためポリシーは一元管理し、優先度衝突を避ける
現状、1日平均5件の新規アタッチメント要求があり、運用負荷を最小化しつつ SLA で求められるゼロダウンタイムを維持したい。
Network Manager のアタッチメント承認ポリシーを設定する最適な方法はどれか。正解不正解ヒントボタン
Cloud WAN の Network Manager で書くアタッチメント承認ポリシーは、attachment.type や attachment.region、attachment.tags など複数条件を AND で組み合わせられます。まず拒否させたい条件を優先度の最上位に置くことで、us-east-2 の VPN Attachment がどのセグメントにも届かない状態を確実に作れます。Transit Gateway 側で制御するとポリシーが分散し、一元管理という運用方針から離れてしまう点に注意してください。また Deny ルールは後続評価を打ち切るため誤接続防止に最適です。
次に tag:Environment=Prod の判定を置き、Prod 用 VPC Attachment を Core セグメントへ自動ルーティングさせることでセキュリティ境界を維持します。最後にワイルドカード {Rule=*} を低い優先度で追加すれば、条件に当てはまらない全アタッチメントが Dev にフォールバックします。Cloud WAN のポリシー変更はライブ反映され、VPC や VPN を再接続しなくてよいのでゼロダウンタイムを保ち、1 日 5 件ほどの申請でも手動作業はほぼ不要です。
本設計では Cloud WAN、Network Manager、タグ、優先度、Deny、ワイルドカードというキーワードを組み合わせ、①特定リージョン VPN の接続拒否、②Prod タグを Core へ、③その他を Dev へ、④中央集権的ポリシーで衝突排除、⑤ダウンタイム無の自動運用、という複数要件を俯瞰して満たせる構成かどうかを総合判断することが鍵となります。
-
質問 5 of 20
5. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-149】金融系グループ企業は 3 アカウント間で決済 API を共有したい。
API はアカウント A の NLB 背後で稼働し、Interface 型エンドポイントサービスとして公開されている。
利用側 2 アカウントでは次を満たす必要がある。
① VPC 内外（オンプレ AD DNS）から FQDN「api.corp.internal」で名前解決できる
② エンドポイントへの通信は 10.0.0.0/8 からの TCP 443 のみに制限
③ プロバイダー側セキュリティグループは変更不可。
最も運用負荷が低く、AWS ベストプラクティスに合致する実装はどれか。正解不正解ヒントボタン
まず「api.corp.internal」を VPC 内でもオンプレでも同じ名前で引けるようにするには、Interface 型の VPC エンドポイントを作成して Private DNS を有効化するのが鍵です。VPC 内の AmazonProvidedDNS は自動でエンドポイント ENI のプライベート IP を返し、オンプレミスは Route 53 Resolver インバウンドエンドポイント経由で同じ応答を得られるため、名前解決の仕組みを追加で作り込む必要がなく運用も軽くなります。
通信フィルタリングは利用側エンドポイント ENI に割り当てる Security Group で行うとシンプルです。ここで TCP 443 と 10.0.0.0/8 だけを許可すれば、AWS PrivateLink の内部経路を通るトラフィックだけが通過し、公開側の SG や NLB の設定を変えずに要件を満たせます。さらに Endpoint Policy を組み合わせれば将来のアクセス権管理も利用側だけで完結し、金融システムの厳格な監査対応にも有利です。
VPC ピアリングや Transit Gateway はルートやホストゾーンの管理が増え、Gateway エンドポイントは S3/DynamoDB 専用で用途が違います。Interface エンドポイント＋Private DNS＋Route 53 Resolver なら①共通 FQDN 解決 ②10.0.0.0/8･443 の通信制限 ③公開側 SG 不変更という複数条件を一手に満たし、クロスアカウントでも最小構成で運用負荷とベストプラクティスの両面から総合的に最も合理的と判断できます。
-
質問 6 of 20
6. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-150】あなたはグローバルSaaS企業のネットワークエンジニアである。
集中管理アカウントのus-east-1 VPC上のマイクロサービス(API)を複数の顧客アカウントからHTTPSで提供したい。
要件:
①インターネット回避
②顧客VPC CIDR重複許容
③同時5,000接続・平均50 KB応答・P95レイテンシ30 ms以下
④顧客側追加セキュリティデバイス不要
⑤本番運用中にIPが変動してもDNS名変更不要。
また、サービス側はAuto Scalingにより短時間でIPが増減する。
最も適切なアーキテクチャはどれか。正解不正解ヒントボタン
インターネットを経由せずに別アカウントの VPC へ HTTPS 提供を行うなら、Network Load Balancer の背後にある VPC エンドポイントサービスを AWS PrivateLink で共有する方法が王道です。エンドポイントは ENI として顧客サブネットに張り付くため CIDR が重複しても問題なく、通信はプライベート IP のみで完結します。さらにプライベート DNS を有効化すれば独自ドメインで解決でき、IP が増減しても顧客側設定は不要になります。
同時 5,000 接続と平均 50 KB 応答を P95 30 ms 以内で処理するには、Elastic Load Balancing の Network Load Balancer が持つ高スループットと低レイテンシが適しています。Auto Scaling グループでインスタンスが短時間に増減しても NLB がターゲットを自動管理し、クライアントは常に同じプライベート DNS 名へアクセスするだけで済みます。リージョン内複数 AZ にまたがる内部負荷分散により、ピーク時でも追加運用なしでスケールを維持できます。
顧客側で VPN や NAT、追加ファイアウォールを準備せず、重複 CIDR の制約を受けず、IP 変動を気にせずにドメイン名を固定できる構成は、AWS RAM で共有した Interface VPC エンドポイントと PrivateLink 経由で Network Load Balancer に到達させる設計だけが各要件を同時に満たします。インターネット回避、スループット性能、運用負荷の低減を俯瞰し総合判断すると、このアプローチが最適であることが見えてきます。
-
質問 7 of 20
7. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-151】あるグローバル小売企業は、東京 (ap-northeast-1) とバージニア (us-east-1) に跨る 2 つの AWS アカウントでハブ＆スポーク型ネットワークを構築する。
本番 VPC (10.0.0.0/16, 10.1.0.0/16) のみをリージョン間で相互接続し、同リージョン内の開発 VPC (10.2.0.0/16, 10.3.0.0/16) は隔離したい。
総経路数は 50 未満に抑え、数秒以内で経路収束し、運用負荷を最小化する必要がある。
最も適切な設計はどれか。正解不正解ヒントボタン
リージョンを跨いだ本番ネットワークを数秒以内で自動収束させ、しかも 50 経路未満に抑えたい場合、BGP 設定や EC2 ルーターの保守を挟まないマネージド接続が鍵です。Transit Gateway のクロスリージョンピアリングは AWS 側で冗長化と動的伝搬が行われ、ルートのサマリ化を強要せずとも高速収束を実現し、VPN の再ネゴシエーションや VPC ピアリング用スタティックルート追加といった細かな運用作業を大幅に削減できます。
開発環境を完全に隔離するには、セキュリティグループや NACL でパケットを止めるより、そもそもルートが広告されない構成が安全でシンプルです。Transit Gateway では複数のルートテーブルを作成し、アタッチごとに関連付けを変えられるため、本番 VPC だけを専用テーブルに紐付けてピア接続へ伝搬させれば、開発 CIDR が誤って学習される事態を防ぎつつ運用の手間も最小化できます。
今回の要件は「本番のみ相互接続」「経路 50 未満」「数秒収束」「最低運用」の四点です。VPC ピアリングは手動ルートと CIDR 重複の制限、VPN＋Transit VPC は EC2 管理コスト、単一ルートテーブル運用は隔離不足という弱点が残ります。Transit Gateway を両リージョンに配置し、本番専用テーブル経由でピアリングする設計だけが四要件を無理なく同時に満たすため、総合的に最適な選択になります。
-
質問 8 of 20
8. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-152】金融 SaaS 企業はオンプレ DC（10.0.0.0/16）と東京リージョンの Transit Gateway を 1 Gbps Direct Connect で接続し、Production（10.1.0.0/16）、Dev（10.2.0.0/16）、Stg（10.3.0.0/16）の 3 VPC をスポークとしている。
監査要件によりオンプレは Production VPC へしか到達できず、Dev/Stg も将来追加される新 VPC も広告してはならない。
現在は単一 TGW ルートテーブルで自動伝搬を有効にしており、ピーク 4,000 pps 程度のトラフィックを扱う。
今後 VPC が 10 以上に増えても追加設定を極力なくし、コストと運用負荷を最小化するにはどうすべきか。正解不正解ヒントボタン
Transit Gateway と Direct Connect Gateway のアソシエーション時に指定できる allowed prefixes を使えば、オンプレ側へ BGP 広告する CIDR を 10.1.0.0/16 だけに限定できます。単一 TGW ルートテーブルを自動伝搬のまま保持しても Dev・Stg や今後追加される十数本のスポーク VPC の経路はそもそも DXGW で遮断されるため届かず、1 Gbps Direct Connect とピーク 4,000 pps 程度のトラフィックでは処理負荷も気になりません。設定はフィルタリングの一行で済み、以降の増設・削除に伴う運用作業が実質ゼロになる点が大きなメリットです。
Transit Gateway ルートテーブルを VPC ごとに分割して関連付けを管理する方法もありますが、スポークが十を超えて増えるたびにルート伝搬の有無を手動または IaC で調整しなければならず、タグ付けや優先度設定のヒューマンエラーが発生しやすくなります。Virtual Private Gateway＋VPN へ切り替えると 1.25 Gbps 制限や接続料金・運用監視コストが加算され、PrivateLink ではルーティング用途そのものが適合しません。allowed prefixes を活用する設計と比べると、これら代替案はいずれも運用負荷とコスト面で不利です。
Direct Connect Gateway のプレフィックスフィルタで経路を制御し、Transit Gateway 側は自動伝搬を維持する構成は「監査要件の順守」「VPC 増設時の無停止スケール」「ルートテーブル設定の簡素化」「DX 帯域課金のみの低コスト」を同時に満たします。複数サービスの役割、帯域性能、将来拡張を俯瞰した総合判断として、既存アーキテクチャを最小変更で活かせるこの方法が最も合理的と言えるでしょう。
-
質問 9 of 20
9. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-153】製造業 A 社は東京リージョンに 3 つの VPC を持つ。
・prod VPC: 10.0.0.0/16
・shared VPC: 10.1.0.0/16
・dev VPC: 10.2.0.0/16
オンプレミス (172.16.0.0/16) とは 1 Gbps Direct Connect を使用し、Direct Connect Gateway (DXGW) と Transit Gateway (TGW) を接続済み。
要件:
1) on-prem⇔prod/shared 間は双方向通信を許可
2) on-prem から dev への到達は拒否
3) dev⇔prod/shared 間は双方向通信を維持
4) 追加運用を最小化し、TGW のルートテーブルで制御すること
どの TGW ルートテーブル構成が最適か。正解不正解ヒントボタン
オンプレ側172.16.0.0/16から prod・shared には通し dev へは閉じたい場合、Transit Gateway のルートテーブルでその経路自体を学習させない設計が最も確実です。Network ACL はステートレスで戻り方向も明示が必要になり、サブネット追加のたびに規則修正が発生します。Direct Connect Gateway が dev のプレフィックスを最初から受け取らなければトラフィック自体が発生せず、運用負荷を大幅に抑えられます。
複数の TGW ルートテーブルを用意すると、アタッチメントごとに関連付けと伝搬の向きを細かく設定できます。prod と shared を同一テーブルに置き自動伝搬し、Direct Connect Gateway 用テーブルと双方向共有、dev は専用テーブルにして core へだけ伝搬すれば dev↔prod/shared は成立しつつ on-prem→dev は経路不在となります。Security Group や Network ACL に追加の調整は要りません。
静的ルートを手で書く構成は CIDR 拡張や VPC 追加のたびに更新が必要となり「追加運用を最小化」という要件と衝突します。auto propagation が効く core-rt、dx-rt、dev-rt の三構成なら prod・shared と on-prem、dev 間で必要な経路だけが自動生成され、不要な方向は存在しません。Transit Gateway のルートテーブル分離という総合判断で選択肢を評価しましょう。
-
質問 10 of 20
10. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-154】金融SaaS企業はネットワークアカウント(us-east-1)に Transit Gateway (TGW) を配置し、AWS RAM で別アカウントの Prod VPC をアタッチしている。
Prod VPC には AZ-1/2 のプライベート 10.0.1.0/24 と 10.0.2.0/24 を関連付け、VPN 越しにオンプレミス (172.16.0.0/16) と通信している。
運用中に AZ-3 へ 10.0.3.0/24 の新サブネットを作成したが、オンプレとの疎通ができない。
高可用性を保ちつつ RTO15分以内で最少変更となる対処はどれか。正解不正解ヒントボタン
Transit Gateway の VPC アタッチメントでは、どのアベイラビリティーゾーンのどのサブネットを関連付けるかを作成時に明示する必要があります。後から新しい AZ にサブネットを増やしても、自動では TGW ENI が配置されず、Site-to-Site VPN から届く 172.16.0.0/16 の経路も VPC 内へ流れません。「サブネットをアタッチメントへ追加してルート伝播を有効化する」という二つの設定がそろって初めてオンプレミスとの疎通が成立する点を確認してみてください。
TGW をハブとするネットワーク設計では、AWS RAM を使って共有されたスポーク VPC に対し、VPN で学習したプレフィックスがルートテーブルへ自動伝播される仕組みが高可用性を支えます。VPC ピアリングはトランジティブルーティングを許可しないため、TGW で集中管理している 172.16.0.0/16 をそのまま流すことはできません。既存のハブ＆スポーク構成を崩さず、AZ を追加しただけで経路も自動反映させることが最小変更かつ運用負荷を抑える鍵になります。
RTO15分以内という要件では、ポリシーベース VPN への切替えや大量の静的ルート追加のようにダウンタイムや作業手順が増える選択肢より、既存 Transit Gateway アタッチメントの設定を編集して AZ-3 のサブネットを関連付けるだけで完結する手法が現実的です。この方法ならルート伝播により経路配布も自動化され、AZ-1/2 のトラフィックに影響を与えずに短時間で復旧できます。複数の要件を横断して眺め、影響範囲と作業量の少なさを両立できるかを総合的に判断する視点が解答への近道です。
-
質問 11 of 20
11. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-155】国内動画配信企業は 4 アカウント・3AZ・20 本スポーク VPC のハブ＆スポーク環境を AWS Transit Gateway(TGW) で運用し、Direct Connect Gateway 経由でオンプレとも接続している。
新たに AWS Network Firewall を配置したインスペクション VPC を追加し、1) 全 VPC 間およびオンプレ往復トラフィックを双方向で検査する 2) ステートフル検査に必須の対称ルーティングを維持する 3) ルートテーブルの増大と運用負荷を最小化する、という目標を達成する最適な設計はどれか。正解不正解ヒントボタン
ステートフルな AWS Network Firewall では送信と応答が同じエンドポイントを通る対称ルーティングが欠かせません。Transit Gateway のアプライアンスモードなら TGW が経由点を強制し、ループ防止機能で往復経路を固定できます。通常アタッチメントと違い復路がショートカットされる心配がなく、Direct Connect Gateway から来るトラフィックも一様にインスペクション VPC へ導けるかをまず考えてみてください。
ルートテーブルを膨らませたくない場合、スポーク VPC には「0.0.0.0/0 → TGW」の 1 行だけを置き、詳細な CIDR は Transit Gateway の内部でまとめる方法が有効です。Ingress・Inspection・Egress など役割別に 3 つの TGW ルートテーブルを設けると、20 本の VPC やオンプレ宛ての経路を集約しつつ Network Firewall への誘導を一元管理できます。伝播機能とブラックホール検知を併用すれば運用負荷も最小化できます。
GRE を使う TGW Connect でオンプレ機器へヘアピン転送したり、VPC ピアリングでフルメッシュを組む方法は、レイテンシや接続数上限、トランジティブルーティング不可といったスケール課題が残ります。AZ ごとにエンドポイントを置いた centralized inspection パターンは、AWS Network Firewall と Transit Gateway が提供する高可用性と一元ポリシー配信を両立できるため、トラフィック検査の完全性・対称経路・運用簡素化という三要件を最もバランス良く満たせる構成と判断できます。
-
質問 12 of 20
12. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-156】広告配信 SaaS 企業は、セキュリティチーム専用のアカウント A に Service VPC を置き、Gateway Load Balancer(GWLB) と Auto Scaling されたサードパーティー検査 EC2 を配置した。
プロダクトチームのアカウント B には 3 つのプライベートサブネットを持つアプリ VPC があり、毎秒 5 万 pps で外部 API にアクセスする。
要件は
①全トラフィックを中央で検査
②FW 障害時に自動フェイルオーバー
③運用変更点を最小化。
アプリ VPC 側のルートとエンドポイント設定方針として最も適切なのはどれか。正解不正解ヒントボタン
アプリ側で既存のプライベートサブネットをそのまま活かし全アウトバウンドを中央検査に流すには、VPC ルートテーブルで 0.0.0.0/0 を Gateway Load Balancer Endpoint に向ける方法が最小手数です。GWLBe は ENI と同様に扱われ GENEVE トンネルで Service VPC の Gateway Load Balancer へ転送し、送信元 IP を保持したままサードパーティー EC2 がインスペクションを実施できます。PrivateLink 共有により別アカウントでも RAM で公開するだけなので、アプリチーム側の作業はエンドポイント作成とルート差し替えのみで完結します。
Gateway Load Balancer は Network Load Balancer と同じマルチ AZ 構成を取り、背後の検査 EC2 を Auto Scaling Group に登録しておけばヘルスチェックで不調インスタンスを自動切り離し、フェイルオーバーも AZ 内で即時に行われます。Transit Gateway や NAT Gateway を経由しないためホップが増えずレイテンシを抑制でき、スループットも ENA と GWLB の透明転送により毎秒数万 pps を安定して処理可能です。運用面では ASG の Desired サイズ監視と CloudWatch アラーム程度で済み、変更範囲を最小化できます。
Network Load Balancer ではサブネットのルート先に指定できず、NAT Gateway は必ず Internet Gateway 行きの仕様、Transit Gateway は VPC Peering をネクストホップに取れないという制約を踏まえると、全トラフィック検査・ファイアウォール障害時の自動迂回・設定変更の少なさという三要件を同時に満たせるのは Gateway Load Balancer Endpoint を各サブネットに置きデフォルトルートをそこへ向ける構成だと総合的に判断できます。
-
質問 13 of 20
13. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-157】FinTech企業A社は、東京リージョンのProdアカウントVPC(10.0.0.0/16)とオレゴンリージョンのDevアカウントVPC(10.1.0.0/16)間で毎秒800 Mbpsの双方向レプリケーションを行う。
オンプレミスDC(AS 64512)とはIPsecのみで接続可能で、DC⇔両VPC間も合計1 Gbps以上のスループットを維持しつつ、95パーセンタイルレイテンシ50 ms以内、RTO5分、月間99.99%可用性を要求する。
今後5以上の新VPC追加が予定され、ルート運用負荷とコストは最小化したい。
最も適切なネットワーク設計を選択せよ。正解不正解ヒントボタン
オンプレミスが「IPsecのみ許可」と明記されているため、Direct Connectを前提とするCloud WAN＋DXプランは早い段階で除外できます。代わりにTransit GatewayはSite-to-Site VPNを2本以上並列化してECMPで帯域を合算でき、マルチAZ内で月間99.99%のSLAを持つため、1 Gbps超スループットと高可用性、RTO5分を同時に満たす基盤になります。さらに自動フェイルオーバが数十秒で完了するため復旧目標も達成しやすく、将来のVPC追加時はTGWアタッチとBGP設定だけで済むので運用負荷を最小化できます。
東京–オレゴン間で双方向800 Mbpsを常時流す場合、リージョン間の最低帯域は5 Gbpsクラスが望ましく、VPCピアリングでも理論上は届きますが、VPCが5つ以上増えるとフルメッシュ接続数とルート表が爆発します。Transit Gatewayピアリングはハブアンドスポーク型でルートを集約し、リージョン内50 Gbps・クロスリージョンでも5 Gbps超のスループットを提供するため帯域余裕が大きいです。各VPCはTGWへのアタッチだけで相互接続が確立するため、経路配布やセキュリティポリシーが一元管理でき、スケールと運用性で優位に立てます。
レイテンシ95パーセンタイル50 ms以内、高可用性99.99%、RTO5分、1 Gbps超スループット、今後のVPC拡張とコスト低減という複数条件を俯瞰すると、マルチAZで動作しVPNを冗長ECMP化できるTransit Gatewayを各リージョンに配置し、TGWピアリングで結ぶハブアンドスポーク構成がクラウド間通信とオンプレミス接続の両面をバランス良く満たす最適な総合判断となります。
-
質問 14 of 20
14. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-158】金融企業F社はAWS Organizations配下に「net」「app1」「app2」の3アカウントを保有する。
netアカウントの東京リージョンにTransit Gateway(tgw-001)を配置し、app1(10.1.0.0/16)とapp2(10.2.0.0/16)のVPCをアタッチして東西5 Gbpsで通信させたい。
要件:
①IaCでアタッチメントを自動作成
②招待や承諾を人手に頼らず組織内だけに限定
③将来追加される多数VPCにも横展開可能。
最適な設計はどれか。正解不正解ヒントボタン
Transit Gateway には auto-accept shared attachments というプロパティがあり、有効化すると AWS Organizations 内から届く VPC アタッチ要求を瞬時に取り込みます。さらに AWS RAM で「組織単位」共有を設定すると OU 配下に今後追加されるアカウントや VPC も招待レスで連携できるため、個別アカウント共有で必要な Invite や AcceptResourceShareInvitation を全廃でき、CI/CD パイプラインや Terraform コードを極小化して要件②③の運用負荷を根底から削減できます。
IaC の観点ではアプリ側で CreateTransitGatewayVpcAttachment だけを書けば完結する構成が理想です。auto-accept を有効にすると AcceptResourceShareInvitation を組み込むテンプレートも Lambda スクリプトも不要となり、CloudFormation や CDK のスタックがシンプルに保てます。これにより検証環境のクローンや Blue/Green デプロイでもネットワーク待ち時間がなくなり、金融システムが求める RTO／RPO を短縮できる点が要件①とも合致します。
東西 5 Gbps を集中制御するなら net アカウントに単一の Transit Gateway を置く中央集約型がベストプラクティスで、複数 TGW ピアリングや VPC ピアリングはルート爆発と手作業負荷を招きます。auto-accept と OU 共有を併用すれば拡張性・自動化・セキュリティ境界を同時に満たせるため、可用性、運用コスト、スケーラビリティという複数要件を俯瞰した総合判断として最も合理的な選択肢となります。
-
質問 15 of 20
15. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-159】メディア企業 A 社は、1 リージョン内の 3 つの VPC を Transit Gateway でハブ＆スポーク接続し、TGW マルチキャスト機能を用いて 239.0.0.1:5000/UDP のライブ映像を配信している。
各 VPC の送信元／受信先サブネットは登録済みだが、視聴端末が IGMPv2 Join を送信してもストリームを受信できない。
ルートとセキュリティグループは要件を満たしていることを確認済みで、残る作業はネットワーク ACL の調整だけである。
AWS の推奨に従い、どの NACL 設定を追加すべきか。正解不正解ヒントボタン
Transit Gateway マルチキャストでは IGMP Join/Leave が IP プロトコル番号 2 で流れるものの Network ACL はステートレスなため戻り方向も明示的に許可する必要があります。視聴端末が Join を送っても CloudWatch VPC Flow Logs に ACCEPT が映らない場合はこの双方向許可漏れが原因となることが多いので、プロトコル 2 を受信・送信の両方で開く手順を AWS Transit Gateway のガイドから確認してみてください。
さらに実際の映像ペイロードは UDP で 224.0.0.0/4 のマルチキャストアドレスからエフェメラルポート 1024-65535 を用いて流れます。Amazon VPC の Network ACL でこの広いポート帯域を双方向 ALLOW にしないとステートレス特性により復路が BLOCK されライブ配信が途切れます。UDP 5000 番だけを開けても疎通しないという現象はこの仕様を照らし合わせて考えると腑に落ちるはずです。
最終的には「IGMP 用にプロトコル 2 を 0.0.0.0/0 で許可しデータプレーン用に UDP 1024-65535 の 224.0.0.0/4 宛・送信元を許可」という AWS ドキュメント推奨設定が Network ACL に求められます。Security Group はステートフルで補助的ですがマルチキャスト制御は主に NACL 側で行われる点、送信方向も必ず開ける点、複数 VPC を Transit Gateway で接続する場合でも原則は同じという全体像を俯瞰して最適な構成を導き出してください。 -
質問 16 of 20
16. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-160】金融機関 A 社は 2 つの AWS アカウント (prod / sec) にまたがり、同一リージョンに 6 つのマイクロサービス VPC と 1 つの検査 VPC を保有している。
全 VPC は AWS Transit Gateway (TGW) に接続済みで、オンプレミスとは AWS Direct Connect で接続されている。
要件
1. VPC 間通信はレイテンシ最優先のため直接ルーティングし、検査対象外とする。
2. オンプレミス⇔各 VPC 間のトラフィックはサードパーティ製ファイアウォールで透過的に L3－L7 検査し、20 Gbps までスケールアウト可能とする。
3. ファイアウォール更改時のダウンタイムを最小化する。
この要件を満たす TGW と Gateway Load Balancer (GWLB) の設計として、最も適切なものはどれか。正解不正解ヒントボタン
Transit Gateway ではレイテンシを抑えて VPC 間を素通りさせつつオンプレミス経路だけを検査させるために、スポーク用と検査用でルートテーブルを分離し、スポーク側では 0.0.0.0/0 を検査アタッチメントへ送り込む一方で VPC CIDR は TGW が直接ルーティングするよう設定すると、アプリ間通信の遅延を最小化しながら要件 1 の対象外化を自然に満たせます。
20 Gbps までスケールしダウンタイムを避けてファイアウォールを更新するには、検査 VPC 内に Gateway Load Balancer と GWLB エンドポイントを集中配置し、ターゲットグループで EC2 アプライアンスをホットスワップする構成が効果的です。ヘルスチェックとフロー一貫性を備えた GWLB が透過的にトラフィックを振り分けることで、個別ルーティング案より高い可用性と運用容易性が得られます。
ステートフル検査の対称性確保、低レイテンシ VPC 間通信、オンプレミス往復のインライン検査という複数要件を俯瞰すると、Transit Gateway のアプライアンスモードで検査アタッチメントを介し Direct Connect Gateway 経路を折り返し、中央の Gateway Load Balancer で水平拡張する組み合わせが最も合理的な総合解となります。
-
質問 17 of 20
17. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-161】証券取引データを扱う企業では、Account-A の送信アプリケーション (UDP 239.10.0.1/30000) を Account-B の 2 台の EC2 のみが受信できるようにしたい。
両 VPC は同一リージョンで既に Transit Gateway (TGW) にアタッチ済みで、今後は受信インスタンスの増減を容易にしたい。
要件は次のとおり：
・TGW マルチキャストを用いてクロス VPC にレプリケートする
・他の ENI や VPC にはパケットを配信しない
・最小限のポート範囲のみをセキュリティグループで許可する
・運用負荷を低く保ち、インスタンス単位で動的に加入・離脱させる
これらの要件を同時に満たす最適なアプローチはどれか。正解不正解ヒントボタン
Transit Gateway マルチキャストは既存の VPC アタッチメントをそのままドメインに関連付け、送信側 ENI をソース、受信側 ENI をリスナーとして join させるだけで 239.10.0.1/30000 をリージョン内レプリケートできます。API で ENI 単位の join/leave が可能なため EC2 の増減時も CLI 一発で済み、他アタッチメントや VPC へは流れず運用負荷と影響範囲を最小に抑えられます。
セキュリティグループは UDP 239.10.0.1/32:30000 のみをインバウンド許可すれば十分で、0.0.0.0/0 や 224.0.0.0/4 を開放するよりはるかに最小権限を保てます。TGW 自体がマルチキャストをルーティングしてくれるため、ルートテーブルや IGMP 設定は不要、ポート制御だけに集中して堅牢性を高められます。
要件を俯瞰すると、既存 Transit Gateway を使って追加装置を置かず、ENI 単位で受信者を選び、239.10.0.1/30000 だけを許可する最小権限のセキュリティグループとし、API で動的に join/leave できる仕組みが、配信制御・セキュリティ・運用効率の全てを同時に満たす最適解だと判断できます。
-
質問 18 of 20
18. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-162】本社決済部門が所有する VPC では NLB 配下の REST API を Interface VPC エンドポイント (vpce-svc) で公開し、AWS RAM で開発アカウント 111111111111 の VPC-A に共有している。
VPC-A では
1) FQDN「api.internal.example.com」で名前解決し、プライベート IP にのみ接続する
2) API 呼び出しを IAM ロール AppRole だけに許可する
3) 管理作業を最小に抑える
という要件がある。
どの構成が最も適切か。正解不正解ヒントボタン
Interface VPC エンドポイントを AWS RAM で受け取った側が api.internal.example.com という独自 FQDN だけでプライベート IP に到達させたいなら、プライベート DNS を無効化しておき、VPC-A 内の Route 53 プライベートホストゾーンに ALIAS レコードで固有 DNS 名を向ければ、エンドポイントが自動生成する *.vpce.amazonaws.com の競合を避けつつシンプルに名前解決を完結でき、追加の Resolver エンドポイントやクロスアカウント関連付け作業も不要となるのです。
Interface VPC エンドポイントのポリシーは JSON で IAM プリンシパルを細かく列挙できるため、arn:aws:iam::111111111111:role/AppRole だけを Allow にし Principal や Action を限定すれば、VPC セキュリティグループや NLB リスナーでの追加制御なしに REST API への呼び出しを単一ロールへ閉じ込められ、開発アカウント内の他ユーザーや Lambda からの想定外アクセスを確実に遮断できます。
Route 53 Resolver のフォワーディングやサービス側でのプライベートホストゾーン共有は運用者が二つの VPC と複数アカウントでリソース関連付けを維持する負荷を生む一方、利用側だけにプライベートホストゾーンとエンドポイントポリシーを配置する方式なら変更範囲が単一アカウントで済み、API の完全内製 FQDN、AppRole での IAM 制御、最小限の設定手順という三要件を全角度から同時に満たせます。 -
質問 19 of 20
19. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-163】大手 EC 企業は 3 つの AWS アカウントで決済マイクロサービスを Amazon ECS Fargate 上に稼働させている。
サービスは VPC-A のプライベートサブネット (デュアルスタック) を AWS RAM で共有し利用する。
要件は次のとおり。
1) 外部からの着信は許可しない、2) 1 万同時接続までの IPv4 アウトバウンド、3) IPv6 は NAT による課金を避けたい、4) AZ 障害時も通信を継続する。
最適なネットワーク設計はどれか。正解不正解ヒントボタン
決済コンテナを載せた Amazon ECS Fargate はプライベートサブネットに閉じ込めつつも外部へ出る必要があります。IPv4 の同時 1 万接続を安全に扱うには、EC2 で構築する NAT インスタンスより 1AZ に 1 つずつ配置する NAT Gateway が有利で、55,000 セッション／AZ の処理能力とマネージド冗長性が確保できます。NAT Gateway は Internet Gateway と紐づくパブリックサブネットに置き、ルートテーブルで 0.0.0.0/0 を向けることで、非公開環境を保ちながら送信トラフィックのみを許可できます。
IPv6 トラフィックはアドレス変換を伴わず直接 Internet Gateway に出られるため、NAT Gateway を通すと料金とレイテンシが増すだけです。各 AZ のプライベートサブネットで ::/0 を IGW に、0.0.0.0/0 を同 AZ の NAT Gateway に振り分けるルーティングを設定すれば、デュアルスタック環境で「IPv6 は NAT 課金を避けたい」という条件を満たしつつ、IPv4 のみ NAT 変換させるハイブリッドなエグレス設計が実現できます。
複数 AZ の耐障害性を求める場合、NAT Gateway と IGW を AZ ローカルに分散し、共有 VPC のルートも各 AZ 内で閉じることが AWS Well-Architected で推奨されます。Transit Gateway で中央 NAT を集約したり Interface VPC エンドポイントに限定すると可用性や通信範囲が制限されるため、外部着信拒否・IPv4 大量接続・IPv6 コスト削減・AZ 障害耐性という四つの要件を総合的に満たす設計を選びましょう。
-
質問 20 of 20
20. 質問
カテゴリ: ANS-2.2さまざまな接続パターンをサポートするために、複数のAWS アカウント、リージョン、VPC にルーティングと接続を実装する。【ANS-164】2 つの AWS アカウントを持つ開発会社は、Account B（us-east-1）の VPC B に配置した AWS Client VPN（/22、同時 1 000 接続）を通じて、Account A（ap-southeast-1）の VPC A（10.0.0.0/16）内のマイクロサービスへ私設網経由でアクセスさせたい。
要件は
①インターネット経由通信を禁止、
②月額コストを 200 USD 未満に抑制、
③レイテンシ低減のため NAT Gateway や追加プロキシを置かない、
④名前解決は Route 53 Private Hosted Zone をそのまま使う、である。
最も適切なネットワーク設計はどれか。正解不正解ヒントボタン
インターネットを経由しないという条件を軸に考えると、Site-to-Site VPN は IPSec トンネル終端でパブリック IP を使うので外部網を通りますが、VPC ピアリングや Transit Gateway の VPC アタッチメントは AWS グローバルバックボーン上を直接流れるため閉域となります。NAT Gateway や追加プロキシを置かない低レイテンシ要件とも整合が取りやすく、ピアツーピア型の単純接続ほど経路が短くなります。
月額 200USD 以内という制約は料金モデルの差が鍵です。Transit Gateway はアタッチメントごとに時間課金＋データ課金、Site-to-Site VPN もトンネル数だけ時課金が重なり、PrivateLink はエンドポイントが増えるほど固定費が増大します。対してクロスリージョン VPC ピアリングは時間単価がなくデータ転送料のみなので、小規模開発で 1 000 クライアント程度の往復トラフィックであれば上限を超えにくく、コスト予測が立てやすいことが強みです。
Route 53 Private Hosted Zone をそのまま利用するには DNS 転送の自動化が重要です。VPC ピアリングは「DNS 解決オプション」を有効化するだけでクロスリージョンでもプライベート DNS 名が解決可能ですが、PrivateLink ではカスタムレコード作成、VPN や Transit Gateway では DNS フォワーダー設定が追加で必要になります。通信経路、料金、名前解決の三要素を総合的に見ると、最小構成で全要件を同時に満たせる設計が自然に浮かび上がってきます。
改善リクエスト