模擬問題集一覧

ANS-C01 模擬問題集（練習問題）

AWS Advanced Networking – Specialty 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

ANS-C01（AWS Advanced Networking – Specialty）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

ANS-C01 の操作は、実機のハンズオンラボで身につける

問題集で覚えた知識を、本物の Azure・AWS 環境で手を動かして確かめられます。 Pro プランなら ANS-C01 対応のハンズオンラボ 7 本と、この問題集の全 200 問がすべて使えます。 ラボは会員登録だけで 1 本無料で試せます。

ANS-C01 の対応ラボを見る（7 本）ラボを 1 本無料で試す

ANS-C01 の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はANS-C01 の学習ガイドにまとめています。

ANS-C01 の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1この要件を満たすソリューションはどれですか?ネットワークのセキュリティ、コンプライアンス、ガバナンス
問題
ある企業が、自動販売機の在庫レベルを追跡し、補充プロセスを自動的に開始するアプリケーションを AWS 上で開発しました。同社はこのアプリケーションを自動販売機と統合し、世界中の複数の市場に自動販売機を展開する計画です。アプリケーションは us-east-1 リージョンの VPC に存在します。アプリケーションは、Application Load Balancer (ALB) の背後にある Amazon Elastic Container Service (Amazon ECS) クラスターで構成されています。自動販売機からアプリケーションへの通信は HTTPS で行われます。 同社は AWS Global Accelerator のアクセラレーターを使用し、アクセラレーターの静的 IP アドレスを自動販売機に設定して、アプリケーションのエンドポイントにアクセスする計画です。アプリケーションはアクセラレーター経由でのみアクセス可能でなければならず、インターネット経由で ALB エンドポイントへ直接接続することはできないようにする必要があります。 この要件を満たすソリューションはどれですか?

選択肢と解説

  • 1
    ALB を VPC のプライベートサブネットに配置する。インターネットゲートウェイをアタッチするが、サブネットのルートテーブルにインターネットゲートウェイを指すルートは追加しない。アクセラレーターを、ALB エンドポイントを含むエンドポイントグループで構成する。ALB のセキュリティグループを、ALB リスナーポートでインターネットからのインバウンドトラフィックのみを許可するように構成する。
  • 2
    ALB を VPC のプライベートサブネットに配置する。アクセラレーターを、ALB エンドポイントを含むエンドポイントグループで構成する。ALB のセキュリティグループを、ALB リスナーポートでインターネットからのインバウンドトラフィックのみを許可するように構成する。
  • ✓
    ALB を VPC のパブリックサブネットに配置する。インターネットゲートウェイをアタッチする。サブネットのルートテーブルにインターネットゲートウェイを指すルートを追加する。アクセラレーターを、ALB エンドポイントを含むエンドポイントグループで構成する。ALB のセキュリティグループを、ALB リスナーポートでアクセラレーターの IP アドレスからのインバウンドトラフィックのみを許可するように構成する。
  • 4
    ALB を VPC のプライベートサブネットに配置する。インターネットゲートウェイをアタッチする。サブネットのルートテーブルにインターネットゲートウェイを指すルートを追加する。アクセラレーターを、ALB エンドポイントを含むエンドポイントグループで構成する。ALB のセキュリティグループを、ALB リスナーポートでアクセラレーターの IP アドレスからのインバウンドトラフィックのみを許可するように構成する。

解説

【正解】C

【0からの解説】
AWS Global Accelerator は、世界中のユーザーに対して 2 つの固定アンキャスト IP アドレス（静的 IP）を提供し、AWS のグローバルネットワーク（エッジロケーション）を経由して、最も近いリージョンのエンドポイント（ALB/NLB/EC2/Elastic IP）へトラフィックを最適経路で転送するサービスです。本問では、ALB をアクセラレーターのエンドポイントグループに登録します。

要件は次の 2 点です。
(1) アクセラレーター経由でのみアクセスでき、(2) インターネットから ALB へ直接アクセスできないようにする。

ALB をインターネット向け（internet-facing）エンドポイントとして Global Accelerator に登録するには、ALB がパブリックサブネットに配置され、インターネットゲートウェイ (IGW) がアタッチされ、サブネットのルートテーブルに IGW へのルートが必要です（ALB がインターネットからのトラフィックを受け取れる状態）。これが選択肢 C の「パブリックサブネット + IGW + ルート追加」です。

そのうえで「アクセラレーター経由のみ」という制限を実現するには、ALB のセキュリティグループのインバウンドルールを、Global Accelerator が使用する IP アドレス範囲のみに絞り込みます。Global Accelerator の IP 範囲は AWS が公開している ip-ranges.json の「GLOBALACCELERATOR」サービスから取得でき、これを送信元に指定すれば、アクセラレーターを通らない直接アクセスはセキュリティグループでブロックされます。これが C の「アクセラレーターの IP アドレスからのインバウンドのみ許可」に対応します。よって C が要件を完全に満たします。

【誤りの選択肢】
A：プライベートサブネットに ALB を置き、かつ IGW へのルートを追加しない構成です。これではインターネット向け ALB として機能せず、Global Accelerator のエンドポイントとして外部トラフィックを受けられません。さらにセキュリティグループが「インターネットからのインバウンドを許可」となっており、アクセラレーター経由のみという制限も満たしません。
B：プライベートサブネット配置で IGW の記述もなく、インターネット向け ALB として成立しません。加えてセキュリティグループが「インターネットから許可」のため、直接アクセスを排除する要件を満たしません。
D：セキュリティグループはアクセラレーター IP のみ許可で正しいものの、ALB を「プライベートサブネット」に置きつつ IGW ルートを追加するという矛盾した構成です。インターネット向け ALB はパブリックサブネット（IGW へのデフォルトルートを持つサブネット）に配置するのが要件であり、プライベートサブネットという記述が誤りです。正しくはパブリックサブネットに置く C が適切です。

※補足：ExamTopics の Most Voted は D ですが、インターネット向け ALB を Global Accelerator のエンドポイントとして用いる本構成では ALB をパブリックサブネットに配置する必要があり、「プライベートサブネット + IGW ルート」という D の記述は構成として矛盾しています。アクセスをアクセラレーター経由に限定するセキュリティグループ条件は C・D とも同一であるため、サブネットの記述が正しい C を本解説の正解とします。

【参考】
Secure VPC connections in AWS Global Accelerator
AWS Global Accelerator のエンドポイントへのアクセスをセキュリティグループで制限する
この問題のページを開く →
問題 2ネットワーク設計ネットワーク設計
問題
ある小売企業が、オンプレミスのアプリケーションを AWS クラウドへ移行しようとしています。現在、同社にはオンプレミスのデータセンターが 2 拠点あります。1 つは米国東海岸、もう 1 つは西海岸にあります。 各データセンターは 4 つのデータベースシステムをホストしています。最大のデータベースシステムは 500 GB のデータを保存しています。2 つのデータセンターは、データ同期のために 2 本の 10 GbE 回線で相互接続されています。各データセンターには、それぞれ別個の 1 GbE の上り（アップストリーム）インターネット接続が 2 本あります。同社は複数の事業部門にサービスを提供するため、合計 8 つの VPC を持つ計画です。4 つの VPC は us-east-1 リージョンに、4 つは us-west-2 リージョンに配置されます。 ネットワークエンジニアは、VPC 間接続を可能にする接続ソリューションを設計する必要があります。さらに、移行プロセス中はオンプレミスのデータセンターと AWS の間でセキュアな接続も可能にする必要があります。同社は、データベース同期の際に VPC 間のトラフィックがスパイク（急増）すると予想しています。同社は移行計画を 1 週末で、かつ技術的に可能な限り早く実行したいと考えています。また、長期的な運用および人的リソースのコストを最小化したいと考えています。 これらの要件を満たすステップの組み合わせはどれですか?（2 つ選択）

選択肢と解説

  • ✓
    1 つの Transit Gateway をデプロイし、すべての VPC をそれにアタッチする。Transit Gateway と VPC のルートテーブルを更新し、任意の VPC が他の任意の VPC に接続できるようにする。
  • 2
    すべての VPC 間で VPC ピアリングを構成する。VPC のルートテーブルを更新して接続を許可する。
  • 3
    us-east-1 と us-west-2 を提供する 2 つの Direct Connect ロケーションから 2 本の AWS Direct Connect 接続をプロビジョニングし、データセンターと AWS の間の接続を提供する。
  • ✓
    各データセンターに対して 1 つの Transit Gateway VPN アタッチメントをプロビジョニングし、オンプレミスのデータセンターと AWS VPC の間の接続を構築する。
  • 5
    各データセンターおよび各 VPC に対して 1 つの AWS Site-to-Site VPN 接続をプロビジョニングし、オンプレミスのデータセンターと AWS VPC の間の接続を構築する。

解説

【正解】A、D

【0からの解説】
要件を整理すると、(1) 8 つの VPC（2 リージョンにまたがる）間の相互接続、(2) 移行中のオンプレミス〜AWS のセキュアな接続、(3) VPC 間トラフィックのスパイクに耐える、(4) 1 週末で迅速に構築、(5) 長期的な運用・人的コストを最小化、です。

■ VPC 間接続には Transit Gateway（A）
AWS Transit Gateway は、多数の VPC・VPN・Direct Connect をハブ＆スポーク型で集約接続する中央ハブです。8 個の VPC をフルメッシュで VPC ピアリングすると、必要なピアリング数は n(n-1)/2 = 8×7/2 = 28 本となり、各 VPC のルートテーブル管理が爆発的に複雑化します。Transit Gateway なら各 VPC を 1 回アタッチするだけで全 VPC が相互接続でき、ルート管理も中央集約されるため運用コストが最小です。さらに Transit Gateway Peering を使えば us-east-1 と us-west-2 のリージョン間も接続できます。同期時のトラフィックスパイクにも Transit Gateway は十分なスループットでスケールします。

■ オンプレミス〜AWS のセキュアな接続には Transit Gateway VPN アタッチメント（D）
「1 週末で技術的に可能な限り早く」という要件が決定的です。AWS Direct Connect の物理回線の新規プロビジョニングは数週間〜数か月かかるため、週末の移行には間に合いません。一方、AWS Site-to-Site VPN（IPsec）は既存のインターネット回線（各 DC の 1 GbE×2）の上に数分〜数時間で構築でき、暗号化されたセキュアな接続を提供します。これを Transit Gateway の VPN アタッチメントとして接続すれば、各データセンターからの VPN がそのまま全 VPC に到達できます。アタッチメントは各データセンターにつき 1 つで済むため、構成も運用もシンプルです。

したがって A（Transit Gateway で VPC 間接続）と D（DC ごとに Transit Gateway VPN アタッチメント）の組み合わせが最適です。

【誤りの選択肢】
B：8 VPC のフルメッシュ VPC ピアリングは 28 本必要で、ルートテーブル管理が極めて煩雑になり、長期的な運用・人的コストを最小化する要件に反します。また VPC ピアリングは推移的ルーティング非対応のため、ハブ集約のメリットも得られません。
C：Direct Connect の専用線を 2 本新規プロビジョニングするには通常数週間〜数か月かかり、「1 週末で迅速に」という要件を満たせません。移行フェーズの暫定接続としては VPN が適切です。
E：各データセンターと「各 VPC」に Site-to-Site VPN を張る構成は、2 DC × 8 VPC で多数の VPN トンネルを個別管理することになり、運用コストが膨大です。Transit Gateway に VPN アタッチメント（D）すれば DC あたり 1 接続で全 VPC に到達でき、はるかに効率的です。

【参考】
AWS Transit Gateway とは
Transit Gateway の VPN アタッチメント
この問題のページを開く →
問題 3この要件を満たすソリューションはどれですか?ネットワーク設計
問題
ある企業が、アプリケーションのフロントエンドが同一 VPC 内の Network Load Balancer (NLB) を介してバックエンドインスタンスと通信するアプリケーションをデプロイしました。アプリケーションは 2 つのアベイラビリティーゾーン（AZ）にまたがって高可用性を備えています。同社は、AZ をまたいで移動するトラフィックの量を制限したいと考えています。アプリケーションのフロントエンドからのトラフィックは、その AZ 内の NLB 配下に正常なターゲットが存在しない場合を除き、同一 AZ 内にとどまる必要があります。同一 AZ 内に正常なターゲットがない場合は、トラフィックは他方の AZ に送信されなければなりません。 この要件を満たすソリューションはどれですか?

選択肢と解説

  • 1
    AZ ごとに加重ルーティングのプライベートホストゾーンを作成する。プライマリレコードをローカル AZ の NLB DNS レコードに向ける。セカンダリレコードをリージョンの NLB DNS レコードに向ける。アプリケーションのフロントエンドが、ローカルのプライベートホストゾーンレコードに対して DNS ルックアップを行うよう構成する。
  • 2
    NLB のクロスゾーン負荷分散をオフにする。アプリケーションのフロントエンドが、ローカル AZ の NLB DNS レコードに対して DNS ルックアップを行うよう構成する。
  • ✓
    プライベートホストゾーンを作成する。AZ ごとにフェイルオーバーレコードを作成する。各フェイルオーバーレコードについて、プライマリレコードをローカル AZ の NLB DNS レコードに向け、セカンダリレコードをリージョンの NLB DNS レコードに向ける。アプリケーションのフロントエンドが、ローカルのプライベートホストゾーンレコードに対して DNS ルックアップを行うよう構成する。
  • 4
    スティッキーセッション（セッションアフィニティ）を有効にして、NLB がユーザーのセッションを同一 AZ 内のターゲットにバインドできるようにする。

解説

【正解】C

【0からの解説】
まず Network Load Balancer (NLB) のゾーン DNS の仕組みを理解します。NLB を作成すると、各 AZ にゾーン固有の DNS 名（例: us-east-1a.my-nlb-xxxx.elb.amazonaws.com）と、全 AZ を含むリージョン DNS 名（my-nlb-xxxx.elb.amazonaws.com）が払い出されます。

クロスゾーン負荷分散をオフにした NLB では、各ゾーン固有の DNS 名にアクセスすると、その AZ 内のターゲットにのみトラフィックが分散されます。これを使えば「同一 AZ にとどめる」ことができますが、問題はそのゾーンに正常なターゲットが 1 つもなくなったときです。クロスゾーン無効の NLB では、AZ 内に正常なターゲットがなくなると、その AZ の NLB ノードの IP は DNS 応答から外れますが、ゾーン固有 DNS 名だけを使っていると他 AZ へ自動的にフェイルオーバーする確実な仕組みが弱くなります。

そこで Route 53 のフェイルオーバールーティングを組み合わせます。AZ ごとに、プライマリレコード＝ローカル AZ のゾーン NLB DNS 名、セカンダリレコード＝リージョン NLB DNS 名（全 AZ をカバー）とし、ヘルスチェックでプライマリを監視します。通常時はプライマリ（ローカル AZ）が応答してトラフィックは同一 AZ にとどまり、ローカル AZ に正常なターゲットがなくなるとヘルスチェックが失敗してセカンダリ（リージョン全体）に切り替わり、他方の AZ へトラフィックが流れます。これがまさに要件「同一 AZ 優先、なければ他 AZ」を満たすため、C が正解です。

【誤りの選択肢】
A：加重（weighted）ルーティングは指定した重みの比率でトラフィックを振り分ける仕組みで、ヘルスチェックに基づく「プライマリが落ちたらセカンダリ」という明確なフェイルオーバー挙動を本来の目的としていません。フェイルオーバー要件にはフェイルオーバールーティング（C）が適切です。
B：クロスゾーン負荷分散をオフにしてゾーン固有 DNS をルックアップすれば同一 AZ には保てますが、ローカル AZ のターゲットが全滅したときに他 AZ へ確実にフェイルオーバーさせる仕組みが欠けています。Route 53 フェイルオーバーによるセカンダリ（リージョン全体）への切り替えがないため、要件の後半（なければ他 AZ へ）を満たしきれません。
D：スティッキーセッションはクライアントのセッションを特定のターゲットに固定する機能であり、「AZ をまたぐトラフィックを抑制し、なければ他 AZ にフォールバックする」という AZ レベルのルーティング制御は実現できません。要件と無関係です。

【参考】
Network Load Balancer のゾーン別 DNS とクロスゾーン負荷分散
Route 53 フェイルオーバールーティングポリシー
この問題のページを開く →
問題 4これらの要件を満たす、最も運用効率の高い（MOST operationally efficient）ソリューションは何で…ネットワークのセキュリティ、コンプライアンス、ガバナンス
問題
ある企業が、外部向けのウェブサイトを AWS でホストする計画です。ウェブサイトには、ウェブサーバー、アプリケーションロジックサービス、データベースなど複数の階層（ティア）が含まれます。同社はネットワークセキュリティのために、AWS Network Firewall、AWS WAF、VPC セキュリティグループを使用したいと考えています。 同社は、Network Firewall のファイアウォールが該当する VPC 内に適切にデプロイされることを保証する必要があります。また、Network Firewall および AWS WAF のルールにデプロイされるポリシーを一元的に管理できる必要があります。さらに、アプリケーションチームが自分たちのセキュリティグループを管理できるようにしつつ、それらのセキュリティグループが過度に緩い（permissive な）アクセスを許可しないようにする必要があります。 これらの要件を満たす、最も運用効率の高い（MOST operationally efficient）ソリューションは何ですか?

選択肢と解説

  • 1
    Network Firewall のファイアウォール、AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループをコードで定義する。AWS CloudFormation を使ってオブジェクトと初期ポリシー・ルールグループをデプロイする。CloudFormation を使って AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループを更新する。Amazon GuardDuty を使って過度に緩いルールを監視する。
  • 2
    Network Firewall のファイアウォール、AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループをコードで定義する。AWS マネジメントコンソールまたは AWS CLI を使って AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループを管理する。Amazon GuardDuty を使って AWS Lambda 関数を起動し、構成されたルールを評価して過度に緩いルールを削除する。
  • 3
    AWS WAFv2 IP セットと AWS WAFv2 Web ACL を AWS CloudFormation でデプロイする。AWS Firewall Manager を使って、必要な場所に Network Firewall のファイアウォールと VPC セキュリティグループをデプロイし、AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループを管理する。
  • ✓
    Network Firewall のファイアウォール、AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループをコードで定義する。AWS CloudFormation を使ってオブジェクトと初期ポリシー・ルールグループをデプロイする。AWS Firewall Manager を使って AWS WAFv2 の Web ACL、Network Firewall ポリシー、VPC セキュリティグループを管理する。Amazon GuardDuty を使って過度に緩いルールを監視する。

解説

【正解】D

【0からの解説】
要件は次の 3 つです。(1) Network Firewall を該当 VPC に適切にデプロイ、(2) Network Firewall と WAF のポリシーを一元管理、(3) アプリチームに SG の管理を委ねつつ過度に緩い SG を防ぐ。これらを「最も運用効率よく」満たす必要があります。

ここで鍵になるのが AWS Firewall Manager です。Firewall Manager は AWS Organizations 全体にわたって、AWS WAF の Web ACL、AWS Network Firewall のポリシー、Amazon VPC セキュリティグループ（および Shield Advanced、Route 53 Resolver DNS Firewall 等）を一元的に管理・自動適用できるサービスです。具体的には、
・WAF と Network Firewall のポリシーを組織横断で一括適用・継続的に強制（新しいアカウント/VPC にも自動適用）
・セキュリティグループに対しては「コンテンツ監査ポリシー」で過度に緩いルール（例: 0.0.0.0/0 で全ポート開放）を検出・是正でき、かつアプリチームに SG の日常管理を委ねつつガードレールを効かせられる
という点で、3 つの要件すべてに直接対応します。

D は「CloudFormation で初期定義・初期デプロイ → 以後 Firewall Manager で WAF・Network Firewall・SG を一元管理、GuardDuty で監視」という構成で、IaC による初期構築と Firewall Manager による継続的な一元管理・強制を両立しており、最も運用効率が高い正解です。

【誤りの選択肢】
A：管理を CloudFormation の更新のみで行う構成で、組織全体への自動適用・継続的な強制や、SG の過剰許可に対するガードレールを一元的に効かせる仕組みがありません。新規 VPC への自動適用も手動になり運用効率が劣ります。また GuardDuty は脅威検知サービスであり「過度に緩いルールの監視」を主目的とする設計ではない点も弱点です。
B：コンソールや CLI による手動管理は運用負荷が高く、一元管理・自動強制の要件に反します。GuardDuty + Lambda で緩いルールを削除する仕組みも作り込みが必要で運用効率が低く、Firewall Manager を使う D に劣ります。
C：Network Firewall や SG の「初期作成」まで Firewall Manager に任せる構成として書かれていますが、複数ティア構成の初期インフラ定義は CloudFormation で行い、Firewall Manager は組織横断のポリシー一元管理・強制に使うのが定石です。C は WAF を CloudFormation、それ以外を Firewall Manager と役割が分散し、コードによる初期定義（IaC）の一貫性に欠け、D ほど整合的・効率的ではありません。

【参考】
AWS Firewall Manager とは
Firewall Manager のセキュリティグループポリシー
この問題のページを開く →
問題 5この要件を満たすソリューションはどれですか?ネットワークのセキュリティ、コンプライアンス、ガバナンス
問題
ある企業が、オンプレミスのデータセンターを AWS クラウドに接続するハイブリッド環境を持っています。このハイブリッド環境は 10 Gbps の AWS Direct Connect 専用接続（dedicated connection）を使用しています。この Direct Connect 接続には、複数の VPC で終端する複数のプライベート VIF があります。 規制に準拠するため、同社は基盤となるトランスポートに関係なく、すべての WAN トラフィックを暗号化する必要があります。同社は、自社の帯域容量に影響を与えない暗号化ソリューションを実装する必要があります。 この要件を満たすソリューションはどれですか?

選択肢と解説

  • 1
    パブリック VIF を作成する。新しい AWS Site-to-Site VPN 接続が、その新しいパブリック VIF を使うように構成する。
  • 2
    既存の Direct Connect 接続のポートで MAC セキュリティ (MACsec) サポートを構成する。暗号化モードを must_encrypt に変更する。
  • ✓
    MAC セキュリティ (MACsec) をサポートする新しい Direct Connect 接続を構成する。既存の VIF を新しい Direct Connect 接続に関連付ける。
  • 4
    パブリック VIF を作成する。Direct Connect 接続を使うプライベート IP VPN を構成する。

解説

【正解】C

【0からの解説】
要件は (1) トランスポートに関係なく WAN トラフィックを暗号化、(2) 帯域容量に影響を与えない、の 2 点です。

暗号化の選択肢は大きく 2 つあります。
・IPsec VPN（Site-to-Site VPN を Direct Connect 上に張る）: 暗号化できますが、IPsec のオーバーヘッドと VPN 終端のスループット上限（AWS 側 VPN トンネルは 1 トンネルあたり最大約 1.25 Gbps）により、10 Gbps の帯域をフルには活かせず「帯域に影響を与えない」要件に反します。
・MACsec（MAC セキュリティ）: レイヤー 2 で回線そのものを回線速度（ラインレート）で暗号化する技術で、Direct Connect の専用接続でサポートされます。ハードウェアで処理するため帯域への影響がほぼなく、10 Gbps をフルに暗号化できます。よって本要件には MACsec が最適です。

ここで重要なのが、MACsec は「接続（ポート）」が MACsec 対応である必要があるという点です。既存の Direct Connect 接続が MACsec 非対応の場合、設定変更だけでは有効化できません。MACsec をサポートする新しい Direct Connect 接続をプロビジョニングし、既存の VIF をその新接続に移行（関連付け）する必要があります。これが選択肢 C であり、正解です。

【誤りの選択肢】
A：パブリック VIF 経由で Site-to-Site VPN を張る構成は、IPsec のトンネルスループット上限により 10 Gbps の帯域をフルに使えず、「帯域容量に影響を与えない」要件を満たせません。
B：MACsec を使う方向性は正しいものの、「既存の接続のポートで MACsec を構成する」とあります。MACsec は接続が MACsec 対応ハードウェアでなければ有効化できず、既存接続が非対応なら設定変更（must_encrypt への変更）だけでは実現できません。MACsec 対応の新規接続が必要なため C が正しい表現です。
D：パブリック VIF を作りつつ「プライベート IP VPN」を構成するという記述で、構成として整合性がありません。プライベート IP VPN（Direct Connect 上の VPN）は transit VIF と Direct Connect ゲートウェイ経由で構成するもので、いずれにせよ IPsec のため帯域上限の問題が残り、要件を満たしません。

【参考】
AWS Direct Connect の MACsec (MAC セキュリティ)
MACsec の前提条件
この問題のページを開く →
問題 6ネットワークのセキュリティ、コンプライアンス、ガバナンスネットワークのセキュリティ、コンプライアンス、ガバナンス
問題
ある企業が、オンプレミスでトラフィックの監視・検査を行うためにサードパーティ製のファイアウォールアプライアンスを使用しています。同社は AWS でも同じモデルを使いたいと考えています。同社には、インターネットゲートウェイを持つ単一の VPC があります。この VPC には、Auto Scaling グループによって管理される Amazon EC2 インスタンス上で動作するウェブサーバーのフリート（群）があります。 同社のネットワークチームはセキュリティチームと協力して、ウェブサーバーとの間で送受信されるすべてのパケットのインライン検査（inline inspection）を確立する必要があります。ソリューションは、仮想ファイアウォールアプライアンスのフリートがスケールするのに合わせてスケールしなければなりません。 このソリューションを実装するために、ネットワークチームが取るべきステップの組み合わせはどれですか?（3 つ選択）

選択肢と解説

  • ✓
    新しい VPC を作成し、ファイアウォールアプライアンスのフリートをデプロイする。Gateway Load Balancer を作成する。ファイアウォールアプライアンスをターゲットとして追加する。
  • 2
    ファイアウォールアプライアンス用のセキュリティグループを作成し、ポート 443 を許可する。Gateway Load Balancer がヘルスチェックを実行するためのポートを許可する。
  • ✓
    ファイアウォールアプライアンス用のセキュリティグループを作成し、ポート 6081 を許可する。Gateway Load Balancer がヘルスチェックを実行するためのポートを許可する。
  • 4
    既存の VPC にファイアウォールアプライアンスのフリートをデプロイする。Gateway Load Balancer を作成する。ファイアウォールアプライアンスをターゲットとして追加する。
  • 5
    インターネットゲートウェイのルートテーブルとウェブサーバーのルートテーブルを更新し、インターネットとの間のトラフィックを Gateway Load Balancer の VPC エンドポイント ID に送る。Gateway Load Balancer エンドポイントに関連付けられたサブネットのルートテーブルを更新し、インターネットトラフィックをインターネットゲートウェイに向ける。
  • ✓
    ウェブサーバー VPC 内に新しいルートテーブルを作成する。インターネットゲートウェイとの新しいエッジアソシエーションを作成する。インターネットゲートウェイのルートテーブルとウェブサーバーのルートテーブルを更新し、インターネットとの間のトラフィックを Gateway Load Balancer の VPC エンドポイント ID に送る。Gateway Load Balancer エンドポイントに関連付けられたサブネットのルートテーブルを更新し、インターネットトラフィックをインターネットゲートウェイに向ける。

解説

【正解】A、C、F

【0からの解説】
本問は Gateway Load Balancer (GWLB) を使ったインライン検査アーキテクチャの典型問題です。GWLB は、サードパーティ製のファイアウォール/IDS/IPS アプライアンスをスケーラブルに配置し、すべてのトラフィックを透過的にそれらへ「バンプ・イン・ザ・ワイヤ」で流す仕組みを提供します。GWLB はターゲット（アプライアンス）と GENEVE プロトコル（UDP ポート 6081）でトラフィックをやり取りします。

正しい設計の要点は次の通りです。

■ A：検査用のアプライアンスは専用の VPC（検査用/セキュリティ用 VPC）に分離してデプロイし、そこに GWLB を作成してアプライアンスをターゲット登録するのがベストプラクティスです。アプライアンスと GWLB を別 VPC に分離することで、管理・スケーリングを独立して行えます。

■ C：アプライアンス用のセキュリティグループでは、GWLB がトラフィックをカプセル化して送る GENEVE のポート 6081（UDP）を許可する必要があります。これがないと GWLB からアプライアンスへトラフィックが届きません。加えてヘルスチェック用のポートも許可します。検査対象のウェブトラフィックがたまたま 443 であっても、GWLB→アプライアンス間は 6081 でカプセル化されるため、許可すべきは 6081 です（B の 443 ではない）。

■ F：ウェブサーバー VPC 側では、インターネットとの送受信トラフィックを GWLB エンドポイント (GWLBe) 経由で検査 VPC に流すよう、複数のルートテーブルを正しく設定します。具体的には、(1) インターネットゲートウェイに「エッジアソシエーション」したルートテーブルを新規作成し、IGW から入ってくるトラフィックを GWLB エンドポイントへ向ける、(2) ウェブサーバーのサブネットのルートテーブルでインターネット向けトラフィックを GWLB エンドポイントへ向ける、(3) GWLB エンドポイントのサブネットのルートテーブルでインターネット向けを IGW へ向ける、という三方向のルーティングを構成します。E はこの「IGW へのエッジアソシエーションを伴う新ルートテーブル作成」が欠けているため不完全で、それを含む F が正解です。

したがって A・C・F の組み合わせが正解です。

【誤りの選択肢】
B：許可ポートが 443 となっていますが、GWLB とアプライアンス間は GENEVE のポート 6081 でカプセル化されるため、6081 を許可しなければなりません。443 では GWLB からのトラフィックが届かず誤りです。
D：アプライアンスを既存のウェブサーバー VPC に同居させる構成です。検査アプライアンスは専用 VPC に分離するのがベストプラクティス（A）であり、同居はスケーリングや管理の分離を損なうため最適ではありません。
E：F とほぼ同内容ですが、IGW へのエッジアソシエーション用の新しいルートテーブルを作成するステップが欠けています。インターネットからの戻り/入りトラフィックを検査経路へ向けるにはエッジアソシエーションが必須であり、それを含む F の方が正しい完全な手順です。

【参考】
AWS Gateway Load Balancer とは
Gateway Load Balancer エンドポイントとルーティング (Geneve / ポート 6081)
この問題のページを開く →
問題 7この要件を満たすソリューションはどれですか?ネットワークの実装
問題
ある企業のデータセンターは、AWS Direct Connect 専用接続によって単一の AWS リージョンに接続されています。同社はそのリージョンに単一の VPC を持っています。同社はすべてのアプリケーションのログをデータセンター内にローカルで保存しています。 同社はすべてのアプリケーションログを 7 年間保持する必要があります。同社は、すべてのアプリケーションログを Amazon S3 バケットにコピーすることを決定しました。 この要件を満たすソリューションはどれですか?

選択肢と解説

  • 1
    Direct Connect 接続でパブリック VIF を作成する。VPC に Amazon S3 ゲートウェイエンドポイントを作成する。
  • 2
    Direct Connect 接続でプライベート VIF を作成する。VPC に Amazon S3 ゲートウェイエンドポイントを作成する。
  • ✓
    Direct Connect 接続でプライベート VIF を作成する。VPC に Amazon S3 インターフェイスエンドポイントを作成する。
  • 4
    Direct Connect 接続でパブリック VIF を作成する。VPC に Amazon S3 インターフェイスエンドポイントを作成する。

解説

【正解】C

【0からの解説】
オンプレミスのデータセンターから、Direct Connect 経由でプライベートに Amazon S3 へログをコピーしたい、というシナリオです。ここでのポイントは「VIF の種類」と「S3 エンドポイントの種類」の組み合わせです。

■ S3 エンドポイントの種類
・ゲートウェイエンドポイント (Gateway Endpoint): VPC のルートテーブルにプレフィックスリストを追加して S3 へプライベートアクセスする方式。しかしオンプレミスからはルートテーブルを参照できないため、オンプレミス（Direct Connect/VPN 経由）からはゲートウェイエンドポイントを利用できません。
・インターフェイスエンドポイント (Interface Endpoint / AWS PrivateLink): VPC 内に ENI（プライベート IP）を作成し、その IP 宛てに S3 へアクセスする方式。オンプレミスからも Direct Connect のプライベート VIF 経由でこのプライベート IP に到達でき、オンプレミスからのプライベートアクセスに対応します。
→ オンプレミスから使うには「インターフェイスエンドポイント」が必要です。

■ VIF の種類
・プライベート VIF: VPC のプライベート IP 空間に到達するための VIF。インターフェイスエンドポイントの ENI（VPC 内のプライベート IP）に到達するにはプライベート VIF を使います。
・パブリック VIF: AWS のパブリックサービス（パブリック IP）に Direct Connect 経由で到達するための VIF。
→ インターフェイスエンドポイントの ENI（プライベート IP）へ到達するにはプライベート VIF が必要です。

したがって「プライベート VIF ＋ S3 インターフェイスエンドポイント」の組み合わせ（C）が、オンプレミスから Direct Connect 経由でプライベートに S3 へログをコピーする正しい構成です。

【誤りの選択肢】
A：パブリック VIF とゲートウェイエンドポイントの組み合わせ。ゲートウェイエンドポイントは VPC ルートテーブル前提でオンプレミスから利用できず、誤りです。
B：プライベート VIF とゲートウェイエンドポイントの組み合わせ。ゲートウェイエンドポイントはオンプレミスから到達できないため、プライベート VIF と組み合わせても機能しません。
D：パブリック VIF とインターフェイスエンドポイントの組み合わせ。インターフェイスエンドポイントは VPC 内のプライベート IP (ENI) で公開されるため、到達にはプライベート VIF が必要です。パブリック VIF ではこのプライベート IP に到達できず、誤りです。

【参考】
Amazon S3 のインターフェイスエンドポイント (AWS PrivateLink)
AWS Direct Connect の仮想インターフェイス (プライベート / パブリック VIF)
この問題のページを開く →
問題 8ネットワークの実装ネットワークの実装
問題
あるネットワークエンジニアが、オンプレミスのデータセンターから AWS Control Tower ベースのマルチアカウント環境への大規模な移行作業に取り組んでいます。この環境には、中央のネットワークサービスアカウントにデプロイされた Transit Gateway があります。この中央ネットワークサービスアカウントは、AWS Resource Access Manager (AWS RAM) を通じて、AWS Organizations の組織と共有されています。 この環境には共有サービスアカウント (shared services account) も存在します。共有サービスアカウントは、組織全体と共有する必要のあるワークロードをホストしています。 ネットワークエンジニアは、環境全体にわたって共通のネットワークコンポーネントのデプロイを自動化するソリューションを作成する必要があります。このソリューションは、新規および既存のメンバーアカウントそれぞれに、アプリケーションワークロード用の VPC をプロビジョニングする必要があります。これらの VPC は、中央ネットワークサービスアカウントの Transit Gateway に接続されている必要があります。 最も運用オーバーヘッドの少ない（LEAST operational overhead）形でこれらの要件を満たすステップの組み合わせはどれですか?（3 つ選択）

選択肢と解説

  • 1
    AWS Lambda 関数を共有サービスアカウントにデプロイする。Lambda 関数が、新規および既存のメンバーアカウントのロールを引き受けて、必要なネットワークインフラをプロビジョニングするようにプログラムする。
  • ✓
    既存のアカウントを Account Factory Customization (AFC) で更新する。新しいアカウントをプロビジョニングする際にも同じ AFC を選択する。
  • ✓
    各アカウントに作成する必要のあるインフラを記述した AWS CloudFormation テンプレートを作成する。そのテンプレートを AWS Service Catalog 製品として共有サービスアカウントにアップロードする。
  • 4
    共有サービスアカウントのデフォルトイベントバスに Amazon EventBridge ルールをデプロイする。EventBridge ルールが AWS Control Tower の CreateManagedAccount ライフサイクルイベントに反応し、AWS Lambda 関数を起動するように構成する。
  • ✓
    共有サービスアカウントに AWSControlTowerBlueprintAccess ロールを作成する。

解説

【正解】B、C、E

【0からの解説】
本問は AWS Control Tower の Account Factory Customization (AFC)（アカウントファクトリーのカスタマイズ＝ブループリント機能）を使い、新規・既存アカウントへ共通の VPC をプロビジョニングし、中央の Transit Gateway に接続する自動化を、最小の運用オーバーヘッドで実現する設計を問うています。

AFC（ブループリント）は、AWS Service Catalog 製品（CloudFormation テンプレート）を「ブループリント」として指定し、Control Tower のアカウントファクトリーが新規アカウント作成時・既存アカウント更新時にそのテンプレートを自動適用してくれるマネージドな仕組みです。Lambda や EventBridge を自前で作り込む必要がなく、運用オーバーヘッドが最小になります。

必要なステップは次の 3 つです。
■ C：各アカウントに作る共通インフラ（VPC、Transit Gateway へのアタッチメント等）を CloudFormation テンプレートで記述し、それを Service Catalog 製品として登録します。これが AFC のブループリント本体になります。
■ B：既存アカウントを AFC で更新（ブループリントを適用）し、新規アカウントのプロビジョニング時にも同じ AFC（ブループリント）を選択します。これにより「新規・既存の両方」へ自動適用される要件を満たします。
■ E：AFC（ブループリント）が対象アカウントにリソースを展開できるよう、ブループリントを管理する側のアカウント（ここではブループリント/Service Catalog 製品を持つ共有サービスアカウント）に AWSControlTowerBlueprintAccess ロールを作成する必要があります。これは AFC を機能させるための必須の前提ロールです。

よって B・C・E が正解です。これらは Control Tower のマネージド機能を活用するため、自前のイベント駆動の作り込み（Lambda/EventBridge）より運用負荷が小さくなります。

【誤りの選択肢】
A：Lambda 関数が各メンバーアカウントのロールを引き受けてインフラをプロビジョニングする方式は、ロール管理・エラー処理・冪等性などを自前で作り込む必要があり、運用オーバーヘッドが大きくなります。AFC を使う B・C・E の方がマネージドで効率的です。
D：EventBridge で CreateManagedAccount ライフサイクルイベントを捕捉して Lambda を起動する方式も、A と同様にカスタムの自動化基盤を自前で構築・運用することになり、運用負荷が高くなります。さらに既存アカウントへの適用（イベントは新規作成時に発火）にも別途対応が必要で、要件「新規および既存」を一貫して満たしにくく、AFC を使う構成に劣ります。

【参考】
AWS Control Tower の Account Factory Customization (ブループリント)
AWSControlTowerBlueprintAccess ロールの作成
この問題のページを開く →
問題 9運用上のオーバーヘッドが最も少なく、企業の要件を満たすアーキテクチャはどれですか?ネットワーク設計
問題
ある企業は、複数の VPC と 2 つのオンプレミスデータセンターでホストされる高可用性アプリケーションを運用しています。すべての VPC は同一の AWS リージョンに存在します。すべての VPC は、複数ギガバイトに及ぶサイズのファイルを転送するために、相互に、そしてオンプレミスデータセンターにアクセスする必要があります。 ネットワークエンジニアは、オンプレミスデータセンターを各 VPC に接続するための AWS Direct Connect ソリューションを設計しています。 運用上のオーバーヘッドが最も少なく、企業の要件を満たすアーキテクチャはどれですか?

選択肢と解説

  • 1
    リージョン内の各 VPC に仮想プライベートゲートウェイとプライベート VIF を構成する。Direct Connect ゲートウェイを構成する。すべての VPC の VIF を Direct Connect ゲートウェイに関連付ける。Direct Connect ゲートウェイを各オンプレミスデータセンターに接続する新しいプライベート VIF を作成する。新しいプライベート VIF を、オンプレミスデータセンターと BGP ルートを交換し、MTU を 9001 にするように構成する。各 VPC 間で VPC ピアリングを使用する。VPC 間ルーティングを提供するため各 VPC で静的ルーティングを構成する。
  • 2
    リージョン内の各 VPC に仮想プライベートゲートウェイとプライベート VIF を構成する。Direct Connect ゲートウェイを構成する。すべての VPC の VIF を Direct Connect ゲートウェイに関連付ける。Direct Connect ゲートウェイを各オンプレミスデータセンターに接続する新しいプライベート VIF を作成する。新しいプライベート VIF を、オンプレミスデータセンターと BGP ルートを交換し、MTU を 8500 にするように構成する。各 VPC 間で VPC ピアリングを使用する。VPC 間ルーティングを提供するため各 VPC で静的ルーティングを構成する。
  • 3
    各 VPC と同一リージョンに Transit Gateway を構成する。各 VPC を Transit Gateway にアタッチする。Direct Connect ゲートウェイを構成する。Direct Connect ゲートウェイを Transit Gateway に関連付ける。各 Direct Connect 接続に新しい transit VIF を関連付ける。新しい transit VIF を、BGP ルートを交換し、MTU を 9001 にするように構成する。各 VPC と Transit Gateway 間でルート伝播を構成する。
  • ✓
    各 VPC と同一リージョンに Transit Gateway を構成する。各 VPC を Transit Gateway にアタッチする。Direct Connect ゲートウェイを構成する。Direct Connect ゲートウェイを Transit Gateway に関連付ける。各 Direct Connect 接続に新しい transit VIF を関連付ける。新しい transit VIF を、BGP ルートを交換し、MTU を 8500 にするように構成する。各 VPC と Transit Gateway 間でルート伝播を構成する。

解説

【正解】D

【0からの解説】
この問題のポイントは 2 つです。(1) 多数の VPC + 複数のオンプレミスデータセンターを「最も運用負荷が少なく」相互接続するトポロジの選択、(2) 複数ギガバイトのファイル転送に向けたジャンボフレーム(高 MTU)の正しい値です。

まずトポロジ。多数の VPC を相互接続する場合、VPC ピアリングは「フルメッシュ」になり、VPC が増えるたびにピアリング接続と各 VPC のルートテーブルの静的ルートを追加・管理する必要があり、運用負荷が急増します。一方 AWS Transit Gateway は「ハブ&スポーク」で、各 VPC を 1 回アタッチしてルート伝播(propagation)を有効にするだけで相互接続でき、オンプレミス側も Direct Connect ゲートウェイを Transit Gateway に関連付け、transit VIF 1 つで集約できます。よって運用負荷が最小なのは Transit Gateway + Direct Connect ゲートウェイ + transit VIF の構成(C か D)です。

次に MTU。Direct Connect 上のプライベート VIF は最大 9001 バイトのジャンボフレームに対応しますが、Transit Gateway 経由(transit VIF)でジャンボフレームを使う場合の最大 MTU は 8500 バイトです。したがって transit VIF の MTU は 9001 ではなく 8500 を指定する D が正解です。

【誤りの選択肢】
A：仮想プライベートゲートウェイ + プライベート VIF + VPC ピアリング + 静的ルーティングという構成で、VPC が増えるたびにピアリングとルートを手作業で増やす必要があり運用負荷が大きい。
B：A と同様にピアリング+静的ルーティングで運用負荷が大きい(MTU 値自体は妥当だがトポロジが非効率)。
C：トポロジ(Transit Gateway + transit VIF)は正しいが、transit VIF の最大 MTU は 8500 であり 9001 は構成できないため誤り。

【参考】
AWS Direct Connect のジャンボフレームに関するページ(MTU 8500 / 9001)
Transit Gateway と Direct Connect ゲートウェイの関連付け
この問題のページを開く →
問題 10この要件を満たすソリューションはどれですか?ネットワークのセキュリティ、コンプライアンス、ガバナンス
問題
ある企業は、Amazon S3 を使用して財務データをアーカイブする計画を立てています。データは現在オンプレミスデータセンターに保存されています。企業はオンプレミスデータセンターへの接続に、Direct Connect ゲートウェイと Transit Gateway を備えた AWS Direct Connect を使用しています。データはパブリックインターネット経由で転送してはならず、転送中に暗号化されなければなりません。 この要件を満たすソリューションはどれですか?

選択肢と解説

  • 1
    Direct Connect パブリック VIF を作成する。パブリック VIF 上に IPsec VPN 接続をセットアップして Amazon S3 にアクセスする。通信には HTTPS を使用する。
  • ✓
    transit VIF 上に IPsec VPN 接続を作成する。VPC を作成し、その VPC を Transit Gateway にアタッチする。その VPC 内に Amazon S3 用のインターフェイス VPC エンドポイントをプロビジョニングする。通信には HTTPS を使用する。
  • 3
    VPC を作成し、その VPC を Transit Gateway にアタッチする。その VPC 内に Amazon S3 用のインターフェイス VPC エンドポイントをプロビジョニングする。通信には HTTPS を使用する。
  • 4
    Direct Connect パブリック VIF を作成する。パブリック VIF 上に Transit Gateway への IPsec VPN 接続をセットアップする。Amazon S3 用のアタッチメントを作成する。通信には HTTPS を使用する。

解説

【正解】B

【0からの解説】
要件は (1) データがパブリックインターネットを通らないこと、(2) 転送中に暗号化されること、の 2 点です。

(2) の「転送中の暗号化」が重要です。Direct Connect 自体は専用線ですが、リンク層での暗号化(MACsec)を構成しない限り回線そのものは暗号化されません。HTTPS(TLS)はアプリケーション層の暗号化を提供しますが、本問のように「すべてのパケットの暗号化」を確実にするには IPsec VPN を併用するのが定番です。Site-to-Site VPN を Direct Connect 上で実行することで、Direct Connect の安定性を保ちつつ IPsec による暗号化を実現できます。

(1) の「パブリックインターネットを通らない」ため、S3 へはパブリックエンドポイントではなくプライベート経路でアクセスする必要があります。VPC を作成して Transit Gateway にアタッチし、その VPC 内に Amazon S3 用のインターフェイス VPC エンドポイント(PrivateLink)を作成すれば、S3 へのトラフィックは VPC 内のプライベート IP を経由し、インターネットを通りません。

これらを満たすのは B です。transit VIF 上に IPsec VPN を確立して暗号化し、Transit Gateway 経由で VPC に到達し、その VPC のインターフェイスエンドポイントから S3 にプライベートアクセスします。

【誤りの選択肢】
A：パブリック VIF 経由で S3 のパブリックエンドポイントにアクセスするため、要件「パブリックインターネットを通らない(プライベート経路)」に反する(パブリック VIF は AWS パブリックサービスのパブリック IP への到達に使われる)。
C：インターフェイスエンドポイントでプライベート到達は満たすが、transit VIF 上の Direct Connect は暗号化されておらず、IPsec VPN による「転送中の暗号化」が無いため要件を満たさない。
D：パブリック VIF 上の VPN で Transit Gateway に接続する構成自体が成立せず(Transit Gateway への VPN はプライベート/transit 経路で構成する)、また「S3 用のアタッチメント」という Transit Gateway のアタッチメント種別は存在しないため誤り。

【参考】
AWS Site-to-Site VPN を Direct Connect 上で実行する(プライベート IP VPN)
Amazon S3 へのインターフェイス VPC エンドポイント(AWS PrivateLink)
この問題のページを開く →
問題 11追加のインフラストラクチャのセットアップなしで API を呼び出すために、ネットワークエンジニアが使用できるソリューショ…ネットワークの実装
問題
ある企業は、プロセスワークフロー要件のために AWS 上で API ベースのアプリケーションを開発しています。この API は、企業のオンプレミスデータセンター内のクライアントから呼び出されます。企業はオンプレミスと AWS の間に AWS Direct Connect 接続をセットアップしています。ネットワークエンジニアは、この API を Amazon API Gateway のプライベート REST API として実装することを決定しました。ネットワークエンジニアは、クライアントがプライベート通信を通じて API エンドポイントに到達できるようにしたいと考えています。 追加のインフラストラクチャのセットアップなしで API を呼び出すために、ネットワークエンジニアが使用できるソリューションはどれですか?

選択肢と解説

  • 1
    プライベート DNS 名を有効にした API Gateway 用のインターフェイス VPC エンドポイントを作成する。エンドポイントのプライベート DNS 名を使用して API にアクセスする。
  • 2
    プライベート DNS 名を有効にした API Gateway 用のインターフェイス VPC エンドポイントを作成する。エンドポイントの Amazon Route 53 エイリアスを使用して API にアクセスする。
  • 3
    API Gateway 用のインターフェイス VPC エンドポイントを作成する。そのエンドポイントをプライベート REST API に関連付ける。エンドポイントの Amazon Route 53 エイリアスを使用して API にアクセスする。
  • ✓
    プライベート DNS 名を有効にした API Gateway 用のインターフェイス VPC エンドポイントを作成する。エンドポイントのパブリック DNS 名を使用して API にアクセスする。

解説

【正解】D

【0からの解説】
Amazon API Gateway の「プライベート REST API」は、VPC 内のインターフェイス VPC エンドポイント(execute-api)経由でのみアクセスできる API です。Direct Connect で接続されたオンプレミスのクライアントは、VPC のインターフェイスエンドポイントを通じてプライベートにこの API を呼び出せます。

ここで重要なのは「追加のインフラストラクチャのセットアップなしで」という条件です。インターフェイスエンドポイントで プライベート DNS を有効化 すると、API の通常の(パブリックな)実行エンドポイント名、すなわち {restapi-id}.execute-api.{region}.amazonaws.com という DNS 名が、VPC 内/オンプレミス側からはエンドポイントのプライベート IP に名前解決されるようになります。つまりクライアントは特別な URL を組み立てる必要がなく、API の「パブリック DNS 名(標準の実行エンドポイント名)」をそのまま使ってプライベートに到達できます。これが「追加セットアップ不要」を満たす D です。

※補足: 選択肢 D の「パブリック DNS 名」とは、プライベート DNS を有効化したときに名前解決先がプライベート IP に切り替わる、API の標準の execute-api ホスト名を指します。Route 53 のカスタムエイリアスやエンドポイント固有 DNS 名を別途設定する必要がないため、最も手間がかかりません。

【誤りの選択肢】
A：プライベート DNS を有効化した場合、利用するのは API の標準(パブリック)実行エンドポイント名であり、「エンドポイント自身のプライベート DNS 名(VPC エンドポイント固有のホスト名)」を直接使うと、URL の組み立てや Host ヘッダー指定などの追加作業が必要になり「追加セットアップ不要」に反する。
B：Route 53 エイリアスを別途作成する追加作業が必要であり、条件「追加のインフラ不要」に反する。
C：プライベート DNS の有効化に言及しておらず、さらに「エンドポイントをプライベート REST API に関連付ける」設定と Route 53 エイリアス作成という追加作業が必要なため不適切。

【参考】
API Gateway プライベート REST API の呼び出し
API Gateway 用インターフェイス VPC エンドポイントの作成(プライベート DNS)
この問題のページを開く →
問題 12ネットワークの実装ネットワークの実装
問題
ある企業の AWS 環境には、Transit Gateway で接続された複数の VPC が含まれています。企業は、オンプレミスネットワークと AWS 環境の間の接続を確立するために AWS Site-to-Site VPN を使用することを決定しました。 企業のオンプレミスネットワークには静的なパブリック IP アドレスがありません。ネットワークエンジニアは、AWS 環境からオンプレミスネットワークへのトラフィックについて、AWS 側から VPN 接続を開始するソリューションを実装する必要があります。 Transit Gateway とオンプレミスネットワークの間で VPN 接続を確立するために、ネットワークエンジニアが取るべき手順の組み合わせはどれですか?(3 つ選択)

選択肢と解説

  • 1
    Site-to-Site VPN のトンネルオプションを、Internet Key Exchange バージョン 1(IKEv1)を使用するように構成する。
  • ✓
    Site-to-Site VPN のトンネルオプションを、Internet Key Exchange バージョン 2(IKEv2)を使用するように構成する。
  • ✓
    AWS Private Certificate Authority のプライベート認証機関(CA)を使用して証明書を作成する。
  • 4
    AWS Private Certificate Authority のパブリック認証機関(CA)を使用して証明書を作成する。
  • 5
    カスタマーゲートウェイを作成する。カスタマーゲートウェイデバイスの外部インターフェイスの現在の動的 IP アドレスを指定する。
  • ✓
    カスタマーゲートウェイを作成する。カスタマーゲートウェイデバイスの IP アドレスを指定しない。

解説

【正解】B、C、F

【0からの解説】
通常の Site-to-Site VPN では、カスタマーゲートウェイ(オンプレミス側ルーター)に 静的なパブリック IP を指定し、AWS 側はその IP に向けてトンネルを確立します。しかし本問ではオンプレミスに静的パブリック IP がありません。この場合、AWS は「証明書ベースの認証」と「IP アドレスを指定しないカスタマーゲートウェイ」を使う構成をサポートしており、これにより AWS 側からトンネルを開始(initiate)できます。

必要な 3 要素は次の通りです。
・B(IKEv2): 静的 IP を持たないカスタマーゲートウェイ(証明書ベース認証)は IKEv2 を必須とします。IKEv1 では対応できません。
・C(プライベート CA の証明書): 事前共有キー(PSK)の代わりに、AWS Private Certificate Authority のプライベート CA で発行した証明書を相互認証に使用します。AWS Certificate Manager 経由でカスタマーゲートウェイにこの証明書を関連付けます。
・F(IP を指定しないカスタマーゲートウェイ): オンプレミスの IP が動的/不定なので、カスタマーゲートウェイ作成時に IP アドレスを指定しません。これにより AWS は相手 IP に縛られず、証明書 ARN によって相手を識別してトンネルを確立できます。

【誤りの選択肢】
A：IKEv1 は、静的 IP を持たない(証明書ベース)カスタマーゲートウェイ構成をサポートしないため誤り。IKEv2 が必須。
D：AWS Private Certificate Authority で作成するのはプライベート CA であり、「パブリック CA」という指定は誤り(本ユースケースではプライベート CA 証明書を使う)。
E：「現在の動的 IP アドレスを指定する」と固定 IP を前提とした構成になり、IP が変わると接続が破綻する。動的 IP のケースでは IP を指定しない構成にすべきで誤り。

【参考】
証明書ベース認証の Site-to-Site VPN(IP を指定しないカスタマーゲートウェイ)
Site-to-Site VPN のトンネル認証オプション(プライベート証明書)
この問題のページを開く →
問題 13ネットワーク設計ネットワーク設計
問題
us-east-1 リージョンに所在する金融企業が、AWS へのセキュアな接続を確立する必要があります。企業には 2 つのオンプレミスデータセンターがあり、いずれも同一リージョン内に所在します。企業のネットワークチームは、信頼性が高く一貫した接続性を備えたハイブリッド接続を AWS 環境に確立する必要があります。 この接続は、AWS 環境内のプライベートリソースへのアクセスを提供しなければなりません。これらのリソースは us-east-1 リージョンと us-west-2 リージョンに配置されています。また、この接続は、企業ネットワークから同じ接続を通じて Amazon S3 に大量のデータを送信できるようにしなければなりません。コンプライアンス要件を満たすため、接続は高可用性を備え、オンプレミス拠点と AWS 上のあらゆるサービスの間で送信されるすべてのパケットを暗号化しなければなりません。 これらの要件を満たすために、ネットワークチームが取るべき手順の組み合わせはどれですか?(2 つ選択)

選択肢と解説

  • 1
    Amazon S3 にデータを送信するためのプライベート VIF をセットアップする。プライベート VIF 上で AWS Site-to-Site VPN 接続を使用し、us-east-1 と us-west-2 の VPC への転送中データを暗号化する。
  • ✓
    企業の各データセンターへの AWS Direct Connect 接続をセットアップする。
  • 3
    企業のデータセンターの 1 つから us-east-1 と us-west-2 への AWS Direct Connect 接続をセットアップする。
  • ✓
    Amazon S3 にデータを送信するためのパブリック VIF をセットアップする。パブリック VIF 上で AWS Site-to-Site VPN 接続を使用し、us-east-1 と us-west-2 の VPC への転送中データを暗号化する。
  • 5
    AWS Direct Connect ゲートウェイ用の transit VIF をセットアップして Amazon S3 にデータを送信する。Transit Gateway を作成する。Transit Gateway を Direct Connect ゲートウェイに関連付けて、企業のデータセンターから us-east-1 と us-west-2 の VPC へのセキュアな通信を提供する。

解説

【正解】B、D

【0からの解説】
要件を整理すると、(1) 信頼性が高く一貫した接続(=Direct Connect)、(2) 高可用性、(3) S3 への大量データ送信を同じ接続で行う、(4) すべてのパケットの暗号化、です。

高可用性(2)を満たすには、単一障害点を避けるため 各データセンターからそれぞれ Direct Connect 接続 を用意します(B)。1 つのデータセンターからだけでは、そのサイトや回線が落ちると全体が切れます。

S3 への送信(3)と暗号化(4)を同時に満たすには、パブリック VIF を使います。S3 は AWS のパブリックサービスであり、プライベート VIF や transit VIF からは S3 のパブリックエンドポイントに到達できません(パブリックサービスへの到達はパブリック VIF が必要)。そしてパブリック VIF 上で AWS Site-to-Site VPN(IPsec)を確立すれば、Direct Connect の安定性を保ちつつ、S3 や複数リージョン(us-east-1 / us-west-2)の VPC への通信を含む全パケットを暗号化できます。これが D です。

したがって正解は B と D です。

【誤りの選択肢】
A：プライベート VIF は S3 のパブリックエンドポイントへ到達できないため、「同じ接続で S3 に大量データを送る」要件を満たせない。
C：1 つのデータセンターからのみの Direct Connect では高可用性(単一障害点の排除)を満たせない。
E：transit VIF / Transit Gateway は VPC へのプライベート接続用であり、S3 のパブリックエンドポイントへの到達手段にならない。また transit VIF 単体では IPsec 暗号化を提供しないため「すべてのパケットの暗号化」要件も満たせない。

【参考】
AWS Direct Connect の回復性(高可用性)のベストプラクティス
Direct Connect 上の Site-to-Site VPN(パブリック VIF 上の IPsec で暗号化)
この問題のページを開く →
問題 14この要件を満たすソリューションはどれですか?ネットワークの実装
問題
ある企業には、異なるサプライヤーによる複数の冗長リンクで相互接続された 2 つのデータセンターがあります。企業は 172.16.0.0/16 CIDR ブロック内の IP アドレスを使用しています。企業は 2 つのデータセンター間で、プライベート ASN(自律システム番号)と IGP を使用して iBGP を実行しています。 企業はハイブリッド構成へ移行しつつあり、最初は AWS クラウド内で 1 つの VPC を使用します。AWS Direct Connect 接続が、プライベート VIF を使用して第 1 データセンターから Direct Connect ゲートウェイに引かれています。この接続上で、企業は 172.16.0.0/16 ネットワークの集約ルートをアドバタイズしています。企業は、別の Direct Connect ロケーションで第 2 データセンターからの 2 つ目の集約ルートを設定する計画です。 企業は、AWS との間のトラフィックを第 1 の Direct Connect 接続経由でルーティングするソリューションを実装する必要があります。このソリューションは、第 2 の Direct Connect 接続をフェイルオーバー目的でのみ使用しなければなりません。 この要件を満たすソリューションはどれですか?

選択肢と解説

  • 1
    第 2 データセンターから AWS への BGP アナウンスにプライベート ASN をプリペンドする。第 1 の Direct Connect 接続に 2 つ目の VIF を追加する。第 1 データセンターからはプリペンドなしで同じネットワークをアドバタイズする。AWS から 2 つのデータセンターへの BGP アナウンスにも同じセットアップを実装する。
  • ✓
    BGP アナウンスを local preference の BGP コミュニティタグでタグ付けする。第 1 データセンターには高 preference のタグを設定する。第 2 データセンターには低 preference のタグを設定する。第 2 データセンターのルーターを、第 1 データセンターからのアドバタイズよりも AWS からの直接 BGP アドバタイズの local preference を低くするように構成する。
  • 3
    Direct Connect ゲートウェイを、第 1 データセンターとの Direct Connect 接続経由でルーティングするよう優先設定する。第 2 データセンターのルーターを、第 1 データセンターからのアドバタイズよりも AWS からの直接 BGP アドバタイズの local preference を低くするように構成する。
  • 4
    第 1 データセンターからアドバタイズされる BGP ルートに、ローカル AWS リージョンの BGP コミュニティタグを構成する。第 2 データセンターからの BGP アナウンスに AS_PATH プリペンドを構成する。

解説

【正解】B

【0からの解説】
この問題は「アクティブ/パッシブ(プライマリ/フェイルオーバー)」の経路制御を、双方向(AWS→オンプレ と オンプレ→AWS)で正しく実現する方法を問うています。

双方向を制御する必要がある点に注意します。
・AWS への入り(オンプレ→AWS)方向: AWS が複数の Direct Connect から同じプレフィックス 172.16.0.0/16 を受け取ったとき、どちらを優先するかを制御する手段が必要です。AWS は受信ルートの優先順位として、まず最長プレフィックス一致、次に local preference の BGP コミュニティタグ(7224:7100=低、7224:7200=中、7224:7300=高)、最後に最短 AS_PATH の順で判断します。第 1 データセンターからのアナウンスに高 preference タグ、第 2 データセンターに低 preference タグを付ければ、AWS は通常は第 1 経由を選び、第 1 がダウンしたときだけ第 2 にフェイルオーバーします。
・AWS からの出(AWS→オンプレ)方向: 第 2 データセンターのルーター側で、AWS からの直接アドバタイズより第 1 データセンター経由(iBGP)のルートを優先するよう local preference を調整すれば、戻りトラフィックも通常は第 1 経由になります。

選択肢 B はこの両方向の制御をカバーしているため正解です。

※補足: AWS への inbound 経路制御として AWS が公式に推奨するのは local preference コミュニティタグ(7224:7100/7200/7300)であり、AS_PATH プリペンドより確実に効きます(AWS の経路選択では local preference の方が AS_PATH より先に評価されるため)。

【誤りの選択肢】
A：プライベート ASN のプリペンドは AS_PATH を長くする手法だが、AWS の経路選択では local preference コミュニティの方が先に評価されるため、コミュニティタグほど確実ではない。さらに「2 つ目の VIF を追加」など余計で、双方向の制御も不十分。
C：「Direct Connect ゲートウェイ側で接続を優先設定する」という機能は存在せず(DXGW に経路優先のスイッチはない)、経路制御は BGP 属性で行う必要があるため誤り。
D：「ローカル AWS リージョンのコミュニティタグ」はリージョン到達範囲(スコープ)を制御するもので優先度制御ではない。優先度の主制御を AS_PATH プリペンドだけに頼るのは local preference より弱く、要件のアクティブ/パッシブを確実に実現できないため不適切。

【参考】
Direct Connect ルーティングポリシーと BGP コミュニティ(local preference)
Direct Connect でのアクティブ/パッシブ冗長構成の設計
この問題のページを開く →
問題 15ネットワークのセキュリティ、コンプライアンス、ガバナンスネットワークのセキュリティ、コンプライアンス、ガバナンス
問題
ある企業は、us-east-1 リージョンに 1 つのエッジロケーション、us-west-1 リージョンに 1 つのエッジロケーションを持つ AWS Cloud WAN を使用しています。両方のエッジロケーションに共有サービスセグメント(shared services segment)が存在します。各共有サービスセグメントは、各リージョンの各インスペクション VPC への VPC アタッチメントを持っています。インスペクション VPC は AWS Network Firewall を使用して WAN からのトラフィックを検査します。 企業は、us-east-1 エッジロケーションに新しいビジネスユニット(BU)用の新しいセグメントを作成します。新しい BU には、新しい BU セグメントにアタッチされた 3 つの VPC があります。規制に準拠するため、BU の VPC は相互に通信してはなりません。すべてのインターネット宛トラフィックはインスペクション VPC で検査されなければなりません。 企業は、インターネット宛のすべてのトラフィックが AWS Cloud WAN コアネットワークへ向かうように VPC ルートテーブルを更新します。 企業は将来、新しい BU 用にさらに多くの VPC を追加する予定です。将来のすべての VPC も規制に準拠しなければなりません。 この要件を最も運用効率の高い方法で満たすソリューションはどれですか?(2 つ選択)

選択肢と解説

  • ✓
    共有サービスセグメントを BU セグメントと共有するようにネットワークポリシーを更新する。
  • 2
    インスペクションサービスセグメントを BU セグメントと共有するネットワークポリシーを作成する。
  • ✓
    BU セグメントの isolate-attachments フィールドを True に設定する。
  • 4
    BU セグメントの isolate-attachments フィールドを False に設定する。
  • 5
    BU セグメントの静的ルートを追加するようにネットワークポリシーを更新する。共有サービスセグメントを、VPC CIDR ブロックに関連するトラフィックをそれぞれの VPC アタッチメントにルーティングするように構成する。

解説

【正解】A、C

【0からの解説】
AWS Cloud WAN では「セグメント」がルーティングドメイン(VRF のようなもの)で、同一セグメント内のアタッチメント同士はデフォルトで相互通信できます。

要件は 2 つです。(1) 同じ BU セグメント内の 3 つの VPC が相互に通信してはならない、(2) インターネット宛トラフィックはインスペクション VPC(共有サービスセグメント側)で検査されなければならない。さらに将来 VPC を追加しても自動的に準拠させたい(運用効率)。

・C(isolate-attachments = True): セグメントの isolate-attachments を True にすると、そのセグメント内のアタッチメント同士は直接通信できなくなります。BU セグメントに対してこれを設定すれば、現在の 3 VPC も、将来追加される VPC も、自動的に相互通信が遮断され、規制に準拠します。手動で個別ルートを管理する必要がないため運用効率も最良です。
・A(共有サービスセグメントを BU セグメントと共有する): isolate-attachments=True にしても、BU の VPC は依然として共有サービス(インスペクション VPC 経由のインターネット出口)に到達する必要があります。Cloud WAN の「セグメント共有(sharing / segment actions)」を使い、共有サービスセグメントと BU セグメント間の通信を許可すれば、各 BU VPC はインスペクション VPC を経由してインターネットに出られます(セグメント内分離は維持したまま、共有サービスへの経路だけ開く)。

よって A と C の組み合わせが正解です。

【誤りの選択肢】
B：検査(インスペクション)機能は共有サービスセグメント側のインスペクション VPC が担っており、トラフィックは共有サービスセグメントを経由させる。「インスペクションサービスセグメント」を別途共有するのではなく、共有サービスセグメントの共有(A)が適切で、B は構成が噛み合わない。
D：isolate-attachments=False は同一セグメント内の相互通信を許可してしまい、「BU の VPC は相互通信不可」という規制要件に真っ向から反する。
E：VPC CIDR ごとに静的ルートを手動追加する運用は、VPC が増えるたびに手作業が発生し「最も運用効率が高い」要件に反する。isolate-attachments による分離の方が自動的で効率的。

【参考】
AWS Cloud WAN のセグメントとセグメントアクション(共有・分離)
AWS Cloud WAN のポリシーと isolate-attachments の概念
この問題のページを開く →

ANS-C01 対策のハンズオンラボ

実際の Azure・AWS 環境を払い出して手を動かせます。問題演習と組み合わせると理解が定着します。

VPC のネットワーク到達性トラブルシューティング（ルートテーブル・セキュリティグループ・ネットワーク ACL）
intermediate・約 50 分
3層ネットワークの VPC を一から構築する
intermediate・約 50 分
AWS Network Firewall を VPC に構成して送信トラフィックを検査する
intermediate・約 55 分
S3 ゲートウェイ VPC エンドポイントでプライベートに S3 へアクセスする
intermediate・約 40 分
VPC ピアリングで 2 つの VPC をプライベート接続する
intermediate・約 45 分
カスタム VPC と DHCP オプションセットの作成
intermediate・約 40 分
Network Load Balancer を作成して TCP 負荷分散を構成する
intermediate・約 45 分

ANS-C01 模擬問題集についてよくある質問

ANS-C01 の練習問題は無料で試せますか？

はい。ANS-C01 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

ANS-C01 は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。

ANS-C01 のハンズオン学習もできますか？

はい。ANS-C01 に対応するハンズオンラボを 7 件ご用意しています。実際の Azure・AWS 環境を払い出して手を動かしながら学習できます。