AWS ANS無料問題集です。正解と解説を確認する際は右側のボタンを押下してください。
問題集の完全版は以下Udemyにて発売しているためお買い求めください。問題集への質問はUdemyのQA機能もしくはUdemyのメッセージにて承ります。Udemyの問題1から10問抜粋しております。
多くの方にご好評いただき、講師評価 4.5/5.0 を獲得できております。ありがとうございます。
特別価格： 通常2,600円 → 1,500円
講師クーポン適用で42%OFF
講師クーポン【構成図解付き】出題範囲網羅+AWS ANS-C01日本語実践問題220問 (Advanced Networking)
この資格を活かしたキャリア情報
ANS資格の取得後にどんなキャリアが開けるか、詳しくはこちら：
→ ANS合格者の転職市場価値と求人傾向
AWS資格全体のキャリア活用法：
→ AWS資格は転職・キャリアアップでどう活きる？資格別市場価値と実体験
問題文：
あるオンライン証券会社は、顧客向けの株式売買プラットフォームを新しいAWSアカウントへ移行しています。プラットフォームは単一のAWSリージョン内にある1つのVPCと複数のアベイラビリティゾーンに展開されます。アプリケーションはプライベートサブネットのAmazon EC2インスタンスで稼働し、各アベイラビリティゾーンに複数のインスタンスがあります。1日あたり数万人の投資家がWebブラウザからHTTPSで接続して売買注文を出します。取引の途中経過をセッションに保持しているため、同じクライアントセッションから届くすべての接続は同じEC2インスタンスに固定する必要があります。また、金融業界のコンプライアンス要件を満たすため、クライアントとアプリケーションの間の通信は、アプリケーションが保有するSSL証明書でエンドツーエンドに暗号化しなければなりません。これらの要件を満たすソリューションはどれですか。
選択肢：
A. Network Load Balancerを作成します。ターゲットグループを作成し、プロトコルをTCP、ポートを443に設定します。セッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。リスナーを作成し、プロトコルをTCP、ポートを443に設定します。SSL証明書をEC2インスタンス側に配置して終端します。
B. Application Load Balancerを作成します。ターゲットグループを作成し、プロトコルをHTTP、ポートを80に設定します。アプリケーションCookie方式のセッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。HTTPSリスナーを作成し、AWS Certificate Manager（ACM）で取得した証明書をリスナーに割り当てて、デフォルトアクションをターゲットグループへの転送に設定します。
C. Network Load Balancerを作成します。ターゲットグループを作成し、プロトコルをTLS、ポートを443に設定します。セッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。リスナーを作成し、プロトコルをTLS、ポートを443に設定します。ACMで取得した証明書をリスナーに割り当てます。
D. Application Load Balancerを作成します。ターゲットグループを作成し、プロトコルをHTTPS、ポートを443に設定します。アプリケーションCookie方式のセッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。HTTPリスナーを作成し、リスナーのポートを443に設定して、デフォルトアクションをターゲットグループへの転送に設定します。
正解：A
A. Network Load Balancerを作成します。ターゲットグループを作成し、プロトコルをTCP、ポートを443に設定します。セッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。リスナーを作成し、プロトコルをTCP、ポートを443に設定します。SSL証明書をEC2インスタンス側に配置して終端します。
正解 Network Load BalancerをTCPリスナーとして構成すると、暗号化されたトラフィックを復号せずにEC2インスタンスへ転送できます。これにより、クライアントからEC2インスタンスまでのエンドツーエンド暗号化が保たれます。SSL証明書はEC2インスタンス側に置くため、アプリケーション層での暗号化が可能です。また、NLBはセッションアフィニティをサポートしており、同じクライアントからの接続を同じインスタンスに固定します。
B. Application Load Balancerを作成します。ターゲットグループを作成し、プロトコルをHTTP、ポートを80に設定します。アプリケーションCookie方式のセッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。HTTPSリスナーを作成し、AWS Certificate Manager（ACM）で取得した証明書をリスナーに割り当てて、デフォルトアクションをターゲットグループへの転送に設定します。
不正解 Application Load BalancerのHTTPSリスナーは、ロードバランサーの位置でTLSを終端します。ターゲットグループがHTTPのため、ALBからEC2インスタンスへは平文のHTTPで転送され、ALB以降の区間が暗号化されません。したがって、エンドツーエンド暗号化の要件を満たせません。
C. Network Load Balancerを作成します。ターゲットグループを作成し、プロトコルをTLS、ポートを443に設定します。セッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。リスナーを作成し、プロトコルをTLS、ポートを443に設定します。ACMで取得した証明書をリスナーに割り当てます。
不正解 Network Load BalancerのTLSリスナーは、ロードバランサーの位置でTLSを終端して復号するため、クライアントからアプリケーションまでのエンドツーエンド暗号化にはなりません。また、TLSリスナーではスティッキーセッションがサポートされていません。NLBでスティッキーセッションを使うにはTCPリスナーが必要です。
D. Application Load Balancerを作成します。ターゲットグループを作成し、プロトコルをHTTPS、ポートを443に設定します。アプリケーションCookie方式のセッションアフィニティ（スティッキーセッション）を有効化します。EC2インスタンスをターゲットとして登録します。HTTPリスナーを作成し、リスナーのポートを443に設定して、デフォルトアクションをターゲットグループへの転送に設定します。
不正解 HTTPリスナーは平文のHTTPトラフィックを受け付けるリスナーであり、ポート443で構成してもTLSハンドシェイクは行われません。クライアントがHTTPSで接続するという前提が満たされないうえ、クライアントからロードバランサーまでの区間が暗号化されないため、エンドツーエンド暗号化の要件からも外れます。ターゲットグループをHTTPSにしても、入口が平文である以上は要件を満たせません。
全体的な説明
問われている要件
- 数万人規模のHTTPS接続を、複数のアベイラビリティゾーンにあるEC2インスタンスへ分散すること
- 同じクライアントセッションからの接続を常に同じEC2インスタンスへ固定すること（セッションアフィニティ）
- クライアントからアプリケーションまでの通信を、途中で復号せずエンドツーエンドで暗号化したまま保つこと
- 復号にはアプリケーションが保有するSSL証明書を使用し、コンプライアンス要件を満たすこと
前提知識
Elastic Load Balancingの種類について
- Application Load Balancer（ALB）はレイヤー7で動作し、パス・ホストヘッダー・クエリ文字列などHTTPの内容に基づくルーティングを行います
- Network Load Balancer（NLB）はレイヤー4で動作し、TCP・UDP・TLSを超低レイテンシーで処理し、アベイラビリティゾーンごとに固定IPアドレスを持ちます
- Gateway Load Balancer（GWLB）はGENEVE（ポート6081）でサードパーティ製の仮想アプライアンスへトラフィックを受け渡す用途で、この要件には関係しません
TLSの終端位置について
- ALBのHTTPSリスナーとNLBのTLSリスナーは、ロードバランサーの位置でTLSハンドシェイクを終端して復号します
- 終端した後の区間はターゲットグループのプロトコル次第で、HTTPやTCPを指定すれば平文、HTTPSやTLSを指定すればロードバランサーが再暗号化して転送します
- NLBのTCPリスナーは暗号化されたパケットを解釈せずそのまま転送するため、クライアントとEC2インスタンスの間で1つのTLSセッションが維持されます
- エンドツーエンド暗号化を求められる場合は、復号する主体をアプリケーション側に置き、SSL証明書もそのインスタンスに配置します
セッションアフィニティについて
- ALBはロードバランサー生成CookieまたはアプリケーションCookieをHTTPヘッダーに載せ、同じクライアントを同じターゲットへ振り分けます
- NLBはターゲットグループ属性の stickiness.enabled を有効にして使用し、stickiness.type に指定できる値は source_ip です
- NLBのスティッキーセッションはTLSリスナーとQUICリスナーではサポートされないため、TCPリスナーと組み合わせます
- 送信元IPを基準にするため、同一のNATデバイスの背後にいるクライアントは同じターゲットへ集中しやすい点に注意します
アーキテクチャ図の解説
アーキテクチャ図
NLBのTCPリスナーは暗号化トラフィックを復号せずに通過させ、クライアントからEC2インスタンスまでのエンドツーエンド暗号化を維持します。クライアントのHTTPS接続はTCPリスナー（ポート443）に届き、NLBは内容に手を加えず各アベイラビリティゾーンのEC2インスタンスへ転送します。SSL証明書はEC2インスタンス側に置かれ、復号はアプリケーションまで到達してから行われます。セッションアフィニティにより、同じクライアントの接続は常に同じインスタンスへ固定されます。もしTLSリスナーやHTTPSリスナーを選ぶと、ロードバランサーでTLSが終端され、LBからEC2インスタンスまでの区間が平文になってエンドツーエンド暗号化が崩れます。TLSの終端位置で正解が分かれます。
解くための考え方
この問題は、エンドツーエンド暗号化・セッションアフィニティ・証明書の配置という3つの条件を同時に満たす組み合わせを探す設問です。まず着目すべきは暗号化の要件です。「クライアントとアプリケーションの間をエンドツーエンドで暗号化する」という表現は、途中のロードバランサーで復号してはならないという意味なので、ロードバランサーでTLSを終端するALBのHTTPSリスナーとNLBのTLSリスナーはこの時点で外れます。残るのは、暗号化されたパケットをそのまま転送するNLBのTCPリスナー（ポート443）です。次にセッションアフィニティを確認します。ALBはCookieで実現しますがTLSを終端しなければHTTPヘッダーを操作できず、暗号化要件と両立しません。NLBはターゲットグループ属性で送信元IPベースのスティッキーセッションを有効にでき、TCPリスナーであればこの機能が使えます。TLSリスナーではスティッキーセッションがサポートされない点も、TCPリスナーを選ぶ根拠になります。最後に証明書の配置です。復号がEC2インスタンスで行われる以上、SSL証明書はACMでリスナーに割り当てるのではなく、アプリケーションが動くインスタンス側へ配置する必要があり、これは「アプリケーションが保有するSSL証明書」という条件とも一致します。以上の3点がすべて揃うのは、TCPリスナーのNLBとインスタンス側証明書を組み合わせた構成です。
参考資料
問題文：
人事・給与管理のクラウドサービスを提供するソフトウェア企業が、約300社の顧客企業向けに新しいWebアプリケーションをApplication Load Balancer（ALB）の背後にあるAmazon EC2インスタンスにデプロイしました。インスタンスはAuto Scalingグループで管理されており、顧客企業の従業員は毎日の業務時間中、オフィスからHTTPSでこのアプリケーションに接続します。各顧客企業は、自社のファイアウォールで承認済みの宛先IPアドレスへのアウトバウンド通信のみを許可するポリシーを運用しています。ネットワークエンジニアは、顧客の従業員が世界各地から最小限のレイテンシーでアクセスでき、なおかつ各顧客がファイアウォールで許可する宛先IPをできるだけ少なく抑えられる構成を求めています。インフラストラクチャに加えるべき変更はどれですか。
選択肢：
A. 新しいNetwork Load Balancer（NLB）を作成し、既存のALBをNLBのターゲットグループへ登録します。顧客にはNLBが提供するIPアドレスを通知します。
B. 新しいAmazon CloudFrontディストリビューションを作成し、既存のALBをディストリビューションのオリジンとして設定します。顧客には配信ドメイン名を通知します。
C. AWS Global Acceleratorで新しいアクセラレーターを作成し、ALBをエンドポイントに追加します。顧客には固定IPアドレスを通知します。
D. Amazon Route 53で新しいホストゾーンを作成し、トラフィックをALBへルーティングするレコードを追加します。顧客にはそのドメイン名を通知します。
正解：C
A. 新しいNetwork Load Balancer（NLB）を作成し、既存のALBをNLBのターゲットグループへ登録します。顧客にはNLBが提供するIPアドレスを通知します。
不正解 NLBはアベイラビリティゾーンごとに固定IPアドレスを持ち、Elastic IPを割り当てることもできるため、許可リストの宛先を絞る点では一定の効果があります。しかしNLBは単一のリージョン内で動作するロードバランサーであり、世界各地のユーザーを最寄りのエッジロケーションで受け止めてAWSのグローバルネットワークへ載せる仕組みは持ちません。レイテンシーを最小化するという要件を満たせないため不適切です。
B. 新しいAmazon CloudFrontディストリビューションを作成し、既存のALBをディストリビューションのオリジンとして設定します。顧客には配信ドメイン名を通知します。
不正解 CloudFrontはコンテンツ配信ネットワーク（CDN）であり、業務アプリケーションのような動的コンテンツではキャッシュの効果が限定的です。また、通常のディストリビューションは広範なIPアドレス範囲から随時アドレスを使うため、各社のファイアウォールで許可すべき宛先が多くなります。2024年に追加されたエニーキャスト静的IPを使えば許可リストは絞り込めますが、この選択肢はその構成を指定していません。
C. AWS Global Acceleratorで新しいアクセラレーターを作成し、ALBをエンドポイントに追加します。顧客には固定IPアドレスを通知します。
正解 Global Acceleratorは2つの固定エニーキャストIPアドレスを提供するため、各顧客はこの2つだけをファイアウォールで許可すれば済みます。トラフィックは最寄りのAWSエッジロケーションで受け入れられ、AWSのグローバルネットワークを経由してALBへ転送されるため、インターネット経由より低レイテンシーでアクセスできます。2つの要件を同時に満たします。
D. Amazon Route 53で新しいホストゾーンを作成し、トラフィックをALBへルーティングするレコードを追加します。顧客にはそのドメイン名を通知します。
不正解 Route 53はドメイン名をIPアドレスへ解決するDNSサービスであり、レコードを作成するだけではレイテンシーは低減しません。また、ALBのIPアドレスは動的に変化するため、各社のファイアウォールでの許可リスト管理が難しくなり、宛先IPを少なく抑える要件を満たしません。
全体的な説明
問われている要件
- 顧客企業のファイアウォールが許可する宛先IPアドレスを、できるだけ少なくかつ固定にすること
- 約300社の顧客がそれぞれ許可リストを管理するため、AWS側の構成変更でIPが変わらないこと
- 世界各地のオフィスから接続する従業員のレイテンシーを最小限に抑えること
- 既存のALBとAuto Scalingグループの構成を大きく作り替えずに実現すること
前提知識
AWS Global Acceleratorについて
- アクセラレーターを作成すると2つの静的なエニーキャストIPv4アドレスが割り当てられ、世界中のエッジロケーションで同じアドレスが広告されます
- ユーザーのトラフィックは最寄りのエッジロケーションで受け止められ、そこから先はAWSのグローバルネットワークを経由してリージョンのエンドポイントへ届きます
- エンドポイントにはApplication Load Balancer、Network Load Balancer、EC2インスタンス、Elastic IPアドレスを登録でき、重み付けやクライアントアフィニティを設定できます
- エンドポイントのヘルスチェックを継続的に行い、異常を検知すると正常なエンドポイントグループへトラフィックを切り替えます
Amazon CloudFrontについて
- エッジロケーションでコンテンツをキャッシュして配信するCDNで、静的コンテンツの配信で効果を発揮します
- 動的コンテンツはキャッシュしにくいため、レイテンシー改善の効果はワークロードの性質に左右されます
- 通常は広範なIPアドレス範囲を使うため許可リスト運用には向きませんが、エニーキャスト静的IPをリクエストすれば固定アドレスでの配信も可能です
宛先IPの許可リスト運用について
- ALBのIPアドレスは動的に変化するため、DNS名ではなくIPで許可リストを組むと運用が破綻しやすくなります
- NLBはアベイラビリティゾーンごとに固定IPを持ち、Elastic IPも割り当てられますが、これはリージョン単位の入口にとどまります
- Global AcceleratorのエニーキャストIPは世界中で同じ2アドレスなので、拠点が増えても許可リストは増えません
- 独自のIPアドレス範囲をAWSへ持ち込むBYOIPにも対応しており、既存の許可リストを引き継ぐこともできます
アーキテクチャ図の解説
アーキテクチャ図
顧客のトラフィックは最寄りのAWSエッジロケーションで受け取り、AWSのグローバルネットワークを経由してALBへ届けます。北米・欧州・アジアの各顧客オフィスは、ファイアウォールでGlobal Acceleratorの固定エニーキャストIP2つだけを許可し、それぞれ最寄りのエッジロケーションへ接続します。エッジロケーションからアプリケーションまではAWSのプライベートネットワークを通るため、インターネット経由よりも低レイテンシーで経路も安定します。ALBは受け取ったトラフィックをAuto Scalingグループ内のEC2インスタンスへ分散します。許可する宛先IPを2つに抑えられるのは、世界中に入口がありながら接続先のIPが固定されるためです。仮にALBのIPを直接許可させると、IPが動的に変化して各社のファイアウォール運用が複雑になります。
解くための考え方
この設問は、許可リストに載せる宛先IPの数と、グローバルな低レイテンシーという2つの条件を同時に満たす構成を選ばせる問題です。まず許可リストの観点で候補を絞ります。ALBはIPアドレスが動的に変化するため、DNS名でしかアクセスさせられずIPベースの許可リストとは相性が悪く、Route 53でレコードを作っても最終的な宛先はALBのIPなので状況は変わりません。CloudFrontは通常のディストリビューションでは広範なIPアドレス範囲を使うため、追加の設定をしない限り許可リストは大きくなります。NLBはアベイラビリティゾーンごとの固定IPを持つのでこの点は改善しますが、リージョン内のロードバランサーである以上、世界各地からの接続はインターネットを長距離たどることになります。次にレイテンシーの観点で見ると、ユーザーの近くでトラフィックを受け止め、そこから先を混雑の影響を受けにくいAWSのグローバルネットワークで運ぶ仕組みが必要です。この2つを同時に満たすのがGlobal Acceleratorで、世界中どこからでも同じ2つの静的エニーキャストIPに接続でき、そのIPは最寄りのエッジロケーションで応答します。既存のALBはそのままエンドポイントとして登録できるため、アプリケーション側の作り替えも不要です。したがって、アクセラレーターを作成してALBをエンドポイントに追加し、顧客には固定IPを通知する構成が正解になります。
参考資料
問題文：
大手小売グループは、商品マスタや在庫管理などの社内システムを複数のAWSリージョンにまたがるVPCへ展開しています。各リージョンにはアプリケーションを提供する複数のVPCがあり、その中のリソースへ内部ドメイン名で接続したいと考えています。ネットワーク運用チームは、すべてのリソースに「corp.example.com」というDNSサフィックスを適用し、どのリージョンのVPCからでも同じ名前でリソースを解決できるようにする必要があります。社内システムは毎日の業務で頻繁に相互参照されるため、名前解決は一貫していなければなりません。この要件を満たすために、ネットワーク運用チームは何をするべきですか。
選択肢：
A. リソースがある各リージョンにcorp.example.comのプライベートホストゾーンを作成し、そのリージョンのVPCに関連付けます。各リージョンのリソースのDNSレコードを、対応するプライベートホストゾーンに作成します。
B. corp.example.comのプライベートホストゾーンを1つ作成し、すべてのVPCとのゾーン転送を許可するように構成します。
C. example.comのプライベートホストゾーンを1つ作成し、corp.example.comの単一のリソースレコードを作成します。レコードにマルチバリューアンサールーティングポリシーを適用し、すべてのVPCリソースを個別の値として追加します。
D. corp.example.comのプライベートホストゾーンを1つ作成し、リソースを持つすべてのVPCに関連付けます。プライベートホストゾーンに、すべてのリソースのDNSレコードを作成します。
正解：D
A. リソースがある各リージョンにcorp.example.comのプライベートホストゾーンを作成し、そのリージョンのVPCに関連付けます。各リージョンのリソースのDNSレコードを、対応するプライベートホストゾーンに作成します。
不正解 プライベートホストゾーンは関連付けたVPCからしかレコードを解決できません。この構成では各ホストゾーンが自リージョンのVPCとしか関連付けられていないため、あるVPCから別リージョンのリソース名を引いても、そのレコードを持つホストゾーンが見えず解決できません。同名のゾーンが複数存在することで名前空間も分断され、レコードの追加漏れなど運用負荷も増えます。
B. corp.example.comのプライベートホストゾーンを1つ作成し、すべてのVPCとのゾーン転送を許可するように構成します。
不正解 ゾーン転送は権威DNSサーバー同士がゾーンファイルを複製するための仕組みですが、Route 53のホストゾーンはこの方式に対応していません。プライベートホストゾーンがどのVPCから見えるかは、ゾーン転送ではなくVPCとの関連付けによって決まります。したがって「すべてのVPCとのゾーン転送を許可する」という設定自体が存在せず、この構成は実装できません。
C. example.comのプライベートホストゾーンを1つ作成し、corp.example.comの単一のリソースレコードを作成します。レコードにマルチバリューアンサールーティングポリシーを適用し、すべてのVPCリソースを個別の値として追加します。
不正解 この方法ではcorp.example.comに対する単一のDNSレコードを作成し、マルチバリューアンサールーティングポリシーで複数のリソースを指定しますが、corp.example.comをDNSサフィックスとして使うことはできません。DNSサフィックスの実装には、複数の個別レコードを持つプライベートホストゾーンが必要です。マルチバリューアンサーは複数のIPアドレスを持つ単一レコード向けで、異なる名前の複数リソースには機能しません。
D. corp.example.comのプライベートホストゾーンを1つ作成し、リソースを持つすべてのVPCに関連付けます。プライベートホストゾーンに、すべてのリソースのDNSレコードを作成します。
正解 corp.example.comのプライベートホストゾーンを1つ作成してすべてのVPCに関連付けることで、どのVPCからもこのホストゾーンのレコードを解決できるようになります。プライベートホストゾーンは複数のVPC（別リージョンを含む）と関連付けられるため、一貫したDNS解決を提供します。各リソースの個別のレコードをこのホストゾーン内に作ることで、corp.example.comのサフィックスを持つFQDNにアクセスできます。
全体的な説明
問われている要件
- 複数のAWSリージョンにまたがるVPC内のリソースに、corp.example.comという統一されたDNSサフィックスを適用すること
- どのリージョンのどのVPCからでも、同じ内部ドメイン名で同じリソースを解決できるようにすること
- 業務で頻繁に相互参照されるため、名前解決の結果が一貫していること
- 内部システム向けの名前解決であり、インターネットへレコードを公開しないこと
- ホストゾーンやレコードの管理を増やしすぎず、運用負荷を抑えること
前提知識
プライベートホストゾーンについて
- 指定したVPC内からのDNSクエリにだけ応答する内部向けのホストゾーンで、レコードはインターネットには公開されません
- 作成時に関連付けたVPCに加え、後から複数のVPCを追加で関連付けられます
- 関連付けるVPCは同一リージョンである必要はなく、別リージョンのVPCも関連付けられます
- 別アカウントのVPCと関連付ける場合は、先にホストゾーン側で関連付けを認可する必要があり、この操作はAPIまたはCLIで行います
- 利用するVPCでは enableDnsHostnames と enableDnsSupport の両方を有効にしておく必要があります
名前解決の優先順位について
- 名前空間が重複するホストゾーンが複数ある場合、VPC Resolverは最も具体的に一致するゾーンのレコードを返します
- 同じドメイン名に対してプライベートホストゾーンとResolverルールの両方がある場合は、Resolverルールが優先されます
- 同じ名前のゾーンをリージョンごとに分けて作ると、VPCごとに見えるレコードが変わり、名前解決の結果が一貫しなくなります
DNSサフィックスとゾーン転送について
- DNSサフィックスは短縮名を完全修飾ドメイン名へ補完するための共通部分で、web1はweb1.corp.example.comとして解決されます
- サフィックスを共有する多数のリソースは、そのサフィックスをゾーン名とするホストゾーン内に個別のレコードとして登録します
- ゾーン転送は権威DNSサーバー間でゾーンファイルを複製する仕組みですが、Route 53のホストゾーンはこの方式に対応していません
- VPCから見えるレコードの範囲は、ゾーン転送ではなくホストゾーンとVPCの関連付けで制御します
アーキテクチャ図の解説
アーキテクチャ図
1つのプライベートホストゾーンを複数リージョンのVPCへ関連付けると、統一されたDNSネームスペースになります。corp.example.comという単一のプライベートホストゾーンが、リージョンA・B・Cの各VPCに点線で関連付けられ、web1やdb1など各リソースのレコードを一元的に保持します。プライベートホストゾーンは複数のVPC（別リージョンを含む）と関連付けられるため、どのVPCからでも同じ名前でリソースを解決できます。リージョンごとにホストゾーンを分けると、関連付けのないVPCからはそのゾーンのレコードが見えず、名前空間が分裂してしまいます。DNSサフィックスを揃えるには、ホストゾーンを1つにして全VPCへ関連付けることが肝心です。ゾーン転送による同期はRoute 53では使えない点も、構成判断の前提になります。
解くための考え方
この設問は、複数リージョンに散らばるVPCから同じDNSサフィックスで名前解決できる構成を選ばせる問題です。まず押さえるべきは、プライベートホストゾーンのレコードが見えるかどうかは、そのVPCがホストゾーンに関連付けられているかどうかだけで決まるという点です。ここから、リージョンごとにcorp.example.comのホストゾーンを作り、それぞれ自リージョンのVPCにしか関連付けない構成では、あるVPCから他リージョンのリソース名を引いてもレコードが見えないと分かります。同名ゾーンが並立することで名前空間も分断され、一貫した名前解決という要件に反します。次に、ゾーン転送でゾーンの内容を配る案を検討します。ゾーン転送は権威サーバー同士でゾーンファイルを複製する伝統的な仕組みですが、Route 53のホストゾーンはこれに対応しておらず、可視範囲は関連付けで制御するため、この案は設定自体が成立しません。マルチバリューアンサーを使う案は、1つのレコード名に複数の値を返す機能であり、web1やdb1といった別々の名前を持つリソース群にサフィックスを付与する用途とは目的が異なります。残るのは、corp.example.comのプライベートホストゾーンを1つだけ作り、リソースを持つすべてのVPCへ関連付け、各リソースのレコードをそのゾーン内に登録する構成です。プライベートホストゾーンはリージョンをまたいでVPCを関連付けられるため、この方法であればどのVPCからでも同じ名前で同じ結果が返り、管理するゾーンも1つで済みます。
参考資料
問題文：
大手総合物流企業は、オンプレミスのデータセンターで稼働する基幹システムをAWSへ段階的に移行しています。移行先のワークロードは複数のVPCへ分かれ、相互に依存関係があるため、すべてを同時に移行できるわけではありません。移行期間中は、AWS上のワークロードとオンプレミスに残るシステムの間で、双方の内部ドメイン名を相互に解決できる必要があります。毎日の貨物追跡や在庫照会の業務で両方向の名前解決が継続的に使われるため、ネットワーク運用チームはエンドツーエンドの双方向DNS解決を確立したいと考えています。要件を満たすソリューションはどれですか。
選択肢：
A. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access ManagerでResolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをインバウンドエンドポイントへ転送するよう構成します。
B. 各アプリケーションVPCのパブリックホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access ManagerでResolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをインバウンドエンドポイントへ転送するよう構成します。
C. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access ManagerでResolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをアウトバウンドエンドポイントへ転送するよう構成します。
D. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アウトバウンドエンドポイントをアプリケーションVPCに関連付け、AWS Resource Access Managerでプライベートホストゾーンをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをインバウンドエンドポイントへ転送するよう構成します。
正解：A
A. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access ManagerでResolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをインバウンドエンドポイントへ転送するよう構成します。
正解 内部向けのレコードをプライベートホストゾーンに置き、それをイグレスVPCへ関連付けることで、インバウンドエンドポイントに届いたオンプレミスからのクエリに応答できます。逆方向はResolverルールで指定ドメインのクエリをアウトバウンドエンドポイント経由でオンプレミスDNSサーバーへ転送し、そのルールをAWS RAMでアプリケーションアカウントへ共有して各VPCに適用します。エンドポイントの向きと共有対象がいずれも正しい構成です。
B. 各アプリケーションVPCのパブリックホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access ManagerでResolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをインバウンドエンドポイントへ転送するよう構成します。
不正解 パブリックホストゾーンはインターネット経由のDNS解決向けであり、プライベートなワークロードのレコードを保持するには適していません。内部ワークロードのDNSレコードがインターネット上に公開されることになり、セキュリティ上の問題を招きます。ホストゾーンの種類以外は正解の構成と同じです。
C. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access ManagerでResolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをアウトバウンドエンドポイントへ転送するよう構成します。
不正解 オンプレミスDNSサーバーがクラウドドメインをアウトバウンドエンドポイントへ転送する点が誤りです。アウトバウンドエンドポイントはAWS内からオンプレミスへのクエリを送信するためのもので、オンプレミスからのクエリを受信するものではありません。オンプレミスからのクエリを受信するにはインバウンドエンドポイントを使います。
D. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを作成します。オンプレミスドメインへのクエリをオンプレミスDNSサーバーへ転送するResolverルールを定義します。アウトバウンドエンドポイントをアプリケーションVPCに関連付け、AWS Resource Access Managerでプライベートホストゾーンをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを、クラウドドメインをインバウンドエンドポイントへ転送するよう構成します。
不正解 プライベートホストゾーンそのものをAWS RAMの共有リソースとして指定することはできません。他アカウントへ広げる場合は、ホストゾーン側で関連付けを認可してVPCを追加するか、Route 53プロファイルにまとめてプロファイルを共有します。またResolverエンドポイントは特定のVPC内に作成するもので、別のVPCへ付け替える設定はありません。共有すべき対象はResolverルールです。
全体的な説明
問われている要件
- AWS上のワークロードとオンプレミスに残るシステムの間で、双方向にドメイン名を解決できるようにすること
- AWSからオンプレミスへのクエリと、オンプレミスからAWSへのクエリの両方を継続的に処理できること
- 段階的に移行される複数のアプリケーションVPCが、同じDNS設定を共有できること
- 内部システムのレコードをインターネットへ公開しないこと
- 複数アカウントにまたがる構成でも、DNS設定を一元的に管理できること
前提知識
Route 53 Resolverのエンドポイントについて
- インバウンドエンドポイントは、オンプレミスのDNSサーバーからAWS内の名前を問い合わせるための入口です。作成したVPCのサブネットにENIが配置され、そのIPアドレスへオンプレミス側から転送します
- アウトバウンドエンドポイントは、VPC内のリソースがオンプレミスの名前を問い合わせるための出口で、Resolverルールに従ってクエリを外部のDNSサーバーへ転送します
- どちらのエンドポイントも作成したVPC内に存在し、可用性のため2つ以上のアベイラビリティゾーンにIPアドレスを持ちます
- オンプレミスとの通信経路にはDirect ConnectやSite-to-Site VPNなどのプライベート接続が必要です
Resolverルールと共有について
- 転送ルールは対象ドメイン名と転送先DNSサーバーのIPアドレスを定義し、VPCに関連付けることで有効になります
- ResolverルールはAWS RAMで他のアカウントや組織へ共有でき、共有先アカウントは自分のVPCに関連付けて使えます
- プライベートホストゾーンはAWS RAMの共有リソースとしては扱えず、他アカウントのVPCとはホストゾーン側で関連付けを認可して追加します
- 2024年に追加されたRoute 53プロファイルを使うと、プライベートホストゾーンやResolverルールをまとめた設定をAWS RAMで共有し、複数VPCへ一括適用できます
ホストゾーンの使い分けについて
- プライベートホストゾーンは関連付けたVPCからのみ解決でき、社内システムの名前解決に用います
- パブリックホストゾーンはインターネット上の権威DNSとして公開され、内部ワークロードのレコードを置く用途には適しません
- 集約用のイグレスVPCにアプリケーションVPCのプライベートホストゾーンを関連付けると、インバウンドエンドポイントに届いたクエリでそれらのレコードを解決できます
アーキテクチャ図の解説
アーキテクチャ図
Route 53 Resolverのインバウンドとアウトバウンドの2つのエンドポイントを使い分けると、双方向のDNS解決が成立します。オンプレミスからAWSへの解決は、オンプレミスDNSサーバーがクラウドドメインのクエリをイグレスVPCのインバウンドエンドポイントへ転送し、イグレスVPCに関連付けられたプライベートホストゾーンのレコードを返します。AWSからオンプレミスへの解決は、アプリケーションVPCのリソースがResolverルールに従ってアウトバウンドエンドポイントへクエリを送り、オンプレミスDNSサーバーへ転送します。ResolverルールはAWS RAMでアプリケーションアカウントへ共有され、各VPCに関連付けて有効になります。エンドポイントの向きを逆にするとクエリの入口と出口が入れ替わり、双方向の名前解決が成立しません。段階的な移行中も両方向を一貫して解決できます。
解くための考え方
この設問は、選択肢の文面がほとんど同じで、違いは「ホストゾーンの種類」「エンドポイントの向き」「共有するリソース」の3点に絞られています。まずエンドポイントの向きを確認します。オンプレミスのDNSサーバーがAWS内の名前を引くには、クエリを受け取る側であるインバウンドエンドポイントへ転送する必要があります。アウトバウンドエンドポイントはAWSから外部へクエリを出すための出口なので、オンプレミス側の転送先に指定しても応答は得られません。ここで向きを取り違えている選択肢が落ちます。次にホストゾーンの種類です。移行中の内部システムのレコードをパブリックホストゾーンに置けば、インターネット上の誰からでも社内システムの名前と対応付けが参照できてしまい、内部向けという前提に反します。関連付けたVPCからだけ解決できるプライベートホストゾーンが適切です。最後に共有するリソースを見ます。Resolverルールはマルチアカウント構成での共有を想定した機能で、AWS RAMで共有して各アプリケーションアカウントのVPCに関連付けられます。一方、プライベートホストゾーン自体はAWS RAMの共有対象ではなく、他アカウントのVPCと使う場合は関連付けの認可という別の手順を踏みます。したがって、プライベートホストゾーンをイグレスVPCへ関連付け、ResolverルールをAWS RAMで共有し、オンプレミスDNSサーバーはインバウンドエンドポイントへ転送する構成が、3つの観点すべてを満たす唯一の選択肢になります。
参考資料
問題文：
大手広告代理店は、クリエイティブ制作の進捗を管理する制作管理システムをap-northeast-1（東京）リージョンのVPCで稼働させています。シドニーにある地域オフィスは、VPCへのAWS Site-to-Site VPN接続に仮想プライベートゲートウェイ（VGW）を使用しています。同社はトランジットゲートウェイ（TGW）を構成し、このVPCと社内の各部門が使う複数のVPCを接続しています。シドニーオフィスの社員は、毎日の制作レビューでこのシステムへ接続する際にレイテンシーの問題を感じています。このレイテンシーを削減するために、ネットワークエンジニアは何をするべきですか。
選択肢：
A. 新しいSite-to-Site VPN接続を作成し、トランジットゲートウェイをターゲットゲートウェイとして設定します。新しい接続でアクセラレーションを有効にし、シドニーオフィスのVPNデバイスを新しい接続の設定で更新します。
B. 既存のSite-to-Site VPN接続を変更し、トランジットゲートウェイをターゲットゲートウェイとして設定します。既存の接続でアクセラレーションを有効にします。
C. ap-southeast-2（シドニー）リージョンに新しいトランジットゲートウェイを作成し、既存のトランジットゲートウェイとピアリングします。既存のSite-to-Site VPN接続を変更し、新しいトランジットゲートウェイをターゲットゲートウェイとして設定します。
D. Site-to-Site VPN接続をエンドポイントとする新しいAWS Global Acceleratorアクセラレーターを作成し、シドニーオフィスのVPNデバイスを新しい接続の設定で更新します。
正解：A
A. 新しいSite-to-Site VPN接続を作成し、トランジットゲートウェイをターゲットゲートウェイとして設定します。新しい接続でアクセラレーションを有効にし、シドニーオフィスのVPNデバイスを新しい接続の設定で更新します。
正解 Site-to-Site VPN接続をトランジットゲートウェイへ移行してアクセラレーションを有効にすると、VPNトラフィックは最寄りのAWSエッジロケーションへ入り、AWSのグローバルネットワークを経由して東京リージョンへ到達します。インターネット経由より低レイテンシーの経路が得られます。既存の接続ではアクセラレーションを有効にできないため、新しい接続の作成が必要です。
B. 既存のSite-to-Site VPN接続を変更し、トランジットゲートウェイをターゲットゲートウェイとして設定します。既存の接続でアクセラレーションを有効にします。
不正解 ターゲットゲートウェイを仮想プライベートゲートウェイからトランジットゲートウェイへ変更する操作自体は可能ですが、アクセラレーションは接続の作成時にのみ指定できる設定で、既存のSite-to-Site VPN接続について後から有効化も無効化もできません。アクセラレーションを使うには、有効にした新しいVPN接続を作成し、切り替え後に古い接続を削除する必要があります。
C. ap-southeast-2（シドニー）リージョンに新しいトランジットゲートウェイを作成し、既存のトランジットゲートウェイとピアリングします。既存のSite-to-Site VPN接続を変更し、新しいトランジットゲートウェイをターゲットゲートウェイとして設定します。
不正解 Site-to-Site VPN接続もトランジットゲートウェイもリージョン単位のリソースであり、東京リージョンで作成した既存の接続のターゲットに、シドニーリージョンの新しいトランジットゲートウェイを指定することはできません。シドニー側で終端するにはカスタマーゲートウェイとVPN接続を新規に作成する必要があります。加えて、この構成ではアクセラレーションを使わないため、要件に対して遠回りです。
D. Site-to-Site VPN接続をエンドポイントとする新しいAWS Global Acceleratorアクセラレーターを作成し、シドニーオフィスのVPNデバイスを新しい接続の設定で更新します。
不正解 AWS Global AcceleratorはWebアプリケーションやAPIのエンドポイントへのアクセス高速化に使われますが、Site-to-Site VPN接続のエンドポイントとして直接設定することはできません。VPN接続のアクセラレーションはGlobal Acceleratorとは別の仕組みです。
全体的な説明
問われている要件
- シドニーオフィスから東京リージョンの制作管理システムへ接続する際のレイテンシーを低減すること
- 拠点とAWSの間の長距離区間を、混雑しやすいインターネット経由から、より安定した経路へ切り替えること
- 既存のトランジットゲートウェイに接続された複数のVPCへ、引き続き到達できること
- オンプレミス側のVPNデバイスの設定変更を伴う移行手順まで含めて検討すること
前提知識
Site-to-Site VPNのターゲットゲートウェイについて
- Site-to-Site VPNは、拠点のカスタマーゲートウェイデバイスとAWSの間をIPsecトンネルで接続します
- AWS側の終端には、単一のVPCに接続する仮想プライベートゲートウェイと、複数のVPCやVPNを束ねるトランジットゲートウェイがあります
- 作成済みのVPN接続でも、ターゲットゲートウェイを仮想プライベートゲートウェイからトランジットゲートウェイへ変更する移行操作が用意されています
- 移行の際は新しいエンドポイントのプロビジョニング中に短時間の通信断が生じ、ASNが異なる場合はカスタマーゲートウェイデバイス側の設定合わせも必要です
アクセラレーテッドSite-to-Site VPNについて
- AWS Global Acceleratorの仕組みを利用し、VPNトラフィックを最寄りのAWSエッジロケーションで受けてAWSのグローバルネットワークで運びます
- トランジットゲートウェイにアタッチするVPN接続で利用でき、仮想プライベートゲートウェイでは利用できません
- 既存のVPN接続に対してアクセラレーションを有効化または無効化することはできず、作成時に指定します
- NAT-Tが必須で、IKEネゴシエーションはカスタマーゲートウェイデバイス側から開始する必要があります
- Direct Connectのパブリック仮想インターフェイス経由では利用できません
AWS Global Acceleratorについて
- 静的なエニーキャストIPアドレスでトラフィックを受け、AWSのグローバルネットワーク経由でエンドポイントへ届けるサービスです
- エンドポイントとして登録できるのはApplication Load Balancer、Network Load Balancer、EC2インスタンス、Elastic IPアドレスです
- Site-to-Site VPN接続をエンドポイントに登録する使い方は用意されておらず、VPNの高速化はアクセラレーションの設定として行います
アーキテクチャ図の解説
アーキテクチャ図
アクセラレーションを有効にしたVPNはパブリックインターネットを迂回し、AWSのグローバルネットワークを経由します。シドニーオフィスのカスタマーゲートウェイデバイスから出たVPNトラフィックは、アクセラレーションなしではインターネットをそのまま経由して東京リージョンのトランジットゲートウェイへ向かいます。アクセラレーションを有効にすると、シドニー近郊のAWSエッジロケーションへ入り、混雑の少ないAWSグローバルネットワークを通って東京のトランジットゲートウェイへ到達し、そこから制作管理システムや各部門のVPCへ分散されます。アクセラレーションはトランジットゲートウェイに接続するVPNで利用でき、仮想プライベートゲートウェイでは利用できません。長距離のトラフィックをインターネットに流すか、AWSのバックボーンに載せるかが、レイテンシー削減の分かれ目になります。
解くための考え方
シドニーと東京の間は物理的に遠く、インターネット経由では経路の混雑や迂回によって遅延が積み上がります。この距離を短くすることはできないため、改善の方向は「どの経路で運ぶか」を変えることになります。ここで思い出したいのがアクセラレーテッドSite-to-Site VPNで、トラフィックを最寄りのAWSエッジロケーションで受け止め、そこから先をAWSのグローバルネットワークで運ぶ仕組みです。次に、この機能を使うための前提条件を確認します。アクセラレーションはトランジットゲートウェイにアタッチするVPN接続で利用でき、現在の構成のように仮想プライベートゲートウェイで終端しているVPNでは利用できません。問題文にはすでにトランジットゲートウェイが存在すると書かれているため、そこへ接続する形へ寄せるのが自然です。さらに重要なのが、アクセラレーションはVPN接続の作成時にしか指定できず、既存の接続を後から変更して有効化することはできないという制約です。この一点で、既存接続を変更して有効化しようとする選択肢は除外できます。残る候補のうち、シドニーリージョンにトランジットゲートウェイを新設してピアリングする案は、既存のVPN接続のターゲットを別リージョンのゲートウェイへ変更するという実現できない手順を含んでいます。Global AcceleratorのエンドポイントにVPN接続を登録する案も、そもそもそのようなエンドポイント種別が存在しません。したがって、トランジットゲートウェイをターゲットとする新しいSite-to-Site VPN接続をアクセラレーション有効で作成し、シドニーオフィスのVPNデバイスを新しい接続情報で更新する手順が正解になります。
参考資料
問題文：
ある保険会社のネットワーク運用チームは、本番移行に先立ち、開発アカウントのVPCのネットワーク設計を構築して検証しています。この会社は金融業界のセキュリティ基準に準拠するため、VPC、サブネット、セキュリティグループ、ルートテーブルなどのネットワークリソースに加えられる変更を継続的に監視し、社内のネットワークセキュリティポリシーへの準拠を厳格に担保する必要があります。加えて、監査部門から四半期ごとに、特定の日時時点で各リソースの設定がどのようになっていたかを提示するよう求められています。これらの要件を満たすソリューションはどれですか。
選択肢：
A. カスタムパターンを持つAmazon EventBridge（Amazon CloudWatch Events）ルールを作成して、アカウント内の変更を監視します。ルールからAWS Lambda関数を呼び出して非準拠リソースを特定し、特定した変更をAmazon DynamoDBテーブルに保存します。
B. AWS CloudTrailでネットワークリソースに対するAPI呼び出しを記録します。Amazon AthenaでCloudTrailのログを検索して、変更を行ったユーザーと日時を特定し、非準拠の変更を洗い出します。
C. AWS Configを使用してネットワークリソースの現在の状態を継続的に記録します。社内のセキュリティポリシーを反映したConfig Rules（マネージドルールまたはカスタムルール）を作成し、非準拠リソースの自動修復を設定します。
D. AWS Systems Manager Inventoryを使用してネットワークリソースの現在の状態を記録します。Systems Manager State Managerを使用して、望ましい設定を強制し、非準拠リソースの修復を実行します。
正解：C
A. カスタムパターンを持つAmazon EventBridge（Amazon CloudWatch Events）ルールを作成して、アカウント内の変更を監視します。ルールからAWS Lambda関数を呼び出して非準拠リソースを特定し、特定した変更をAmazon DynamoDBテーブルに保存します。
不正解 EventBridgeはAPI呼び出しなどのイベントを即時に検知する用途には適していますが、リソースの設定状態を時系列で保持する仕組みは持ちません。Lambdaで判定してDynamoDBへ書き込む方式では、設定項目のバージョン管理や変更前後の差分の保持、任意の日時時点のスナップショットの提示までを自前で実装する必要があり、四半期監査に耐える設定履歴を維持する運用負担が大きくなります。
B. AWS CloudTrailでネットワークリソースに対するAPI呼び出しを記録します。Amazon AthenaでCloudTrailのログを検索して、変更を行ったユーザーと日時を特定し、非準拠の変更を洗い出します。
不正解 AWS CloudTrailはAPI呼び出しの記録であり、誰がいつどの操作を行ったかは分かりますが、その結果としてリソースの設定がどう変わったか（設定状態そのもの）は保持しません。Athenaで検索しても、特定の時点におけるリソースの設定スナップショットを取り出すことはできず、「過去の設定にアクセスする」という要件を満たせません。
C. AWS Configを使用してネットワークリソースの現在の状態を継続的に記録します。社内のセキュリティポリシーを反映したConfig Rules（マネージドルールまたはカスタムルール）を作成し、非準拠リソースの自動修復を設定します。
正解 AWS Configはリソース設定の変更を追跡し、設定の履歴を記録するために設計されたサービスです。Config Rulesで設定の準拠状況を評価し、非準拠リソースの自動修復を設定できます。また、設定の履歴にアクセスして、特定の時点でのリソース状態を確認できます。変更監視、コンプライアンス確保、過去の設定へのアクセスの3要件を同時に満たします。
D. AWS Systems Manager Inventoryを使用してネットワークリソースの現在の状態を記録します。Systems Manager State Managerを使用して、望ましい設定を強制し、非準拠リソースの修復を実行します。
不正解 AWS Systems Manager InventoryはEC2インスタンスやオンプレミスサーバーの管理に適していますが、VPCやサブネット、セキュリティグループなどのネットワークリソースの設定管理には十分ではありません。State Managerも主にサーバーの設定管理に使われ、ネットワークリソースの管理には最適化されていません。この案では、特にネットワークリソースの設定履歴の管理という要件を満たせません。
全体的な説明
問われている要件
- VPC、サブネット、セキュリティグループ、ルートテーブルなどのネットワークリソースの変更を継続的に監視すること
- 社内のネットワークセキュリティポリシーへの準拠状況を評価し、逸脱を是正できること
- 四半期ごとの監査に備え、特定の日時時点における各リソースの設定を後から提示できること
- 独自開発を最小限に抑え、マネージドサービスの標準機能で実現すること
前提知識
AWS Configについて
- 設定レコーダーが記録対象のリソースを継続的に追跡し、変更が発生するたびに設定項目（Configuration Item）を作成します。
- 設定履歴とリソースタイムラインから、任意の日時におけるリソースの設定内容と変更の前後関係をたどれます。
- VPC、サブネット、ルートテーブル、セキュリティグループ、ネットワークACLなどのネットワークリソースが記録対象に含まれます。
- Config ルールにはマネージドルールとカスタムルールがあり、1リージョンあたり最大1,000ルールを作成できます。非準拠リソースの修復はSystems Manager Automationドキュメントで自動実行できます。
- アグリゲータを使うと、複数のアカウントとリージョンの設定および準拠状況を1か所に集約して確認できます。
AWS CloudTrailについて
- 誰がいつどのAPIを呼び出したかという操作の証跡を記録し、Amazon AthenaでSQLによる検索ができます。
- 記録されるのはAPI呼び出しの要求と応答であり、その結果としてリソースがどの設定状態になったかを時系列で保持する機能ではありません。
Amazon EventBridgeについて
- AWSサービスから発行されるイベントをルールでマッチさせ、Lambdaなどのターゲットへ配信するイベントバスです。
- 変更の即時検知には向きますが、設定履歴の保持や準拠評価、修復の仕組みは自前で実装することになります。
AWS Systems Managerについて
- Inventoryは、マネージドノードのOS情報やインストール済みソフトウェア、ネットワーク設定などの構成情報を収集します。
- State Managerは、マネージドノードに対して望ましい状態を定期的に適用・維持する機能で、対象はノードが中心です。
解くための考え方
まず要件を「変更の継続的な監視」「セキュリティポリシーへの準拠の担保」「過去の任意時点の設定の提示」の3つに分解します。1つ目だけであれば複数の案が候補になりますが、3つ目が決め手になります。イベント検知やAPI証跡を中心とする仕組みは、変更が起きた事実や実行者は分かっても、その結果としてリソースがどの設定状態になったかを時系列で保持しません。そのため、監査部門から「四半期末のこの時刻に、このセキュリティグループのインバウンドルールはどうなっていたか」と問われたときに答えられません。EventBridgeとLambdaとDynamoDBを組み合わせる案は、この設定履歴の保持を自前で作り込むことになり、最小限の設定という観点からも不利です。次に2つ目の準拠の担保を見ます。望ましい設定を定義して継続的に評価し、逸脱したリソースを自動的に元へ戻す仕組みが標準機能として用意されているかが判断軸になります。最後に対象リソースの種類を確認します。設問が挙げているのはVPC、サブネット、セキュリティグループ、ルートテーブルといったネットワークリソースであり、マネージドノードの構成管理を目的とするInventoryやState Managerとは対象がかみ合いません。これら3つの観点をすべて標準機能で満たすのは、設定変更の記録と履歴の保持、ルールによる準拠評価、自動修復を一体で提供するAWS Configです。
参考資料
問題文：
大手旅行予約サイトを運営する会社は、予約管理アプリケーションをオンプレミスからAWSへ移行しています。このアプリケーションは、単一のVPCにデプロイしたAmazon EC2インスタンスで稼働する予定です。移行期間中、EC2インスタンスからはオンプレミスに残る予約・顧客管理サーバー（例: booking.onprem.example.com）の名前を解決できる必要があります。移行は3か月で完了する見込みで、その後はオンプレミスサーバーの名前解決が不要になります。ネットワークエンジニアが最小限の設定でこれらの要件を満たすためにすべきことは何ですか。
選択肢：
A. オンプレミスとAWSの間にAWS Site-to-Site VPN接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolverのアウトバウンドエンドポイントをデプロイします。
B. プライベートVIFを持つAWS Direct Connect接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントをデプロイします。
C. オンプレミスとAWSの間にAWS Client VPN接続を設定します。VPCにAmazon Route 53 Resolverのインバウンドエンドポイントをデプロイします。
D. パブリックVIFを持つAWS Direct Connect接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolverのインバウンドエンドポイントをデプロイし、エンドポイントに割り当てられたIPアドレスを使ってオンプレミスDNSサーバーへ接続します。
正解：A
A. オンプレミスとAWSの間にAWS Site-to-Site VPN接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolverのアウトバウンドエンドポイントをデプロイします。
正解 Site-to-Site VPNはインターネット経由でIPsecの暗号化トンネルを張る構成で、カスタマーゲートウェイ側の設定が済んでいれば数十分から数時間で疎通できます。ここにRoute 53 Resolverのアウトバウンドエンドポイントと転送ルールを組み合わせれば、VPC内のEC2インスタンスが出したオンプレミスドメインのクエリだけをVPN経由で社内DNSサーバーへ転送できます。移行完了後は両方を削除するだけで元に戻せます。
B. プライベートVIFを持つAWS Direct Connect接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントをデプロイします。
不正解 Direct Connect接続は高帯域幅かつ安定した専用接続ですが、回線の手配とクロスコネクトの敷設を伴うため、利用開始まで数週間から数か月を要するのが一般的です。3か月で終わる移行のためだけに導入するには時間もコストも見合いません。加えて、名前解決の方向はAWSからオンプレミスの一方向であり、オンプレミス側からAWS内の名前を引くためのインバウンドエンドポイントを併設する必要もありません。
C. オンプレミスとAWSの間にAWS Client VPN接続を設定します。VPCにAmazon Route 53 Resolverのインバウンドエンドポイントをデプロイします。
不正解 AWS Client VPNは、利用者の端末にインストールしたOpenVPNクライアントからAWSへ接続するリモートアクセス向けのサービスで、データセンターとVPCを常時つなぐサイト間接続の用途とは前提が異なります。さらにインバウンドエンドポイントはオンプレミスのDNSサーバーからAWS内の名前を解決させるためのものであり、AWSからオンプレミスを引くという今回の方向とは逆になります。
D. パブリックVIFを持つAWS Direct Connect接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolverのインバウンドエンドポイントをデプロイし、エンドポイントに割り当てられたIPアドレスを使ってオンプレミスDNSサーバーへ接続します。
不正解 Direct Connectは利用開始までに数週間から数か月を要するため、3か月の移行期間には不向きです。またパブリック仮想インターフェイスはAWSのパブリックエンドポイントへ到達するためのもので、VPCやオンプレミスのプライベートアドレス空間との通信にはプライベート仮想インターフェイスを使います。さらに、インバウンドエンドポイントはオンプレミスからAWS内の名前を解決する用途であり、今回必要な方向と逆です。
全体的な説明
問われている要件
- VPC内のEC2インスタンスから、オンプレミスに残るサーバーの名前を解決できること
- 名前解決の方向はAWSからオンプレミスの一方向であること
- 移行期間である3か月だけ使えればよく、移行後は不要になること
- 最小限の設定で実装でき、不要になったら容易に撤去できること
前提知識
AWS Site-to-Site VPNについて
- インターネット経由でオンプレミスのカスタマーゲートウェイとAWSの仮想プライベートゲートウェイまたはTransit Gatewayを結ぶ、IPsecの暗号化トンネルです。
- 1つのVPN接続には冗長化のために2本のトンネルが作成され、トンネルあたりの最大スループットは1.25 Gbpsです。
- 物理工事が不要なため短時間で作成でき、不要になったら削除するだけで撤去できます。一時的な接続に向いた選択肢です。
AWS Direct Connectについて
- AWSとの間に専用線を敷設する接続方式で、インターネットを経由しない安定した帯域と低いレイテンシーが得られます。
- 回線手配とクロスコネクトの敷設を伴うため、利用開始までに数週間から数か月かかるのが一般的です。
- プライベート仮想インターフェイスはVPCなどのプライベートリソースへ、パブリック仮想インターフェイスはAWSのパブリックエンドポイントへ到達するために使います。
Amazon Route 53 Resolverについて
- インバウンドエンドポイントは、オンプレミスのDNSサーバーからAWS内の名前（VPCのプライベートホストゾーンなど）を解決させるために使います。
- アウトバウンドエンドポイントは、VPC内のリソースがオンプレミスなどの外部DNSサーバーの名前を解決するために使い、転送ルールで対象ドメインを指定します。
- どちらのエンドポイントも可用性のために異なるアベイラビリティーゾーンの2つ以上のIPアドレスで構成し、IPアドレスあたり毎秒約10,000クエリを処理できます。
AWS Client VPNについて
- 利用者の端末からAWSへ接続するリモートアクセス向けのマネージドVPNで、認証されたクライアント単位で接続します。
- 拠点間を常時つなぐサイト間接続の代替にはならず、VPC全体のDNS転送基盤として使う構成ではありません。
アーキテクチャ図の解説
アーキテクチャ図
アウトバウンドエンドポイントとSite-to-Site VPNを組み合わせるだけで、AWSからオンプレミスの名前解決を最小構成で実現できます。VPC内のEC2インスタンスがオンプレミスサーバーの名前解決を要求すると、Route 53 Resolverのアウトバウンドエンドポイントがそのクエリを受け取り、VPN接続を通じてオンプレミスDNSサーバーへ転送します。DNSサーバーが返したIPアドレスは逆の経路でEC2インスタンスへ戻り、EC2インスタンスはそのIPへ接続してデータをやり取りします。名前解決の方向が「AWSからオンプレミス」なので、使うのはアウトバウンドエンドポイントです。インバウンドエンドポイントに置き換えると入口と出口が逆になり、この要件は満たせません。VPNは数時間で確立でき、移行後に削除できるため、3か月の一時的な利用に適しています。
解くための考え方
判断軸は「接続手段の準備期間」と「名前解決の向き」の2つです。まず接続手段から絞り込みます。設問は移行が3か月で終わり、その後はオンプレミスの名前解決が不要になると明示しています。Direct Connectは回線の手配と物理的な敷設を伴い、利用開始まで数週間から数か月かかるうえ、撤去にも手間がかかります。移行の途中で使い始められない可能性があり、最小限の設定という条件にも反します。これに対しSite-to-Site VPNはインターネット経由でIPsecトンネルを張るだけなので短時間で確立でき、移行が終わればVPN接続を削除するだけで済みます。したがって一時利用にはVPNが適切です。次に名前解決の向きを確認します。今回必要なのはVPC内のEC2インスタンスがオンプレミスのサーバー名を引くことであり、クエリはAWSからオンプレミスへ向かいます。Route 53 Resolverでこの方向を担うのはアウトバウンドエンドポイントと転送ルールであり、オンプレミス側からAWS内の名前を引かせるインバウンドエンドポイントは今回不要です。両方を作る構成は要件以上の設定を行うことになり、最小限という条件から外れます。最後に、リモートアクセス用のClient VPNは拠点間を常時接続する用途とは前提が異なるため候補になりません。以上から、Site-to-Site VPNとアウトバウンドエンドポイントの組み合わせが残ります。
参考資料
問題文：
ある大手製造業グループは、複数の事業部門のアプリケーションをAWSへ移行しています。同社は、VPC内を流れるトラフィックの集中検査とNAT機能のために、サードパーティ製のファイアウォールアプライアンスを導入する計画です。対象のVPCはパブリックサブネットとプライベートサブネットで構成されています。ファイアウォールアプライアンスはロードバランサーの背後に配置する必要があります。セキュリティチームは、検査対象のトラフィック量が増えてもアプライアンスを水平スケールでき、かつ運用コストを最小限に抑えられる構成を求めています。どのアーキテクチャが最もコスト効率よくこれらの要件を満たしますか。
選択肢：
A. ファイアウォールアプライアンスをターゲットとするGateway Load Balancerを導入します。ファイアウォールアプライアンスをプライベートサブネット内の単一のネットワークインターフェイスで構成します。検査後のトラフィックをインターネットへ送信するためにNATゲートウェイを使用します。
B. ファイアウォールアプライアンスをターゲットとするGateway Load Balancerを導入します。ファイアウォールアプライアンスを2つのネットワークインターフェイスで構成します。1つはプライベートサブネット内、もう1つはパブリックサブネット内です。検査後のトラフィックをインターネットへ送信するためにファイアウォールアプライアンスのNAT機能を使用します。
C. ファイアウォールアプライアンスをターゲットとするNetwork Load Balancerを導入します。ファイアウォールアプライアンスをプライベートサブネット内の単一のネットワークインターフェイスで構成します。検査後のトラフィックをインターネットへ送信するためにNATゲートウェイを使用します。
D. ファイアウォールアプライアンスをターゲットとするNetwork Load Balancerを導入します。ファイアウォールアプライアンスを2つのネットワークインターフェイスで構成します。1つはプライベートサブネット内、もう1つはパブリックサブネット内です。検査後のトラフィックをインターネットへ送信するためにファイアウォールアプライアンスのNAT機能を使用します。
正解：B
A. ファイアウォールアプライアンスをターゲットとするGateway Load Balancerを導入します。ファイアウォールアプライアンスをプライベートサブネット内の単一のネットワークインターフェイスで構成します。検査後のトラフィックをインターネットへ送信するためにNATゲートウェイを使用します。
不正解 Gateway Load Balancerを使う点は適切ですが、ファイアウォールアプライアンスが単一インターフェイスの「シングルアーム」モードで配置されています。この構成では追加のNATゲートウェイが必要となり、NATゲートウェイは時間単位の料金と処理データ量に応じた料金が発生するため、コスト効率が低下します。アプライアンスが本来持つNAT機能を活用せず、追加のAWSマネージドサービスへ料金を支払うことになります。
B. ファイアウォールアプライアンスをターゲットとするGateway Load Balancerを導入します。ファイアウォールアプライアンスを2つのネットワークインターフェイスで構成します。1つはプライベートサブネット内、もう1つはパブリックサブネット内です。検査後のトラフィックをインターネットへ送信するためにファイアウォールアプライアンスのNAT機能を使用します。
正解 Gateway Load Balancerを使い、ファイアウォールアプライアンスを「デュアルアーム」モード（2つのネットワークインターフェイス）で配置します。この構成ではアプライアンス自体のNAT機能を利用するため、追加のNATゲートウェイが不要になり、コストを削減できます。ファイアウォールアプライアンスはもともと必要なコンポーネントであり、その内蔵NAT機能を使えば、追加のNATゲートウェイ料金を払わずに済みます。
C. ファイアウォールアプライアンスをターゲットとするNetwork Load Balancerを導入します。ファイアウォールアプライアンスをプライベートサブネット内の単一のネットワークインターフェイスで構成します。検査後のトラフィックをインターネットへ送信するためにNATゲートウェイを使用します。
不正解 Network Load Balancerはレイヤー4（TCP/UDP/TLS）の負荷分散向けであり、ルートテーブルを介した透過的な検査やGENEVEカプセル化による全パケット転送ができません。ファイアウォールアプライアンスのようなネットワークアプライアンスの集中検査にはGateway Load Balancerが必要です。さらに、この案は追加のNATゲートウェイを必要とするため、コスト効率も低下します。
D. ファイアウォールアプライアンスをターゲットとするNetwork Load Balancerを導入します。ファイアウォールアプライアンスを2つのネットワークインターフェイスで構成します。1つはプライベートサブネット内、もう1つはパブリックサブネット内です。検査後のトラフィックをインターネットへ送信するためにファイアウォールアプライアンスのNAT機能を使用します。
不正解 この案はファイアウォールアプライアンスのNAT機能を使っており、追加のNATゲートウェイが不要な点ではコスト効率的です。しかし、Network Load Balancerはルートテーブルを介した透過的な検査とGENEVEカプセル化に対応しておらず、ファイアウォールアプライアンスの集中検査には使えません。この用途にはGateway Load Balancerが必要です。
全体的な説明
問われている要件
- サードパーティ製ファイアウォールアプライアンスによるVPC内トラフィックの集中検査を実現すること
- 検査後のトラフィックをインターネットへ送出するためのNAT機能を用意すること
- アプライアンスをロードバランサーの背後に置き、トラフィック量に応じて水平にスケールできること
- パブリックサブネットとプライベートサブネットを持つ既存VPCの構成を前提とすること
- 追加で導入するコンポーネントを増やさず、最もコスト効率の高い構成にすること
前提知識
Gateway Load Balancerについて
- ファイアウォールや侵入検知・防止システムなど、サードパーティ製の仮想アプライアンスを透過的に配置するためのロードバランサーです。
- 受け取ったパケットをUDPポート6081のGENEVEでカプセル化し、元の送信元・宛先情報を保ったままアプライアンスへ転送します。
- Gateway Load Balancerエンドポイントをルートテーブルの次ホップに指定して経路を寄せるため、アプリケーション側の設定変更は不要です。同じフローの往復は同一アプライアンスへ届きます。
- ターゲットグループに登録したアプライアンスをヘルスチェックし、台数を増やして検査能力を水平にスケールできます。
Network Load Balancerについて
- レイヤー4で動作し、TCP、UDP、TLSのリスナーを持つロードバランサーです。
- 宛先がロードバランサー自身になるプロキシ型の負荷分散であり、GENEVEによる全パケット転送や透過的な検査の用途には対応していません。
NATゲートウェイについて
- プライベートサブネットのリソースがインターネットへ発信するためのマネージドサービスで、帯域は5 Gbpsから最大100 Gbpsまで自動でスケールします。
- 従来のゾーナルNATゲートウェイは単一のアベイラビリティーゾーンで動作し、AZごとに作成して冗長化します。2025年11月に追加されたリージョナルNATゲートウェイは複数のAZへ自動的に拡張・縮小します。
- どちらの形態でも稼働時間と処理データ量に応じた課金が発生するため、導入すればその分の費用が上乗せされます。
アプライアンスの配置方式について
- シングルアーム方式は1つのインターフェイスで検査に専念し、インターネットへの送出は別のNAT手段に頼ります。
- デュアルアーム方式はプライベート側とパブリック側の2つのインターフェイスを持ち、製品が備えるNAT機能で自らインターネットへ送出できます。
アーキテクチャ図の解説
アーキテクチャ図
ファイアウォールアプライアンスを2つのインターフェイスで挟む「デュアルアーム」構成にすると、アプライアンス内蔵のNAT機能をそのまま使えます。トラフィックはプライベートサブネット側からGateway Load Balancerを経由してアプライアンスへ入り、検査後にパブリックサブネット側のインターフェイスからNATされてインターネットへ出ます。パブリック側がNATを担うため、別途NATゲートウェイを置く必要がありません。ファイアウォールはもともと必要なコンポーネントなので、その機能を余すことなく使うことがコスト効率につながります。仮にプライベート側のインターフェイスだけにしてしまうと、NATを別のサービスで補う必要が生じ、稼働時間とデータ量に応じた追加料金が発生します。
アーキテクチャ図
アプライアンスを単一インターフェイスの「シングルアーム」構成にすると、NATを外部のNATゲートウェイで別途用意しなければなりません。トラフィックはGateway Load Balancerからアプライアンスへ入って検査されますが、アプライアンスは検査だけを担い、インターネットへの送出はパブリックサブネットのNATゲートウェイが受け持ちます。この構成自体は成立しますが、NATゲートウェイには時間単位と処理データ量に応じた料金がかかるため、デュアルアーム構成に比べて運用コストが増えます。同じ検査機能を実現するなら、アプライアンスの内蔵NATを使えるデュアルアームの方が、追加のマネージドサービスに料金を払わずに済む分だけコスト効率に優れます。
解くための考え方
判断軸は「ロードバランサーの種類」と「NATをどこで実現するか」の2つです。まずロードバランサーを選びます。サードパーティ製ファイアウォールによる集中検査では、ルートテーブルの次ホップにエンドポイントを指定して通信を強制的に迂回させ、パケットを元の姿のままアプライアンスへ渡し、往復を同じアプライアンスへ届ける必要があります。この動作を担うのがGENEVEカプセル化とフロー対称性を備えたGateway Load Balancerです。Network Load Balancerはレイヤー4のプロキシ型負荷分散であり、宛先が自身になるためアプライアンスを透過的に挟み込む用途には合いません。この時点でNetwork Load Balancerを使う2案は外れます。次に残った2案をNATの実現方法で比較します。アプライアンスをプライベートサブネットの単一インターフェイスで配置するシングルアーム方式では、検査後の通信をインターネットへ出すためにNATゲートウェイを別途用意することになり、稼働時間と処理データ量に応じた費用が上乗せされます。一方、プライベート側とパブリック側の2つのインターフェイスを持つデュアルアーム方式なら、ファイアウォール製品が備えるNAT機能をそのまま使えます。ファイアウォールはもともと導入が決まっているコンポーネントなので、その機能を活用すれば追加のマネージドサービスを増やさずに済みます。要件の「最もコスト効率が高い」を満たすのは後者であり、Gateway Load Balancerとデュアルアーム構成の組み合わせが正解になります。
参考資料
問題文：
大手ECサイト運営企業が、顧客向けのショッピングプラットフォームをAWS上で運用しています。その構成は複数のVPCに分かれており、共有サービスVPCと複数のアプリケーションVPCが含まれます。同社はすべてのVPCから、オンプレミスデータセンターの社内DNSサーバーへのネットワーク接続をすでに確立しています。アプリケーションVPCにデプロイされたアプリケーションには、オンプレミスでホストされている内部ドメイン（shop.internal）を解決できることが必要です。あわせて、ローカルVPCドメイン名とAmazon Route 53プライベートホストゾーンでホストされているドメインも解決できる必要があります。これらの要件を満たすために、ネットワーク運用チームは何をすべきでしょうか。
選択肢：
A. 共有サービスVPCにRoute 53 Resolver インバウンドエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。さらに各アプリケーションVPCのDHCPオプションセットを更新して、DNS解決が新しいResolverエンドポイントを指すようにします。
B. 共有サービスVPCに、アウトバウンド用のRoute 53 Resolverエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。
C. 共有サービスVPCにRoute 53 Resolver アウトバウンドエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。さらに各アプリケーションVPCのDHCPオプションセットを更新して、DNS解決が新しいResolverエンドポイントを指すようにします。
D. 共有サービスVPCに、インバウンド用のRoute 53 Resolverエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。
正解：B
A. 共有サービスVPCにRoute 53 Resolver インバウンドエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。さらに各アプリケーションVPCのDHCPオプションセットを更新して、DNS解決が新しいResolverエンドポイントを指すようにします。
不正解 インバウンドエンドポイントはオンプレミス側からAWS内のDNS名を解決するためのもので、AWS内からオンプレミスのDNS名を解決する今回の要件とは方向が逆です。さらにDHCPオプションセットを変更してAmazonProvidedDNS以外を指定すると、ローカルVPCドメイン名やRoute 53プライベートホストゾーンの名前解決ができなくなり、要件を満たせません。
B. 共有サービスVPCに、アウトバウンド用のRoute 53 Resolverエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。
正解 アウトバウンドエンドポイントはAWS内からオンプレミスのDNS名を解決するためのもので、要件の方向に合っています。`shop.internal`向けの転送ルールを作成して各アプリケーションVPCに関連付けることで、AmazonProvidedDNSによる解決を維持したまま、オンプレミスドメインだけを社内DNSサーバーへ転送できます。これにより、ローカルVPCドメイン名とRoute 53プライベートホストゾーンの解決も引き続き機能します。
C. 共有サービスVPCにRoute 53 Resolver アウトバウンドエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。さらに各アプリケーションVPCのDHCPオプションセットを更新して、DNS解決が新しいResolverエンドポイントを指すようにします。
不正解 アウトバウンドエンドポイントの選択自体は正しい方向ですが、DHCPオプションセットを変更してResolverエンドポイントを指すよう設定すると、AmazonProvidedDNSによる解決が失われ、ローカルVPCドメイン名やRoute 53プライベートホストゾーンを正しく解決できなくなります。Route 53 Resolverは転送ルールに基づいてクエリを自動で振り分けるため、DHCPオプションセットの変更は不要です。
D. 共有サービスVPCに、インバウンド用のRoute 53 Resolverエンドポイントを新しく作成します。shop.internal向けの転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。
不正解 インバウンドエンドポイントは、オンプレミスのDNSサーバーから転送されてきたクエリを受け取り、VPCのプライベートホストゾーンなどAWS内の名前を解決させるためのものです。今回必要なのはアプリケーションVPCからオンプレミスの`shop.internal`を引く逆方向であり、DHCPオプションセットを変更しない点は妥当でも、エンドポイントの種類が要件と合わないため名前解決は成立しません。
全体的な説明
問われている要件
- 複数のアプリケーションVPCから、オンプレミスの内部ドメイン（shop.internal）を解決できること
- ローカルVPCドメイン名の解決を引き続き利用できること
- Route 53プライベートホストゾーンのドメイン解決を引き続き利用できること
- オンプレミスへのネットワーク接続は確立済みという前提を活かすこと
- 複数VPCに対して一元的に管理でき、VPCごとの重複した構築を避けられること
前提知識
Route 53 Resolverについて
- 各VPCにはVPCのCIDRの先頭から2番目のアドレス（VPC+2）で応答するResolverが用意され、EC2インスタンスの既定のDNSサーバーになります。
- インバウンドエンドポイントは、オンプレミスなどVPCの外からAWS内の名前を解決させたいときに使います。
- アウトバウンドエンドポイントは、VPC内のリソースが外部のDNSサーバーの名前を解決したいときに使い、転送ルールと組み合わせます。
- エンドポイントは異なるアベイラビリティーゾーンの2つ以上のIPアドレスで構成し、IPアドレスあたり毎秒約10,000クエリを処理できます。
転送ルールについて
- 転送ルールはドメイン名と転送先DNSサーバーのIPアドレス、経由するアウトバウンドエンドポイントを指定して作成します。
- ルールをVPCに関連付けると、そのVPCのResolverは該当ドメインのクエリだけを転送先へ送り、それ以外は通常どおり自身で解決します。
- 1つのルールを複数のVPCに関連付けられ、AWS Resource Access Managerを使えば他アカウントのVPCとも共有できます。
DHCPオプションセットについて
- 既定のAmazonProvidedDNSは、ローカルVPCドメイン名、Route 53プライベートホストゾーン、AWSのパブリックエンドポイントを解決します。
- ドメインネームサーバーを独自のDNSサーバーへ変更すると、VPC+2のResolverが使われなくなるため、AWS内の名前解決や転送ルールの適用を自前で補う必要が生じます。
解くための考え方
判断軸は「名前解決の向き」と「AmazonProvidedDNSを維持できるか」の2つで、選択肢はこの2軸の組み合わせになっています。まず向きを確認します。今回解決したいのはオンプレミスでホストされているshop.internalであり、クエリはアプリケーションVPCからオンプレミスへ向かいます。この方向を担うのはアウトバウンドエンドポイントと転送ルールです。インバウンドエンドポイントはオンプレミスのDNSサーバーからAWS内の名前を引かせるための入口なので、これを選ぶ2案は要件と逆になり成立しません。次にAmazonProvidedDNSの扱いを見ます。要件にはローカルVPCドメイン名とRoute 53プライベートホストゾーンの解決を維持することが含まれています。VPC+2のResolverは、関連付けられた転送ルールに一致するドメインだけを外部へ転送し、それ以外のクエリは自身で解決するという振り分けを自動的に行います。したがって追加の設定は不要で、むしろDHCPオプションセットを書き換えてResolverエンドポイントのIPアドレスを直接指定してしまうと、この振り分けの入口であるVPC+2が使われなくなり、AWS内の名前解決まで失われます。この観点でDHCPオプションセットを変更する案は除外されます。最後に運用面として、共有サービスVPCにエンドポイントを1つ置き、そのルールを各アプリケーションVPCへ関連付ける構成にすれば、VPCごとにエンドポイントを作らずに済み、管理も一元化できます。
アーキテクチャ図の解説
アーキテクチャ図
共有サービスVPCに置いたアウトバウンドエンドポイントが、各アプリケーションVPCのリゾルバーから社内DNSサーバーへの転送を一括で担うハブになります。アプリケーションVPC内のEC2インスタンスは、まず自VPCのResolver（VPC+2）へ名前解決を要求し（①）、それがshop.internalへのクエリと判断すると共有サービスVPCのアウトバウンドエンドポイントへ転送します（②③）。転送ルールを各アプリケーションVPCに関連付けるだけで、アプリケーションVPCは自前のエンドポイントを持たずにオンプレミスドメインを解決できるようになります。一方、DHCPオプションセットを書き換えてVPC+2を別のDNSサーバーに差し替えると、条件付き転送が機能しなくなり、ローカルVPCドメイン名やRoute 53プライベートホストゾーンの解決も失われます。
参考資料
問題文：
ある動画配信サービス運営企業が、長年使ってきた旧来のアプリケーション層プロトコルを廃止し、すべてのアプリケーションを新しいプロトコルへ移行することにしました。旧プロトコルはTCPポート8000番、新プロトコルはTCPポート8080番を使用しており、どちらもTCPベースです。数か月にわたる移行作業の後、同社はAmazon EC2インスタンスやコンテナで動く多数のアプリケーションを移行し終えました。同社はすべてのアプリケーションが移行済みだと考えていますが、この判断を裏付けるため、ネットワーク運用チームがどのアプリケーションも旧プロトコル（8000番ポート）をまだ使っていないことを確認する必要があります。ダウンタイムを発生させずにこれらの要件を満たすソリューションはどれですか。
選択肢：
A. Amazon VPC Reachability Analyzerを実行し、まだ8000番ポートをリッスンしているインスタンスを特定します。
B. Amazon GuardDutyを有効にしてトラフィックを監視し、8000番ポートを使う通信を検出します。
C. VPCフローログをAmazon S3バケットへ配信するように設定します。Amazon Athenaでデータをクエリし、旧プロトコルが使う8000番ポートをフィルタリングします。
D. アプリケーションをホストするEC2インスタンスに割り当てられたすべてのセキュリティグループを確認し、8000番ポートが許可リストに含まれていればそのルールを削除します。削除後、アプリケーションが正常に動作することを確認します。
正解：C
A. Amazon VPC Reachability Analyzerを実行し、まだ8000番ポートをリッスンしているインスタンスを特定します。
不正解 Reachability Analyzerは、指定した送信元と宛先の組み合わせについて、セキュリティグループやネットワークACL、ルートテーブルといった設定から到達可能かどうかを静的に判定するツールです。到達できる経路があることは示せますが、実際にどの通信が流れたかという実績は扱わないため、8000番ポートを今も使っているアプリケーションが残っているかどうかの確認には使えません。
B. Amazon GuardDutyを有効にしてトラフィックを監視し、8000番ポートを使う通信を検出します。
不正解 GuardDutyはVPCフローログやDNSログ、CloudTrailイベントなどを解析して不審な挙動を検出する脅威検知サービスであり、findingsとして通知されるのは既知の攻撃パターンや異常な振る舞いです。特定のポート番号を使う正常な通信を一覧化する用途は想定されておらず、任意の条件でトラフィックを集計・検索する手段も提供されないため、移行完了の裏付けには使えません。
C. VPCフローログをAmazon S3バケットへ配信するように設定します。Amazon Athenaでデータをクエリし、旧プロトコルが使う8000番ポートをフィルタリングします。
正解 VPCフローログはネットワークインターフェイスを通過するIPトラフィックのメタデータを記録し、送信元・宛先のポート番号を含む形でS3バケットへ配信できます。保存したログをAmazon AthenaのSQLで検索すれば、8000番ポートを使う通信が残っているかを網羅的に絞り込めます。エージェントの導入も通信経路の変更も不要なためダウンタイムが発生せず、有効化後は記録が蓄積されるので、たまにしか動かないアプリケーションも一定期間観測すれば把握できます。
D. アプリケーションをホストするEC2インスタンスに割り当てられたすべてのセキュリティグループを確認し、8000番ポートが許可リストに含まれていればそのルールを削除します。削除後、アプリケーションが正常に動作することを確認します。
不正解 セキュリティグループから8000番ポートの許可ルールを削除すると、まだ旧プロトコルを使っているアプリケーションが残っていた場合にその通信が即座に遮断され、ダウンタイムを招きます。しかもこれは通信実績を確認する作業ではなく、止めてみて障害が起きるかどうかで判断する方法であり、移行が完了していることを裏付ける検証にはなりません。
全体的な説明
問われている要件
- 稼働中のアプリケーションを止めず、ダウンタイムを発生させないこと
- EC2インスタンスやコンテナを含む多数のアプリケーションを網羅的に確認すること
- 旧プロトコルが使うTCP 8000番の通信が残っていないことを実際の通信実績で裏付けること
- 断続的にしか動かないアプリケーションの通信も取りこぼさないこと
前提知識
VPCフローログについて
- ネットワークインターフェイスを通過するIPトラフィックの情報を記録する機能で、VPC単位、サブネット単位、ネットワークインターフェイス単位で有効化できます。
- 既定のフィールドには送信元・宛先のIPアドレスとポート番号、プロトコル番号、パケット数、バイト数、ACCEPTまたはREJECTのアクション、開始・終了時刻が含まれます。
- 集約間隔は10分または1分から選び、Amazon S3、CloudWatch Logs、Amazon Data Firehoseへ配信できます。
- 記録されるのはメタデータでパケットの中身は含まれません。中身まで見る必要がある場合はトラフィックミラーリングを使います。
- 有効化した時点以降のトラフィックが対象で、有効化前にさかのぼって記録することはできません。また、インスタンスメタデータサービス宛やAmazon DNSサーバー宛など、記録対象外のトラフィックがあります。
Amazon Athenaについて
- S3に置いたデータへ標準SQLを直接実行できるサーバーレスのクエリサービスで、事前のデータロードやサーバー管理が不要です。
- VPCフローログ用のテーブル定義が公式ドキュメントに用意されており、日付でパーティションを切ると検索対象を絞れます。
その他の確認手段について
- Reachability Analyzerは設定に基づく到達性の静的な分析で、通信実績を扱う機能ではありません。
- GuardDutyはフローログやDNSログなどから脅威を検出するサービスで、任意条件でのトラフィック集計には向きません。
- セキュリティグループのルール削除は設定変更そのものであり、残存する通信を遮断してダウンタイムを招く恐れがあります。
解くための考え方
要件を「ダウンタイムを出さないこと」と「実際に流れた通信で裏付けること」に分解すると、候補は素早く絞れます。まずセキュリティグループから8000番ポートの許可を外して様子を見る案は、旧プロトコルを使うアプリケーションが残っていた場合にその通信を即座に遮断してしまい、ダウンタイムを出さないという条件に真正面から反します。加えて、これは移行済みであることを確かめる作業ではなく、通信を止めて障害の有無で判断する乱暴な確認になり、検証方法としても適切ではありません。次に残る案を「設定を見るのか、実績を見るのか」で分けます。Reachability Analyzerは設定から到達可能性を導く静的解析であり、経路が開いていることは分かっても、そこを通って8000番ポートの通信が実際に行われたかは分かりません。GuardDutyは脅威検知に特化しており、正常な通信を任意の条件で集計して一覧化する用途には向きません。残るVPCフローログは、ネットワークインターフェイスを通過した通信のメタデータをポート番号付きで記録し、S3へ配信したログをAthenaのSQLで検索できます。有効化しても通信経路は変わらず、エージェントの導入も不要なので稼働中のアプリケーションに影響しません。フローログは有効化した時点からの記録になるため、さかのぼって過去を調べることはできませんが、しばらく記録を蓄積してから検索すれば、月次バッチのようにたまにしか動かない通信も観測できます。この点で要件を最もよく満たすのが、VPCフローログとAthenaの組み合わせです。
アーキテクチャ図の解説
アーキテクチャ図
実際に流れたトラフィックの記録と、その後のクエリによる絞り込みという2段階で検証します。VPC内のEC2インスタンスやコンテナが送受信する通信は、VPCフローログによって送信元・宛先のIPアドレスとポート番号、プロトコルなどのメタデータとしてS3バケットへ配信されます。このデータに対してAmazon AthenaがSQLでクエリを実行し、8000番ポートを使う通信の有無を洗い出します。フローログの有効化は既存の通信を止めないため、ダウンタイムは発生しません。一方、Reachability Analyzerのような設定ベースの検査では実際の通信実績が分からず、セキュリティグループからポートを削除する方法では稼働中の通信を遮断する恐れがあるため、検証手段としては不適切です。
参考資料
スポンサーリンク
以下スポンサーリンクです。
この記事がお役に立ちましたら、コーヒー1杯分（300円）の応援をいただけると嬉しいです。いただいた支援は、より良い記事作成のための時間確保や情報収集に活用させていただきます。