【無料】AWS ANS-C01練習問題15問｜図解解説付き｜Udemy講師作成

正解：C

A. 新しいNetwork Load Balancer（NLB）を作成します。ALBをNLBのターゲットとして追加します。

不正解 Network Load Balancer（NLB）をALBの前に配置することはできますが、これだけでは世界中のクライアントからの最小レイテンシーアクセスという要件を満たしません。NLBは単一のリージョン内で動作し、グローバルルーティングの最適化は提供しません。また、NLBは固定IPアドレスを提供しますが、リージョンごとに異なるIPアドレスが必要になるため、世界中の多数のオフィスからアクセスする場合、それぞれのファイアウォールで多くのIPアドレスを許可リストに追加する必要があります。

B. 新しいAmazon CloudFrontディストリビューションを作成します。ALBをディストリビューションのオリジンとして設定します。

不正解 Amazon CloudFrontはコンテンツ配信ネットワーク（CDN）サービスで、静的コンテンツを世界中のエッジロケーションにキャッシュして低レイテンシーで提供する目的で設計されています。しかし、動的なWebアプリケーションの場合、キャッシュの効果は限定的です。また、CloudFrontは動的に多数のIPアドレス範囲を使用するため、企業のファイアウォールでこれらすべてのIPアドレスを許可リストに追加する必要があり、「承認済みIPアドレスへのアウトバウンドトラフィックのみを許可する」という要件を満たすのが困難になります。

C. AWS Global Acceleratorに新しいアクセラレーターを作成します。ALBをアクセラレーターのエンドポイントとして追加します。

正解 AWS Global Acceleratorは、AWS グローバルネットワークを使用してユーザーとアプリケーション間のパフォーマンスを向上させるサービスです。Global Acceleratorは2つの固定エニーキャストIPアドレスを提供し、これらのIPを企業のファイアウォールで許可リストに追加するだけで済みます。トラフィックは最も近いAWSエッジロケーションにルーティングされ、AWSのプライベートネットワークを通じてアプリケーションに転送されるため、インターネット経由よりも低レイテンシーでアクセスできます。これにより、「最小限のレイテンシー」と「承認済みIPアドレスへのアウトバウンドトラフィックのみを許可する」という両方の要件を満たします。

D. 新しいAmazon Route 53ホストゾーンを作成します。トラフィックをALBにルーティングする新しいレコードを作成します。

不正解 Amazon Route 53はDNSサービスであり、ドメイン名をIPアドレスに解決する役割を果たします。ホストゾーンとレコードを作成するだけでは、レイテンシーの低減にはつながりません。また、ALBには複数のIPアドレスが動的に割り当てられる可能性があり、これらすべてをファイアウォールで許可リストに追加する必要があります。これは「承認済みIPアドレスへのアウトバウンドトラフィックのみを許可する」という要件を満たすのが困難です。

問われている要件

この問題では、以下の要件を満たすソリューションを選ぶ必要があります：

1. 企業顧客のファイアウォールで承認済みIPアドレスへのアウトバウンドトラフィックのみを許可できるようにする
2. 世界中の企業顧客の従業員が最小限のレイテンシーでアプリケーションにアクセスできるようにする

前提知識

AWS Global Accelerator

AWS Global Acceleratorは、アプリケーションのグローバルトラフィックを最適化するサービスです。主な機能と特徴は以下の通りです：

• 固定IPアドレス: 2つの固定エニーキャストIPアドレスを提供
• エッジロケーション: 世界中のAWSエッジロケーションからアクセス可能
• AWSグローバルネットワーク: インターネットよりも信頼性が高く、レイテンシーの低いAWSのプライベートネットワークを使用
• ヘルスチェック: エンドポイントの健全性を継続的に監視
• フェイルオーバー: 異常なエンドポイントから正常なエンドポイントへ迅速に切り替え
• トラフィック分散: トラフィックダイヤルとエンドポイントの重みによるトラフィック制御

Amazon CloudFront

Amazon CloudFrontはコンテンツ配信ネットワーク（CDN）サービスです。主な機能と特徴は以下の通りです：

• コンテンツキャッシュ: 静的コンテンツと動的コンテンツをキャッシュして配信
• エッジロケーション: 世界中のエッジロケーションでコンテンツを配信
• オリジン: S3バケット、EC2インスタンス、ELB、カスタムオリジンなどをサポート
• セキュリティ: HTTPS、フィールドレベル暗号化、AWS WAFとの統合などをサポート
• 動的コンテンツ: 動的コンテンツもエッジロケーションから配信可能（キャッシュなし）

IP許可リストの課題

企業のファイアウォールで特定のIPアドレスのみを許可リストに追加する場合、以下の課題があります：

• ALB/NLB: 複数のIPアドレスが動的に割り当てられ、変更される可能性がある
• CloudFront: 多数のIPアドレス範囲を使用し、定期的に変更される
• Global Accelerator: 2つの固定IPアドレスのみを使用するため、管理が容易

レイテンシー最適化

グローバルユーザーのレイテンシーを最適化するには、以下の方法があります：

• エッジロケーション: ユーザーに近いロケーションからコンテンツを配信
• ネットワークパス最適化: 最適なネットワークパスを使用してトラフィックをルーティング
• プライベートバックボーン: インターネットよりも高速で信頼性の高いプライベートネットワークを使用

解くための考え方

この問題を解くには、以下のポイントを考慮する必要があります：

1. IPアドレスの管理:
   • ファイアウォールで「承認済みIPアドレスへのアウトバウンドトラフィックのみを許可する」必要がある
   • 管理の容易さから、少数の固定IPアドレスが望ましい
2. グローバルアクセスとレイテンシー:
   • 世界中の企業顧客がアクセスする
   • 最小限のレイテンシーが必要
3. アプリケーションの特性:
   • HTTPS経由のWebアプリケーション
   • 動的なコンテンツが含まれる可能性が高い

これらの要件を考慮すると、AWS Global Acceleratorが最適なソリューションとなります。Global Acceleratorは2つの固定エニーキャストIPアドレスを提供し、これらのIPアドレスをファイアウォールの許可リストに追加するだけで済みます。また、ユーザーからの接続は最寄りのAWSエッジロケーションで受け入れられ、AWSのプライベートネットワークを経由してアプリケーションに転送されるため、レイテンシーが低減されます。

上の図は、AWS Global Acceleratorを使用したアーキテクチャを示しています。Global Acceleratorは2つの固定エニーキャストIPアドレスを提供し、企業の従業員は最寄りのAWSエッジロケーションに接続します。トラフィックはAWSのプライベートネットワークを経由してApplication Load Balancerに転送され、そこからAuto Scalingグループ内のEC2インスタンスに分散されます。

このアーキテクチャにより、企業のファイアウォールではGlobal Acceleratorの2つの固定IPアドレスのみを許可リストに追加すれば良く、世界中の従業員は最寄りのエッジロケーションから低レイテンシーでアプリケーションにアクセスできます。

参考資料

• AWS Global Accelerator とは
• AWS Global Accelerator の仕組み
• CloudFront IP アドレス範囲
• Elastic Load Balancing の種類

正解：D

A. リソースがある各リージョンにaws.example.comのAmazon Route 53プライベートホストゾーンを作成します。プライベートホストゾーンをそのリージョンのVPCに関連付けます。適切なプライベートホストゾーンで、各リージョンのリソースのDNSレコードを作成します。

不正解 各リージョンに個別のプライベートホストゾーンを作成することは管理上の負担が増し、一貫性を維持するのが難しくなります。また、リソースが複数のリージョンにまたがる場合、特定のリージョンのVPCからは他のリージョンのリソースを解決できない可能性があります。これは、各プライベートホストゾーンがそのリージョンのVPCにのみ関連付けられているためです。統一されたDNSサフィックスでリソースに一貫してアクセスするという要件を満たすためには、すべてのVPCが同じプライベートホストゾーンを共有するべきです。

B. aws.example.comのAmazon Route 53プライベートホストゾーンを1つ作成します。すべてのVPCとのゾーン転送を許可するようにプライベートホストゾーンを構成します。

不正解 Route 53のプライベートホストゾーンはゾーン転送をサポートしていません。ゾーン転送は、DNSサーバー間で DNS ゾーンファイルをコピーするための仕組みですが、Route 53のプライベートホストゾーンでは、VPCとの関連付けによってDNSの可視性を制御します。この選択肢は技術的に実装不可能です。

C. example.comのAmazon Route 53プライベートホストゾーンを1つ作成します。プライベートホストゾーンにaws.example.comの単一のリソースレコードを作成します。レコードにマルチバリューアンサールーティングポリシーを適用します。ルーティングポリシーに、すべてのVPCリソースを個別の値として追加します。

不正解 この方法では、aws.example.comに対する単一のDNSレコードを作成し、マルチバリューアンサールーティングポリシーを使用して複数のリソースを指定しています。しかし、この方法ではaws.example.comをDNSサフィックスとして使用することはできません。DNSサフィックスの実装には、複数の個別のリソースレコードを持つプライベートホストゾーンが必要です。また、マルチバリューアンサールーティングポリシーは複数のIPアドレスを持つ単一のレコードに対して機能しますが、異なる名前を持つ複数のリソースに対しては機能しません。

D. aws.example.comのAmazon Route 53プライベートホストゾーンを1つ作成します。プライベートホストゾーンをリソースを持つすべてのVPCに関連付けます。プライベートホストゾーンに、すべてのリソースのDNSレコードを作成します。

正解 aws.example.comのプライベートホストゾーンを1つ作成し、それをすべてのVPCに関連付けることで、すべてのVPCからこのホストゾーンのDNSレコードを解決できるようになります。プライベートホストゾーンは複数のVPCと関連付けることができ、リージョンをまたいで使用することも可能です。これにより、一貫したDNS解決が提供され、すべてのリソースがaws.example.comのサフィックスで解決できるようになります。各リソースの個別のDNSレコードをこのホストゾーン内に作成することで、特定のリソース名を持つFQDN（完全修飾ドメイン名）にアクセスできます。

問われている要件

この問題では、以下の要件を満たすソリューションを選ぶ必要があります：

1. 複数のAWSリージョンにまたがるVPC内のリソースにaws.example.comのDNSサフィックスを適用すること
2. 内部ドメイン名を使用してこれらのリソースに接続できること

前提知識

Amazon Route 53のプライベートホストゾーン

Amazon Route 53のプライベートホストゾーンは、VPC内のDNSクエリに応答するために使用されるDNSゾーンです。プライベートホストゾーンの主な特徴は以下のとおりです：

• VPCとの関連付け: プライベートホストゾーンは1つ以上のVPCに関連付けることができます
• 限定的な可視性: 関連付けられたVPC内からのみDNSレコードを解決できます
• クロスリージョン対応: 異なるリージョンのVPCと関連付けることができます
• ゾーン転送非対応: 従来のDNSのゾーン転送はサポートしていません
• リソースレコード: ホストゾーン内に複数のリソースレコードを作成できます

DNSサフィックス

DNSサフィックスは、短縮名（非修飾ドメイン名）を完全修飾ドメイン名（FQDN）に変換するために使用されるドメイン名の一部です。例えば、DNSサフィックスが「aws.example.com」に設定されている場合、「server1」というリソースは「server1.aws.example.com」として解決されます。DNSサフィックスの主な特徴は以下のとおりです：

• 名前解決の簡素化: 短い名前でリソースにアクセスできるようになります
• ドメイン階層: 組織の構造を反映した階層的なドメイン名を使用できます
• DNS検索リスト: クライアントのDNS設定で検索リストとして設定されることが多いです

クロスリージョンDNS解決

AWS環境でクロスリージョンのDNS解決を実現するための主な方法は以下のとおりです：

• 単一のプライベートホストゾーン: 1つのプライベートホストゾーンを複数のリージョンのVPCに関連付ける
• Route 53 Resolver: クロスリージョンのDNSクエリを転送するためのエンドポイントとルールを設定する
• プライベートVPC接続: VPCピアリングやTransit Gatewayを使用して、VPC間のプライベート接続を確立する

解くための考え方

この問題を解くためには、以下のポイントを考慮する必要があります：

1. 単一のネームスペース: すべてのリソースに一貫したDNSサフィックス（aws.example.com）を適用するためには、単一のDNSネームスペースが必要です。
2. クロスリージョンのアクセス: 複数のリージョンにまたがるリソースにアクセスできる必要があるため、異なるリージョンのVPC間でDNS解決をサポートするソリューションが必要です。
3. 管理の容易さ: 単一のプライベートホストゾーンを管理する方が、複数のホストゾーンを管理するよりも簡単です。
4. 技術的制約: Route 53のプライベートホストゾーンはゾーン転送をサポートしていないため、VPCとの関連付けを使用する必要があります。

aws.example.comの単一のプライベートホストゾーンを作成し、それをすべてのVPCに関連付けることで、一貫したDNS解決を提供し、すべてのリソースがaws.example.comのサフィックスで解決できるようになります。

上の図は、複数のリージョンにまたがるVPCに単一のRoute 53プライベートホストゾーンを関連付ける構成を示しています。この構成では、aws.example.comの単一のプライベートホストゾーンが作成され、異なるリージョンの複数のVPCに関連付けられています。各リソース（EC2インスタンスやRDSインスタンスなど）に対して、プライベートホストゾーン内にDNSレコードが作成されています。

この構成により、どのVPCからでも同じDNS名を使用してリソースにアクセスできるようになります。例えば、リージョンAのVPC内のインスタンスからdb1.aws.example.comを解決すると、リージョンBのRDSインスタンスのIPアドレスが返されます。これにより、リソースの場所に関係なく、一貫した内部ドメイン名を使用してリソースにアクセスできるようになります。

参考資料

• Amazon Route 53 での VPC にまたがるプライベートホストゾーンの使用
• Route 53 Resolver とは
• Amazon Route 53 でのレコードの使用
• VPC と関連付ける既存のプライベートホストゾーンの使用

正解：A

A. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにAmazon Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントのセットを作成します。オンプレミスドメインのリクエストをオンプレミスDNSリゾルバーに転送するRoute 53 Resolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access Managerを使用してRoute 53 Resolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを構成して、クラウドドメインをRoute 53インバウンドエンドポイントに転送します。

正解 この選択肢は、AWS環境とオンプレミス環境間の双方向DNS解決を正しく構成しています。各アプリケーションVPCにプライベートホストゾーンを設定し、イグレスVPCにRoute 53 Resolverのインバウンド/アウトバウンドエンドポイントを設置します。プライベートホストゾーンはイグレスVPCに関連付けられ、Resolverルールはアプリケーションアカウントと共有されます。また、オンプレミスDNSサーバーはクラウドドメインに対するリクエストをRoute 53インバウンドエンドポイント（正しい方向）に転送するよう構成されています。

B. 各アプリケーションVPCのパブリックホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにAmazon Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントのセットを作成します。オンプレミスドメインのリクエストをオンプレミスDNSリゾルバーに転送するRoute 53 Resolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access Managerを使用してRoute 53 Resolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを構成して、クラウドドメインをRoute 53インバウンドエンドポイントに転送します。

不正解 この選択肢では、パブリックホストゾーンを使用していますが、これはインターネット経由のDNS解決に適しており、プライベートネットワーク間のDNS解決には適していません。また、本来はプライベートなワークロードに関するDNSレコードがインターネット上に公開されることになり、セキュリティ上の問題が生じる可能性があります。ホストゾーンの種類以外は正解の選択肢と同じ構成になっています。

C. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにAmazon Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントのセットを作成します。オンプレミスドメインのリクエストをオンプレミスDNSリゾルバーに転送するRoute 53 Resolverルールを定義します。アプリケーションVPCのプライベートホストゾーンをイグレスVPCに関連付け、AWS Resource Access Managerを使用してRoute 53 Resolverルールをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを構成して、クラウドドメインをRoute 53アウトバウンドエンドポイントに転送します。

不正解 この選択肢のほとんどは正解の選択肢と同じですが、オンプレミスDNSサーバーがクラウドドメインをRoute 53アウトバウンドエンドポイントに転送するように構成されている点が異なります。これは誤りです。アウトバウンドエンドポイントはAWS内からオンプレミスへのクエリを送信するためのものであり、オンプレミスからのクエリを受信するためのものではありません。オンプレミスからのクエリを受信するには、インバウンドエンドポイントを使用する必要があります。

D. 各アプリケーションVPCのプライベートホストゾーンを構成し、必要なレコードを作成します。イグレスVPCにAmazon Route 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントのセットを作成します。オンプレミスドメインのリクエストをオンプレミスDNSリゾルバーに転送するRoute 53 Resolverルールを定義します。Route 53アウトバウンドルールをアプリケーションVPCに関連付け、AWS Resource Access Managerを使用してプライベートホストゾーンをアプリケーションアカウントと共有します。オンプレミスDNSサーバーを構成して、クラウドドメインをRoute 53インバウンドエンドポイントに転送します。

不正解 この選択肢では、プライベートホストゾーンをAWS RAMを使用して共有しようとしていますが、Route 53のプライベートホストゾーンはAWS RAMでは共有できません。また、「Route 53アウトバウンドルールをアプリケーションVPCに関連付け」という表現も不適切です。Route 53 Resolverルールはイグレスアカウントで定義し、AWS RAMを通じてアプリケーションアカウントと共有するのが正しいアプローチです。

問われている要件

この問題では、以下の要件を満たすソリューションを選ぶ必要があります：

1. AWS環境とオンプレミス環境間のエンドツーエンドドメイン名解決
2. 双方向のDNS解決（AWSからオンプレミス、およびオンプレミスからAWS）
3. 複数のVPCに移行されるワークロード
4. ワークロード間の相互依存関係（同時に移行されるわけではない）

前提知識

Amazon Route 53 Resolver

Amazon Route 53 Resolverは、AWSのDNSサービスで、VPC内のリソースからのDNSクエリを解決します。Route 53 Resolverには以下の主要構成要素があります：

• インバウンドエンドポイント: オンプレミスからAWS内のDNSレコードを解決するためのエントリポイント。オンプレミスDNSサーバーはAWS内のドメインに関するクエリをこのエンドポイントに転送します。
• アウトバウンドエンドポイント: AWS内からオンプレミスのDNSレコードを解決するためのエンドポイント。VPC内のリソースからのオンプレミスドメインに関するクエリはこのエンドポイントを通してオンプレミスDNSサーバーに転送されます。
• Resolverルール: 特定のドメインに対するDNSクエリをどのように処理するかを定義するルール。例えば、「example.onprem」ドメインへのクエリをオンプレミスDNSサーバーに転送するルールを設定できます。

プライベートホストゾーンとパブリックホストゾーン

Route 53には2種類のホストゾーンがあります：

• プライベートホストゾーン: 特定のVPCからのみアクセス可能なDNSレコードを含むホストゾーン。企業内のプライベートドメインに使用されます。
• パブリックホストゾーン: インターネット上でアクセス可能なDNSレコードを含むホストゾーン。パブリックに公開されるドメインに使用されます。

AWS Resource Access Manager (RAM)

AWS RAMは、AWSリソースを複数のAWSアカウントと共有するためのサービスです。Route 53 Resolverルールは共有可能ですが、プライベートホストゾーンはAWS RAMを通じて共有することはできません。

解くための考え方

この問題を解くためには、以下のポイントを考慮する必要があります：

1. 双方向DNS解決のアーキテクチャ:
   • AWSからオンプレミスへの解決: Route 53 ResolverのアウトバウンドエンドポイントとオンプレミスDNSサーバーへのフォワーディングルール
   • オンプレミスからAWSへの解決: Route 53 ResolverのインバウンドエンドポイントとオンプレミスDNSサーバーからのフォワーディング設定
2. 複数VPCへの展開:
   • 集中管理のためのイグレスVPC
   • 各アプリケーションVPCのDNS設定
   • リソース共有メカニズム
3. 共有可能なリソース:
   • Route 53 Resolverルールは AWS RAM で共有可能
   • プライベートホストゾーンはVPCとの関連付けを通じて「共有」（直接RAMで共有はできない）
4. 正しいエンドポイントの使用:
   • インバウンドエンドポイント: オンプレミスからAWSへのクエリ受信用
   • アウトバウンドエンドポイント: AWSからオンプレミスへのクエリ送信用

プライベートホストゾーンの使用、イグレスVPCとの関連付け、Resolverルールの共有、そして正しい方向のエンドポイント設定がされています。

上の図は、AWS環境とオンプレミス環境間の双方向DNS解決のアーキテクチャを示しています。この設計では、イグレスVPC内にRoute 53 Resolverのインバウンドエンドポイントとアウトバウンドエンドポイントを設置し、各アプリケーションVPCにはプライベートホストゾーンを構成しています。

オンプレミスからAWSへのDNS解決（図の上部フロー１～４）では、オンプレミスアプリケーションからのクエリがオンプレミスDNSサーバーを経由し、Route 53インバウンドエンドポイントに転送されます。クラウド内のDNSレコードが解決され、結果がオンプレミスに返されます。

AWSからオンプレミスへのDNS解決（図の下部フロー５～９）では、アプリケーションVPC内のリソースからのクエリがRoute 53 Resolverルールに基づいてアウトバウンドエンドポイントを経由し、オンプレミスDNSサーバーに転送されます。オンプレミスのDNSレコードが解決され、結果がAWS環境に返されます。

Resolverルールは AWS Resource Access Managerを通じてアプリケーションVPCと共有され、プライベートホストゾーンはイグレスVPCに関連付けられています。これにより、リソースが段階的に移行される場合でも、一貫したDNS解決が提供されます。

参考資料

• Route 53 Resolver とは
• Route 53 Resolver 転送ルールの管理
• プライベートホストゾーン
• AWS Resource Access Manager の使用方法

正解：A

A. 新しいSite-to-Site VPN接続を作成します。トランジットゲートウェイをターゲットゲートウェイとして設定します。新しいSite-to-Site VPN接続でアクセラレーションを有効にします。ロンドンオフィスのVPNデバイスを新しい接続の詳細で更新します。

正解 Site-to-Site VPN接続をトランジットゲートウェイに移行し、アクセラレーションを有効にすることは、レイテンシーを削減するための効果的な方法です。アクセラレーションを有効にすると、VPNトラフィックが最も近いAWSエッジロケーションを経由してルーティングされ、AWSのグローバルネットワークバックボーンを使用してターゲットリージョンに到達します。これにより、インターネット経由のルーティングよりも低レイテンシーのパスが提供されます。新しい接続を作成する必要があるのは、既存の接続に対してアクセラレーションを有効にできないためです。

B. 既存のSite-to-Site VPN接続を変更し、トランジットゲートウェイをターゲットゲートウェイとして設定します。既存のSite-to-Site VPN接続でアクセラレーションを有効にします。

不正解 既存のSite-to-Site VPN接続ではアクセラレーションの有効化や無効化を後から変更することはできません。AWS公式ドキュメントによると、アクセラレーションの設定を変更したい場合は、新しいVPN接続を作成する必要があります。

C. eu-west-2（ロンドン）リージョンに新しいトランジットゲートウェイを作成します。新しいトランジットゲートウェイと既存のトランジットゲートウェイをピアリングします。既存のSite-to-Site VPN接続を変更し、新しいトランジットゲートウェイをターゲットゲートウェイとして設定します。

不正解 不正解: 新しいトランジットゲートウェイをeu-west-2に作成しても、アプリケーションはus-east-1に存在するため、根本的なレイテンシー問題は解決しません。また、この解決策ではアクセラレーションの利点を活用していません。

D. Site-to-Site VPN接続をエンドポイントとする新しいAWS Global Accelerator標準アクセラレータを作成します。ロンドンオフィスのVPNデバイスを新しい接続の詳細で更新します。

不正解 不正解: AWS Global Acceleratorは一般的にウェブアプリケーションのエンドポイントアクセスの高速化に使われますが、直接Site-to-Site VPN接続のエンドポイントとして設定することはできません。VPN接続のアクセラレーションはGlobal Acceleratorとは異なるメカニズムを使用します。

問われている要件

この問題では、ロンドンオフィスからus-east-1リージョンで実行されているビジネスアプリケーションへの接続時のレイテンシーを低減する最適な方法を選択する必要があります。

ロンドン（ヨーロッパ）と米国東部の間には大西洋があり、地理的に離れているため、通常のインターネット経由の接続ではレイテンシーが高くなります。この問題を解決するための最適な方法を理解することが求められています。

前提知識

AWS Site-to-Site VPN接続

AWS Site-to-Site VPNは、お客様のネットワーク（オンプレミス環境など）とAWS VPC間の安全な接続を提供するサービスです。この接続は暗号化されたIPsecトンネルを使用し、インターネット経由でデータを安全に転送します。

Site-to-Site VPN接続には主に2つのタイプのゲートウェイが関連します：

1. バーチャルプライベートゲートウェイ（VGW）: VPCに接続される従来のVPNゲートウェイです。1つのVPCに関連付けられ、最大で10個のVPN接続をサポートします。
2. トランジットゲートウェイ（TGW）: より高度なネットワークハブで、複数のVPCやオンプレミスネットワークを相互接続できます。単一のTGWに多数のVPN接続を設定できるため、スケーラビリティが向上します。

Accelerated VPN

AWS Accelerated VPNは、AWS Global Acceleratorのテクノロジーを利用して、Site-to-Site VPN接続のパフォーマンスを向上させる機能です。通常のVPN接続では、トラフィックはパブリックインターネットを経由して送信されますが、アクセラレーテッドVPNではAWSのグローバルネットワークインフラストラクチャを利用します。

アクセラレーテッドVPNの主な特徴：

• トラフィックは最寄りのAWSエッジロケーションに入り、そこからAWSのプライベートネットワーク経由でターゲットリージョンに到達します
• インターネット経由よりも最適化されたルーティングが可能
• 特に地理的に離れた場所間での接続で大幅なレイテンシー低減が期待できる
• トランジットゲートウェイをターゲットとする場合にのみ設定可能
• 既存のVPN接続でアクセラレーションを有効化または無効化することはできない（新しい接続を作成する必要がある）
• アクセラレーションを有効にすると追加料金が発生する

トランジットゲートウェイ (TGW)

AWSトランジットゲートウェイは、複数のVPCやオンプレミスネットワークを相互接続するためのネットワークトランジットハブです。以下のような利点があります：

• 単一のゲートウェイで複数のVPC間接続を管理
• 複雑なピアリング関係を簡素化
• リージョン間のVPC接続をサポート（ピアリング機能を使用）
• 集中型のルーティングとセキュリティポリシーを適用可能
• 高いスループットと可用性

AWS Global Accelerator

AWS Global Acceleratorは、アプリケーションのグローバルなトラフィックを最適化するサービスです。エッジロケーションからAWSのバックボーンネットワークを使用してトラフィックをルーティングすることで、パフォーマンスを向上させます。ただし、このサービスは主にウェブアプリケーションやAPIエンドポイントのアクセス高速化に使われ、直接Site-to-Site VPN接続のエンドポイントには設定できません。

アクセラレーテッドVPN vs 通常のVPN接続

解くための考え方

ロンドンオフィスと米国東部リージョン間のレイテンシーを低減するには、地理的な距離による遅延を最小化する必要があります。この問題を解決するためには、以下のポイントを考慮します：

1. 現在の構成を理解する：
   • ロンドンオフィスはバーチャルプライベートゲートウェイ（VGW）を使用してVPC接続している
   • トランジットゲートウェイ（TGW）が構成されているが、VPN接続には使用されていない
   • 従業員はレイテンシーの問題を経験している
2. レイテンシー低減のための選択肢を評価する：
   • VPNアクセラレーションは長距離接続のレイテンシーを低減する良い方法
   • VPNアクセラレーションはTGWでのみ使用可能（VGWでは利用できない）
   • 既存のVPN接続ではアクセラレーション設定を後から変更できない
3. 最適な解決策を選択する：
   • VGWからTGWへの移行が必要
   • アクセラレーションを有効にした新しいVPN接続が必要
   • 既存の接続を変更するのではなく、新しい接続を作成する必要がある

現在の接続は通常のインターネット経由のVPN接続であり、ロンドンから米国東部へのトラフィックは混雑するパブリックインターネットを経由しています。アクセラレーテッドVPNを使用することで、トラフィックはロンドンに近いAWSエッジロケーションに入り、AWSのグローバルバックボーンネットワーク経由でus-east-1リージョンに到達します。

AWS公式ドキュメントによると、既存のVPN接続でアクセラレーションの設定を後から変更することはできません。また、アクセラレーテッドVPNはバーチャルプライベートゲートウェイではなく、トランジットゲートウェイをターゲットとする場合にのみ設定可能です。

新しいトランジットゲートウェイをeu-west-2に作成する解決策は、最終的にはアプリケーションがus-east-1にあるため効果が限定的です。また、AWS Global Acceleratorは直接Site-to-Site VPN接続のエンドポイントには設定できません。

したがって、最適な解決策は新しいSite-to-Site VPN接続を作成し、トランジットゲートウェイをターゲットとして設定し、アクセラレーションを有効にする方法です。これにより、ロンドンオフィスからus-east-1リージョンへの接続が最適化され、レイテンシーが低減されます。

参考資料

• AWS Site-to-Site VPNのアクセラレーテッドVPN
• AWSトランジットゲートウェイ
• AWS Site-to-Site VPNの設定方法
• AWS Site-to-Site VPN Amazon VPC Transit Gateway のアタッチメント
• AWS Global Acceleratorの概要

正解：C

A. カスタムパターンを持つAmazon EventBridge（Amazon CloudWatch Events）ルールを作成して、アカウントの変更を監視します。ルールを設定して、AWS Lambda関数を呼び出し、非準拠リソースを特定します。特定された変更でAmazon DynamoDBテーブルを更新します。

不正解 – Amazon EventBridgeを使用してリソース変更の監視は可能ですが、この方法ではリソースの過去の設定にアクセスするための履歴データを効果的に保存・管理する仕組みが十分ではありません。DynamoDBに変更を記録することは可能ですが、設定のバージョン管理や変更の詳細な追跡には追加の開発が必要となります。

B. Amazon CloudWatchログからカスタムメトリクスを作成します。メトリクスを使用してAWS Lambda関数を呼び出し、非準拠リソースを特定します。特定された変更でAmazon DynamoDBテーブルを更新します。

不正解 – CloudWatchログからカスタムメトリクスを作成し、Lambda関数で非準拠リソースを特定する方法は、変更監視に利用できますが、この方法も履歴設定の管理やコンプライアンス違反の自動修復の機能が限定的です。また、ネットワークリソースの設定変更の詳細な情報をログから収集するのは複雑になる可能性があります。

C. AWS Configを使用してネットワークリソースの現在の状態を記録します。希望する設定を反映するルールを作成します。非準拠リソースの修復を設定します。

正解 – AWS Configはリソース設定の変更を追跡し、設定の履歴を記録するために設計されたサービスです。Config Rulesを使用して設定の準拠状況を評価し、非準拠リソースの自動修復を設定できます。また、設定の履歴にアクセスして、特定の時点でのリソース状態を確認することが可能です。これにより、変更監視、コンプライアンス確保、過去の設定へのアクセスという全ての要件を満たします。

D. AWS Systems Manager Inventoryを使用してネットワークリソースの現在の状態を記録します。Systems Manager State Managerを使用して、希望する設定設定を強制し、非準拠リソースの修復を実行します。

不正解 – AWS Systems Manager InventoryはEC2インスタンスやオンプレミスサーバーの管理に適していますが、VPCやサブネット、セキュリティグループなどのネットワークリソースの設定管理には十分ではありません。また、State Managerは主にサーバーの設定管理に使用され、ネットワークリソースの管理には最適化されていません。このソリューションでは、特にネットワークリソースの設定履歴の管理という要件を十分に満たすことができません。

問われている要件

この問題では、次の3つの主要な要件を満たすソリューションを選択する必要があります：

1. ネットワークリソースに加えられる変更の監視
2. ネットワークセキュリティポリシーへの厳格な準拠の確保
3. ネットワークリソースの過去の設定へのアクセス

前提知識

AWS Config

AWS Configは、AWS環境内のリソース設定を評価、監査、および評価するためのサービスです。以下の主要な機能があります：

• 設定レコーダー（Configuration Recorder）: AWS環境内のリソース設定変更を継続的に記録します。これにより、誰が、いつ、どのような変更を行ったかの詳細な監査証跡が提供されます。
• 設定履歴（Configuration History）: リソースの設定変更の時系列履歴を保持します。特定の時点でのリソースの状態を確認できるため、問題のトラブルシューティングや変更の追跡に役立ちます。
• 設定スナップショット（Configuration Snapshot）: AWS環境内の全てのリソースの現在の設定状態の完全なスナップショットを提供します。これはコンプライアンス監査やリソース管理に役立ちます。
• Config Rules: リソースが望ましい設定に準拠しているかを評価するためのルールを定義できます。AWSが提供するマネージドルールを使用するか、カスタムルールを作成できます。
• 修復アクション（Remediation Actions）: 非準拠リソースを自動的に修復するためのアクションを設定できます。例えば、セキュリティグループのルールが変更された場合に自動的に元の状態に戻すことができます。
• 集約ビュー（Aggregated View）: 複数のAWSアカウントやリージョンからの設定データを一元的に表示できます。

EventBridge（旧CloudWatch Events）

Amazon EventBridgeは、アプリケーションをイベント駆動型に接続するためのサーバーレスイベントバスサービスです。AWS環境内で発生するさまざまなイベント（APIコールなど）に反応してアクションを実行できます。このサービスは、変更の検出には有用ですが、過去の設定履歴を管理するための組み込み機能は提供していません。

CloudWatch Logs と CloudWatch メトリクス

CloudWatch Logsは、ログデータの保存と監視のためのサービスであり、CloudWatchメトリクスはこれらのログから抽出された数値データです。これらのサービスは、イベントの検出と通知に利用できますが、リソースの具体的な設定状態を詳細に追跡するようには設計されていません。

Systems Manager Inventory と State Manager

Systems Manager Inventoryは、主にEC2インスタンスやオンプレミスサーバーの構成詳細（インストールされたソフトウェア、設定など）を収集するためのツールです。State Managerは、これらのインスタンスに対して特定の構成状態を適用し維持するためのサービスです。これらは主にコンピューティングリソースの管理に焦点を当てており、VPCやサブネットなどのネットワークリソースの管理には最適化されていません。

解くための考え方

この問題を解決するには、各選択肢を3つの主要要件に照らし合わせて評価する必要があります：

1. 変更監視：全ての選択肢がある程度の変更監視機能を提供していますが、AWS Configは特にリソース設定の変更を追跡するサービスです。
2. コンプライアンス確保：AWS Configのルールと修復アクションは、リソースが希望する設定に準拠していることを確認し、違反があった場合に自動的に修正するための仕組みがあります。
3. 過去の設定へのアクセス：AWS Configは、リソースの設定変更の履歴を自動的に記録し、特定の時点でのリソースの状態を確認するための機能を提供します。これは、問題のトラブルシューティングや監査に特に有用です。

問題の状況では、ネットワークエンジニアがVPCの設計を構築・テストしており、ネットワークリソースの変更監視と過去の設定へのアクセスが必要です。AWS Configは、VPC、サブネット、ルートテーブル、セキュリティグループなどのネットワークリソースの変更を自動的に追跡し、これらのリソースが会社のセキュリティポリシーに準拠していることを確認するためのルールを設定できます。

AWS Configは、問題の3つの要件全てに対応するための専用機能を提供する唯一のサービスであり、特にネットワークリソースの設定管理のコンテキストでは最適な選択肢です。

参考資料

• AWS Config とは
• AWS Config ルールの使用
• AWS Config による修復アクション
• AWS Systems Manager Inventory
• Amazon EventBridge

正解：A

A. オンプレミスとAWS間にAWS Site-to-Site VPN接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolver アウトバウンドエンドポイントをデプロイします。

正解 – AWS Site-to-Site VPN接続は、パブリックインターネット経由の安全な暗号化接続を迅速に確立できます。Route 53 Resolver アウトバウンドエンドポイントと組み合わせることで、VPC内のEC2インスタンスからのDNSクエリをオンプレミスDNSサーバーに転送できます。3ヶ月の短期間の移行に適しており、設定も比較的簡単です。

B. プライベートVIFを持つAWS Direct Connect接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolver インバウンドエンドポイントとRoute 53 Resolver アウトバウンドエンドポイントをデプロイします。

不正解 – AWS Direct Connect接続は、高帯域幅で低レイテンシーの専用接続を提供しますが、設定には通常数週間から数ヶ月かかります。3ヶ月の一時的な移行期間にはオーバースペックで、セットアップにかかる時間も考慮すると適切ではありません。また、インバウンドとアウトバウンドの両方のResolverエンドポイントは不要です。

C. オンプレミスとAWS間にAWS Client VPN接続を設定します。VPCにAmazon Route 53 Resolver インバウンドエンドポイントをデプロイします。

不正解 – AWS Client VPNは主にリモートユーザーがAWSリソースに安全にアクセスするためのサービスであり、DNSトラフィックの転送には適していません。また、インバウンドエンドポイントはオンプレミスからAWSへのDNSクエリをルーティングするためのものであり、この要件（AWSからオンプレミスへのDNSクエリ）には適合しません。

D. パブリックVIFを持つAWS Direct Connect接続を設定します。VPCをホストしているリージョンにAmazon Route 53 Resolver インバウンドエンドポイントをデプロイします。オンプレミスDNSサーバーへの接続にはエンドポイントに割り当てられたIPアドレスを使用します。

不正解 – Direct Connectにはセットアップ時間がかかり、3ヶ月の移行期間には不向きです。また、パブリックVIFはパブリックAWSサービスへのアクセスに使用され、プライベートネットワークトラフィック（DNSクエリなど）には通常プライベートVIFが使用されます。さらに、インバウンドエンドポイントは要件に合っていません。

問われている要件

この問題では、以下の要件を満たすソリューションを選択する必要があります：

1. EC2インスタンスからオンプレミスサーバーの名前を解決できること
2. 3ヶ月の一時的な移行期間のみ必要であること
3. 最小限の設定で実装できること

これらの要件を踏まえると、迅速に設定でき、コスト効率が良く、一時的な使用に適した解決策が求められます。

前提知識

AWS Site-to-Site VPN

AWS Site-to-Site VPNは、お客様のネットワーク（オンプレミス環境など）とAWS VPC間の安全な接続を提供するサービスです。以下の特徴があります：

• 迅速なセットアップ: 設定後、数分から数時間で接続が確立
• コスト効率: 従量課金制で、使用時間とデータ転送量に基づく料金
• セキュリティ: IPsecプロトコルを使用した暗号化通信
• 柔軟性: 必要に応じて簡単に設定変更や削除が可能
• 一時的な接続に適している: 永続的なハードウェアや長期契約が不要

AWS Direct Connect

AWS Direct Connectは、オンプレミスとAWS間の専用ネットワーク接続を提供するサービスです：

• 高帯域幅: 1Gbpsから100Gbpsの専用接続
• 低レイテンシー: パブリックインターネットを経由しない直接接続
• セットアップ時間が長い: 通常、設定完了まで数週間から数ヶ月必要
• 長期的な使用に適している: 初期セットアップに時間とコストがかかるため
• VIF（Virtual Interface）タイプ:
  • プライベートVIF: VPCなどのプライベートリソースへのアクセス
  • パブリックVIF: S3、DynamoDBなどのAWSパブリックサービスへのアクセス

Amazon Route 53 Resolver

Amazon Route 53 Resolverは、VPC内のDNS解決を管理するサービスです：

• インバウンドエンドポイント: オンプレミスネットワークからAWS内のDNS名を解決する際に使用
• アウトバウンドエンドポイント: AWS内からオンプレミスネットワークのDNS名を解決する際に使用
• 転送ルール: 特定のドメイン名に対するDNSクエリを指定されたDNSサーバーに転送

オンプレミスDNS解決のアーキテクチャ

AWS Client VPN

AWS Client VPNは、リモートクライアント（ユーザーのデバイスなど）がAWSリソースやオンプレミスネットワークに安全にアクセスするためのマネージドクライアントベースのVPNサービスです：

• エンドユーザーのリモートアクセス向け: 主にリモートワーカーがAWSリソースにアクセスするために使用
• インフラストラクチャ間接続には適していない: サイト間のネットワーク接続には向いていない
• クライアントソフトウェアが必要: 接続するユーザーはVPNクライアントをインストールする必要がある

解くための考え方

この問題を解決するための最適なアプローチを選択するには、以下の点を考慮する必要があります：

1. タイムライン: 3ヶ月の短期間の移行期間に対応する必要があります。Direct Connectの設定には通常数週間から数ヶ月かかるため、この要件には適していません。
2. DNS解決の方向: EC2インスタンスからオンプレミスサーバーの名前を解決する必要があります。これはAWSからオンプレミスへの方向であり、Route 53 Resolverのアウトバウンドエンドポイントが必要です。
3. 接続タイプの選択: 一時的な使用には、セットアップが簡単でコスト効率の良いSite-to-Site VPNが適しています。
4. 最小限の設定: シンプルな構成で要件を満たす必要があります。

これらの考慮事項を踏まえると、AWS Site-to-Site VPN接続とRoute 53 Resolver アウトバウンドエンドポイントの組み合わせが最適です。この構成では、VPN接続を通じてEC2インスタンスからのDNSクエリをオンプレミスDNSサーバーに転送し、名前解決を実現できます。また、移行完了後はVPN接続とResolverエンドポイントを簡単に削除できます。

参考資料

• AWS Site-to-Site VPN とは
• AWS Direct Connect の詳細
• Amazon Route 53 Resolver とは
• Route 53 Resolver のアウトバウンドエンドポイントの設定
• AWS Client VPN の概要

正解：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機能を活用することでコスト効率が最大化されます。

C. ファイアウォールアプライアンスをターゲットとするNetwork Load Balancerを導入します。ファイアウォールアプライアンスをプライベートサブネット内の単一のネットワークインターフェイスで構成します。検査後のトラフィックをインターネットに送信するためにNATゲートウェイを使用します。

不正解 – Network Load Balancerはレイヤー4の負荷分散に最適化されていますが、ファイアウォールアプライアンスの負荷分散にはGateway Load Balancerの方が適しています。また、この選択肢も追加のNATゲートウェイを必要とするため、コスト効率が低下します。

D. ファイアウォールアプライアンスをターゲットとするNetwork Load Balancerを導入します。ファイアウォールアプライアンスを2つのネットワークインターフェイスで構成します：1つはプライベートサブネット内、もう1つはパブリックサブネット内です。検査後のトラフィックをインターネットに送信するためにファイアウォールアプライアンスのNAT機能を使用します。

不正解 – この選択肢はファイアウォールアプライアンスのNAT機能を使用しており、追加のNATゲートウェイが不要なため、その点ではコスト効率的です。しかし、Gateway Load Balancerの代わりにNetwork Load Balancerを使用しています。ファイアウォールアプライアンスなどのネットワークアプライアンスの負荷分散には、Gateway Load Balancerの方が適しています。

問われている要件

この問題では、以下の要件を満たす最もコスト効率的なアーキテクチャを選択する必要があります：

1. サードパーティのファイアウォールアプライアンスの導入
2. トラフィック検査機能の提供
3. NAT機能の提供
4. ロードバランサーの背後での導入
5. プライベートサブネットとパブリックサブネットを含むVPC内での構成

特に重要なのは「最もコスト効率的」という条件です。

前提知識

Gateway Load Balancer (GWLB)

Gateway Load Balancerは、ファイアウォール、侵入検知・防止システム、ディープパケットインスペクションシステムなどのサードパーティ製ネットワークアプライアンスの管理に特化したロードバランサーです。主な特徴は以下の通りです：

• GENEVEカプセル化: GWLBはトラフィックをGENEVEプロトコル（Generic Network Virtualization Encapsulation）でカプセル化し、元のパケット情報を保持したままアプライアンスに転送します。
• 透過的動作: フローの対称性を維持し、送信元と宛先の情報を保持したままトラフィックを処理します。
• 高可用性: 複数のアベイラビリティーゾーンにわたるスケーラブルなセキュリティアプライアンスの展開をサポートします。
• ヘルスチェック: ターゲットグループ内のアプライアンスの健全性を監視します。
• 料金体系: 時間単位料金と処理データ量に基づく料金。

Network Load Balancer (NLB)

Network Load Balancerはレイヤー4（トランスポート層）で動作し、TCPおよびUDPトラフィックを処理するロードバランサーです：

• 高パフォーマンス: 数百万リクエスト/秒のスループットを処理できます。
• 低レイテンシー: 固定IPアドレスを提供し、高速なロードバランシングを行います。
• 静的IP: 各アベイラビリティーゾーンで静的IPを提供します。
• 料金体系: 時間単位料金と処理データ量に基づく料金。

NAT Gateway

NATゲートウェイは、プライベートサブネット内のリソースがインターネットや他のAWSサービスにアクセスできるようにするためのマネージドサービスです：

• 高可用性: 単一のアベイラビリティーゾーン内で冗長設計されています。
• スケーラビリティ: 最大45Gbpsまで自動的にスケールします。
• 料金体系: 時間単位料金と処理データ量に基づく料金で、比較的コストが高いサービスです。

サードパーティファイアウォールの展開アーキテクチャ比較

ファイアウォールデプロイメントモデル

ファイアウォールアプライアンスのデプロイメントには主に2つのモデルがあります：

1. シングルアームモード（One-arm mode）:
   • ファイアウォールアプライアンスに単一のネットワークインターフェイスを構成
   • トラフィック検査のみを担当
   • 送信元/宛先アドレス変換（NAT）は別のコンポーネント（NATゲートウェイなど）が処理
   • より単純な構成だが、追加のNATサービスが必要
2. デュアルアームモード（Two-arm mode）:
   • ファイアウォールアプライアンスに2つのネットワークインターフェイスを構成
   • 1つはプライベートサブネット向け、もう1つはパブリックサブネット向け
   • トラフィック検査とNAT処理の両方を担当
   • ファイアウォールベンダーのNAT機能のサポートが必要
   • 追加のNATサービスが不要でコスト削減が可能

解くための考え方

この問題の主要な考慮事項は以下の通りです：

1. ロードバランサーの選択:
   • Gateway Load Balancer (GWLB)はサードパーティのファイアウォールアプライアンス向けに特化したサービス
   • Network Load Balancer (NLB)は汎用的なレイヤー4ロードバランサー
   • ファイアウォールアプライアンスの負荷分散にはGWLBの方が適している
2. ファイアウォールデプロイメントモデル:
   • シングルアームモードは追加のNATゲートウェイが必要
   • デュアルアームモードはアプライアンス自体のNAT機能を使用
3. コスト効率:
   • NAT Gatewayは時間単位と処理データ量に基づく料金がかかる高価なサービス
   • ファイアウォールアプライアンスは既に必要なコンポーネントであり、そのNAT機能を活用すれば追加コストなし

最もコスト効率的なソリューションを選択するには、以下の点を評価します：

• 既に必要なコンポーネント（ファイアウォールアプライアンス）の機能をフルに活用
• 追加コンポーネント（NAT Gateway）の導入を避ける
• ファイアウォールアプライアンスに最適なロードバランサー（GWLB）を選択

これらの評価に基づくと、Gateway Load Balancerとデュアルアームモードのファイアウォールアプライアンス（2つのネットワークインターフェイス）を組み合わせ、アプライアンス自体のNAT機能を使用する選択肢が最もコスト効率的なソリューションとなります。

参考資料

• Gateway Load Balancerの導入ベストプラクティス
• AWSでのファイアウォールの展開パターン
• NATゲートウェイの料金
• Gateway Load Balancerのアーキテクチャ
• AWSネットワークファイアウォールの構成

正解：B

A. 共有サービスVPCにRoute 53 Resolver インバウンドエンドポイントを新しく作成します。オンプレミスでホストされているドメイン用の転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。各アプリケーションVPCのDHCP設定を更新して、DNS解決が新しいResolverエンドポイントを指すようにします。

不正解 – Route 53 Resolver インバウンドエンドポイントはオンプレミスネットワークからAWS内のDNS名を解決するために使用されるものであり、AWS内からオンプレミスのDNS名を解決する必要があるこの要件には適していません。また、DHCP設定を変更してAmazonProvidedDNS以外のDNSサーバーを指定すると、ローカルVPCドメイン名やRoute 53プライベートホストゾーンの名前解決ができなくなるため、要件を満たせません。

B. 共有サービスVPCにRoute 53 Resolver アウトバウンドエンドポイントを新しく作成します。オンプレミスでホストされているドメイン用の転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。

正解 – Route 53 Resolver アウトバウンドエンドポイントはAWS内からオンプレミスのDNS名を解決するために使用されるため、要件に適しています。オンプレミスでホストされているドメイン用の転送ルールを作成し、それを各アプリケーションVPCに関連付けることで、AWSのデフォルトDNS解決機能を保持しながらオンプレミスドメインの解決が可能になります。これにより、ローカルVPCドメイン名とRoute 53プライベートホストゾーンの解決も引き続き機能します。

C. 共有サービスVPCにRoute 53 Resolver アウトバウンドエンドポイントを新しく作成します。オンプレミスでホストされているドメイン用の転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。各アプリケーションVPCのDHCP設定を更新して、DNS解決が新しいResolverエンドポイントを指すようにします。

不正解 – アウトバウンドエンドポイントの設定は適切ですが、DHCP設定を変更してResolverエンドポイントを指すよう設定すると、AmazonProvidedDNSの利点が失われ、ローカルVPCドメイン名やRoute 53プライベートホストゾーンが正しく解決できなくなります。Route 53 Resolverは転送ルールに基づいて自動的にクエリをルーティングするため、DHCP設定の変更は必要ありません。

D. 共有サービスVPCにRoute 53 Resolver インバウンドエンドポイントを新しく作成します。オンプレミスでホストされているドメイン用の転送ルールを作成します。ルールを新しいResolverエンドポイントと各アプリケーションVPCに関連付けます。

不正解 – インバウンドエンドポイントはオンプレミスからAWSへのDNS解決を可能にするもので、AWS内からオンプレミスへのDNS解決という要件を満たしていません。また、DHCPオプションセットの変更がないものの、そもそもインバウンドエンドポイントが要件に合致していないため、機能しません。

問われている要件

この問題では、以下の3つの要件を同時に満たすDNS解決設定が求められています：

1. オンプレミスでホストされている内部ドメインの名前解決
2. ローカルVPCドメイン名の名前解決
3. Route 53プライベートホストゾーンでホストされているドメインの名前解決

特に、複数のVPC環境で効率的かつ一元管理可能な方法で、これらのDNS解決を実現する必要があります。

前提知識

Route 53 Resolver

Amazon Route 53 Resolverは、AWS内のDNS解決を管理するサービスです。主に以下の2種類のエンドポイントを提供します：

1. インバウンドエンドポイント：
   • オンプレミスネットワークからAWS内のDNS名を解決するために使用
   • オンプレミスからVPC内のリソースやRoute 53プライベートホストゾーンのドメインを参照する場合に必要
   • IPアドレスを公開し、オンプレミスDNSサーバーからの転送先として設定される
2. アウトバウンドエンドポイント：
   • AWS内からオンプレミスのDNS名を解決するために使用
   • VPC内のリソースがオンプレミスでホストされているドメインを参照する場合に必要
   • 条件付き転送ルールを設定して、特定のドメイン（example.local など）へのクエリをオンプレミスDNSサーバーに転送

Route 53 Resolver アウトバウンドエンドポイントによるDNS解決

DHCPオプションセット

AWSでは、DHCPオプションセットを使用してVPC内のEC2インスタンスなどのリソースに対してDNS設定を提供します：

• AmazonProvidedDNS：AWSが提供するデフォルトのDNSサーバー（VPC+2アドレス）
  • ローカルVPCドメイン名（例：ip-10-0-0-1.ec2.internal）を解決可能
  • Route 53プライベートホストゾーンのドメインを解決可能
  • AWSのパブリックエンドポイントを解決可能
• カスタムDNSサーバー：独自のDNSサーバーを指定する場合
  • AmazonProvidedDNSの代わりにカスタムDNSサーバーが使用される
  • ローカルVPCドメイン名やRoute 53プライベートホストゾーンの解決はカスタムDNSサーバーで対応する必要がある
  • 正しく設定しないと、AWS内のドメイン名が解決できなくなる可能性がある

解くための考え方

この問題の解決策を選ぶには、以下の点を考慮する必要があります：

1. DNS解決の方向性：
   • AWS内からオンプレミスドメインを解決する必要がある → アウトバウンドエンドポイントが適切
   • オンプレミスからAWSドメインを解決する必要はない → インバウンドエンドポイントは不要
2. AWSのドメイン解決機能の維持：
   • ローカルVPCドメインとRoute 53プライベートホストゾーンも解決できる必要がある
   • AmazonProvidedDNSを維持する必要がある（DHCPオプションを変更すべきでない）
3. 効率的な設計：
   • 共有サービスVPCに一つのエンドポイントを作成し、それを複数のアプリケーションVPCで共有する方が効率的

Route 53 Resolverの標準的な動作として、特定のドメイン（例：onprem.local）に対するクエリのみを設定した転送ルールに基づいてオンプレミスDNSサーバーに転送し、その他のクエリ（VPCローカルドメインやRoute 53プライベートホストゾーン）はAmazonProvidedDNSによって処理されます。

これを実現するには、DHCPオプションセットをデフォルトのままにして、Route 53 Resolver アウトバウンドエンドポイントと転送ルールを設定する選択肢が最も適切です。これにより、すべての要件を満たすハイブリッドDNS解決環境が構築できます。

参考資料

• Amazon Route 53 Resolverの概要
• オンプレミスネットワークとAWS間のDNS解決の設定
• Route 53 Resolver エンドポイントの作成
• DHCPオプションセット
• ハイブリッドクラウドDNSソリューション

正解：C

A. Amazon Inspectorとそのネットワーク到達可能性ルールパッケージを使用します。分析が完了するまで待って、どのEC2インスタンスが古いポートをまだリッスンしているかを確認します。

不正解 Amazon Inspectorのネットワーク到達可能性分析は、コンテナで実行中の アプリケーションに対応しておらず、EC2インスタンスのみが対象です。 また、実際のトラフィック使用状況ではなく設定ベースの分析のため、 古いプロトコルが実際に使用されているかの検証には不適切です。

B. Amazon GuardDutyを有効にします。グラフィカルな可視化を使用して、古いプロトコルのポートを使用するトラフィックをフィルタリングします。同じポートが一時的なポートとして使用される場合を除外するために、すべてのインターネットトラフィックを除外します。

不正解 Amazon GuardDutyはセキュリティ脅威の検出サービスで、異常なネットワークトラフィックを検出することはできますが、特定のポートの使用状況を網羅的に分析するためのツールではありません。また、過去のトラフィックデータを遡って分析することができないため、現在使用されていない可能性のある古いプロトコルの検出には適していません。

C. VPCフローログをAmazon S3バケットに配信するように設定します。Amazon Athenaを使用してデータをクエリし、古いプロトコルで使用されるポート番号をフィルタリングします。

正解 VPCフローログはすべてのネットワークトラフィックをキャプチャし、そのデータをS3バケットに保存できます。Amazon Athenaを使用することで、特定のポート番号を使用するトラフィックを効率的にフィルタリングして分析できます。この方法では、エージェントのインストールやセキュリティグループの変更が不要なため、ダウンタイムを発生させることなく検証が可能です。また、過去のトラフィックデータも分析できるため、断続的に使用されている可能性のあるアプリケーションも検出できます。

D. アプリケーションをホストするEC2インスタンスに割り当てられているすべてのセキュリティグループを検査します。古いプロトコルのポートが許可されたポートのリストにある場合は、そのポートを削除します。セキュリティグループからポートを削除した後、アプリケーションが正常に動作していることを確認します。

不正解 セキュリティグループから古いプロトコルのポートを削除する方法は、実際にまだそのプロトコルを使用しているアプリケーションがある場合に、そのアプリケーションが機能しなくなるリスクがあります。「ダウンタイムを発生させずに」という要件を満たさない可能性があります。また、この方法では実際のトラフィックを検証するのではなく、単に可能性を排除するだけなので、検証にはなりません。

問われている要件

この問題では、「ダウンタイムを発生させずに」古いプロトコルがまだ使用されていないことを検証する方法を求められています。つまり、現在稼働中のシステムに影響を与えずに調査する必要があります。また、古いプロトコルは特定のポート番号を使用しているため、そのポートを使用するトラフィックを検出できる方法が必要です。

前提知識

VPCフローログ

VPCフローログは、Amazon VPC内のネットワークインターフェイスとの間で送受信されるIPトラフィックの情報をキャプチャするサービスです。フローログレコードには以下のような情報が含まれています：

• 送信元IPアドレス・ポート番号
• 宛先IPアドレス・ポート番号
• プロトコル（TCP、UDPなど）
• パケット数・バイト数
• トラフィックの方向（IN/OUT）
• アクション（ACCEPT/REJECT）
• トラフィックの発生時間

これにより、ネットワーク内のすべてのトラフィックを可視化し、特定のパターンを検出することができます。VPCフローログの設定は、既存のネットワークトラフィックやアプリケーションのパフォーマンスに影響を与えません。

Amazon Athena

Amazon Athenaは、標準SQLを使用してS3に保存されたデータを直接分析できるサーバーレスのインタラクティブなクエリサービスです。Athenaの主な特徴は以下の通りです：

• サーバーレス：インフラストラクチャの管理が不要
• ペイ・パー・クエリ：実行したクエリでスキャンされたデータ量に対してのみ支払い
• 標準SQL：ANSI SQLを使用してクエリを実行可能
• 多様なデータ形式：CSV、JSON、Parquet、ORC、Avroなど様々な形式をサポート

VPCフローログとAthenaを組み合わせることで、特定のポート番号を使用するトラフィックパターンを効率的に分析できます。

アプリケーション層プロトコルとポート番号

アプリケーション層プロトコルは、OSI参照モデルの最上位層で動作するプロトコルで、具体的なアプリケーションサービスを提供します（HTTP、FTP、SMTPなど）。これらのプロトコルは通常、特定のポート番号と関連付けられています。例えば、HTTPは80番ポート、HTTPSは443番ポートを使用します。

企業が古いプロトコルから新しいプロトコルに移行する場合、アプリケーションの設定変更が必要であり、完全に移行されたかを確認するには、古いプロトコルで使用されていたポート番号のトラフィックがないことを検証する必要があります。

解くための考え方

この問題を解くためには、次の点を考慮する必要があります：

1. ダウンタイムレスな方法：ダウンタイムを発生させないため、実行中のアプリケーションに影響を与えない方法が必要です。
2. 包括的な検証：すべてのアプリケーションが古いプロトコルを使用していないことを確認するため、網羅的なトラフィック分析が必要です。
3. 過去のデータ分析：断続的に使用されている可能性のあるアプリケーションも検出するため、過去のトラフィックデータも分析できる方法が望ましいです。

VPCフローログとAmazon Athenaを組み合わせたソリューションは、上記のすべての条件を満たします。フローログを有効にしてS3に保存し、Athenaを使用して特定のポート番号でフィルタリングすることで、古いプロトコルを使用しているアプリケーションを効率的に特定できます。また、この方法では既存のアプリケーションに影響を与えず、ダウンタイムを発生させることなく検証が可能です。

VPCフローログとAthenaを使った検証

上の図は、VPCフローログとAthenaを使用して古いプロトコルの使用状況を検証するプロセスを示しています。VPC内のEC2インスタンスやコンテナで実行されているアプリケーションからのネットワークトラフィックがVPCフローログによってキャプチャされ、S3バケットに保存されます。その後、Amazon Athenaを使用してこのデータを分析し、古いプロトコルのポート番号を使用しているトラフィックがあるかどうかを確認します。この方法では実行中のアプリケーションに影響を与えず、ダウンタイムなしで検証が可能です。

参考資料

• VPC フローログ – Amazon Virtual Private Cloud
• Amazon Athena – 分析ドキュメント
• Amazon Athena を使用した VPC フローログのクエリ
• ネットワークモニタリングのための VPC フローログの使用

正解：C, E

A. オンプレミス用に別のトランジットゲートウェイルートテーブルを設定します。VPN接続をこのトランジットゲートウェイルートテーブルに関連付けます。すべてのアプリケーションVPC接続をこのトランジットゲートウェイルートテーブルに伝播します。

不正解 この設定では、オンプレミス用のトランジットゲートウェイルートテーブルにアプリケーションVPC接続が伝播されますが、アプリケーションVPC側から見たオンプレミスへの経路が確立されません。また、共有サービスVPCとの通信を設定する内容も含まれていないため、要件を満たしません。

B. 各アプリケーションVPC用に別々のトランジットゲートウェイルートテーブルを設定します。各アプリケーションVPC接続をそれぞれのトランジットゲートウェイルートテーブルに関連付けます。共有サービスVPC接続とVPN接続をこのトランジットゲートウェイルートテーブルに伝播します。

不正解 各アプリケーションVPC用に別々のトランジットゲートウェイルートテーブルを設定する方法は、アプリケーションVPC同士の分離という要件は満たしますが、数百のアプリケーションVPCに対して別々のルートテーブルを作成することになり、「最小数のトランジットゲートウェイルートテーブル」という条件を満たしません。

C. すべてのアプリケーションVPC用に別のトランジットゲートウェイルートテーブルを設定します。すべてのアプリケーションVPCをこのトランジットゲートウェイルートテーブルに関連付けます。共有サービスVPC接続とVPN接続をこのトランジットゲートウェイルートテーブルに伝播します。

正解 すべてのアプリケーションVPC用に1つのトランジットゲートウェイルートテーブルを設定し、このルートテーブルに共有サービスVPCとVPN接続を伝播することで、アプリケーションVPCから共有サービスVPCとオンプレミスへの通信経路が確立されます。ただし、この設定だけではアプリケーションVPC同士の分離が実装されないため、追加の設定が必要です。

D. 共有サービスVPC用に別のトランジットゲートウェイルートテーブルを設定します。共有サービスVPC接続をこのトランジットゲートウェイルートテーブルに関連付けます。すべてのアプリケーションVPC接続をこのトランジットゲートウェイルートテーブルに伝播します。

不正解 この設定では、共有サービスVPC側からアプリケーションVPCへの通信経路は確立されますが、アプリケーションVPC側から共有サービスVPCやオンプレミスへの経路が確立されません。また、オンプレミスとの接続についても考慮されていないため、要件を満たしません。

E. オンプレミスと共有サービスVPC用に別のトランジットゲートウェイルートテーブルを設定します。VPN接続と共有サービスVPC接続をこのトランジットゲートウェイルートテーブルに関連付けます。すべてのアプリケーションVPC接続をこのトランジットゲートウェイルートテーブルに伝播します。

正解 オンプレミスと共有サービスVPC用に1つのトランジットゲートウェイルートテーブルを設定し、すべてのアプリケーションVPC接続をこのルートテーブルに伝播することで、共有サービスVPCとオンプレミスからアプリケーションVPCへの通信経路が確立されます。これをもう一方の正解の選択肢と組み合わせることで、双方向の通信が可能になります。

問われている要件

この問題では、トランジットゲートウェイを使用して以下の条件を満たすネットワーク設計が求められています：

1. アプリケーションVPC同士は互いに分離されていること
2. アプリケーションVPCとオンプレミスネットワーク間で双方向通信が可能であること
3. アプリケーションVPCと共有サービスVPC間で双方向通信が可能であること
4. 最小数のトランジットゲートウェイルートテーブルで実現すること

前提知識

トランジットゲートウェイ

AWS Transit Gatewayは、VPCとオンプレミスネットワークを接続するためのネットワークハブです。これにより、複雑になり得る多数のピアリング接続を管理する必要がなくなります。トランジットゲートウェイは、スター型トポロジを使用して、すべてのVPCとオンプレミスネットワークを一つの中央ハブに接続できます。

トランジットゲートウェイの接続（アタッチメント）

トランジットゲートウェイには、VPC、VPN接続、Direct Connect gateway、別のトランジットゲートウェイなどの「アタッチメント」を作成できます。アタッチメントはトランジットゲートウェイに接続されるネットワークリソースです。

トランジットゲートウェイのルートテーブル

トランジットゲートウェイルートテーブルは、トラフィックがどのアタッチメントに転送されるかを制御します。各アタッチメントは一つのルートテーブルに関連付け（アソシエーション）できますが、ルートをその他のルートテーブルに伝播（プロパゲーション）することも可能です。

• アソシエーション（関連付け）: アタッチメントとルートテーブルを関連付けると、そのアタッチメントからのトラフィックはそのルートテーブルを使用してルーティングされます。
• プロパゲーション（伝播）: アタッチメントのルートをルートテーブルに伝播すると、そのルートテーブルを使用するアタッチメントはそのアタッチメントにトラフィックを送信できます。

デフォルトルートテーブルの関連付けと伝播

トランジットゲートウェイでは、デフォルトでは新しいアタッチメントがデフォルトルートテーブルに関連付けられ、そのルートがデフォルトルートテーブルに伝播されます。問題の設定では、これらのオプションが無効になっているため、明示的にルートテーブルの関連付けと伝播を設定する必要があります。

解くための考え方

この問題を解決するためには、ルートテーブルの関連付け（アソシエーション）と伝播（プロパゲーション）の概念を理解することが重要です。

最小数のルートテーブルで要件を満たすには、機能的に似たアタッチメントをグループ化し、共通のルートテーブルに関連付けます。同時に、通信を許可したいアタッチメントのルートを適切なルートテーブルに伝播します。

具体的には、以下の2つのルートテーブルが必要です：

1. アプリケーションVPC用のルートテーブル：
   • 関連付け：すべてのアプリケーションVPC
   • 伝播：共有サービスVPCとVPN接続
2. 共有サービスVPCとオンプレミス用のルートテーブル：
   • 関連付け：共有サービスVPCとVPN接続
   • 伝播：すべてのアプリケーションVPC

この設計により、以下の通信パスが可能になります：

• アプリケーションVPC → 共有サービスVPC（アプリケーションVPCルートテーブルに共有サービスVPCルートが伝播されるため）
• アプリケーションVPC → オンプレミス（アプリケーションVPCルートテーブルにVPN接続ルートが伝播されるため）
• 共有サービスVPC → アプリケーションVPC（共有サービスVPCルートテーブルにアプリケーションVPCルートが伝播されるため）
• オンプレミス → アプリケーションVPC（VPN接続ルートテーブルにアプリケーションVPCルートが伝播されるため）

重要なのは、アプリケーションVPC同士は直接通信できないことです。これは、アプリケーションVPCルートテーブルに他のアプリケーションVPCのルートが伝播されていないためです。

トランジットゲートウェイの設計

上の図は、トランジットゲートウェイの設計を示しています。2つのルートテーブルを使用することで、要件を満たしつつ最小限のルートテーブル数を実現しています。

ルートテーブル1はすべてのアプリケーションVPCに関連付けられ、共有サービスVPCとVPN接続からのルートが伝播されています。ルートテーブル2は共有サービスVPCとVPN接続に関連付けられ、すべてのアプリケーションVPCからのルートが伝播されています。

この設計により、アプリケーションVPC同士は互いに通信できず（分離されており）、アプリケーションVPCと共有サービスVPC間、およびアプリケーションVPCとオンプレミスネットワーク間では双方向通信が可能になります。

参考資料

• トランジットゲートウェイの仕組み – Amazon VPC
• 分離されたVPCと共有サービス – トランジットゲートウェイの例
• トランジットゲートウェイのルートテーブル – Amazon VPC
• トランジットゲートウェイのアタッチメント – Amazon VPC

補足：関連付け（アソシエーション）と伝播（プロパゲーション）の違い

関連付け（アソシエーション）

• 目的: アタッチメント（VPCやVPN接続など）からのトラフィックがどのルートテーブルを使用してルーティングされるかを定義します。
  各アタッチメントは1つのルートテーブルにのみ関連付けることができます。
• 例: VPC A がルートテーブル1に関連付けられている場合、VPC A からのすべてのトラフィックはルートテーブル1のルートに基づいてルーティングされます。

伝播（プロパゲーション）

• 目的: アタッチメントのルート（CIDR範囲）を特定のルートテーブルに広告（公開）します。各アタッチメントのルートは複数のルートテーブルに伝播できます。
• 例: VPC B のルートがルートテーブル1に伝播されている場合、ルートテーブル1を使用するアタッチメント（この場合VPC A）はVPC B にトラフィックを送信できます。

正解：B

A. オンプレミスのWindows DNSサーバーを指定する新しいDHCPオプションセットを作成します。新しいDHCPオプションセットを既存のVPCに関連付けます。Amazon Linux 2 EC2インスタンスを再起動します。

不正解 新しいDHCPオプションセットを作成してVPCに関連付けることは、VPC内のすべてのインスタンスに対してDNS設定を変更する方法ですが、設定変更が反映されるためには既存のEC2インスタンスの再起動が必要です。また、デフォルトのDHCPオプションセットを置き換えることで、Amazon提供のDNSサーバー（AmazonProvidedDNS）が使用できなくなる可能性があり、VPCエンドポイントなどのAWSサービスの名前解決に問題が生じる可能性があります。

B. Amazon Route 53 Resolverルールを作成します。そのルールをVPCに関連付けます。ドメイン名がexample.internalに一致する場合、DNSクエリをオンプレミスのWindows DNSサーバーに転送するようにルールを設定します。

正解 Amazon Route 53 Resolverルールを作成し、特定のドメイン（example.internal）に対するDNSクエリをオンプレミスのDNSサーバーに転送するように設定することで、VPC内のすべてのリソースが内部ドメイン名を解決できるようになります。これはAmazonProvidedDNSを使用しながら、特定のドメインだけをオンプレミスDNSに転送するため、VPCエンドポイントなどのAWSサービスの名前解決にも影響を与えません。また、既存のEC2インスタンスの再起動も不要です。

C. VPC内のAmazon Linux 2 EC2インスタンスのローカルホストファイルを変更します。サービスドメイン名（api.example.internal）を内部APIサービスのIPアドレスにマッピングします。

不正解 「VPC内の他のリソースに同じ問題が影響するのを防ぐ」という要件を満たしていません。各EC2インスタンスで同じ変更を行う必要があり、スケーラブルではありません。

D. VPC内のAmazon Linux 2 EC2インスタンスのローカル/etc/resolv.confファイルを変更します。ファイル内のネームサーバーのIPアドレスを、会社のオンプレミスWindows DNSサーバーのIPアドレスに変更します。

不正解 /etc/resolv.confファイルを手動で変更することは、EC2インスタンスの再起動時やDHCP更新時に上書きされる可能性があります。また、これはAmazon Linux 2 EC2インスタンスにのみ適用され、「VPC内の他のリソースに同じ問題が影響するのを防ぐ」という要件を満たしていません。

問われている要件

この問題では、以下の要件を満たすソリューションが求められています：

1. EC2インスタンスからオンプレミスAPIサービスのホスト名を使用して正常に接続できるようにすること
2. 同様の問題がVPC内の他のリソースに影響しないようにすること
3. 現状では、IPアドレスを使用した接続は成功するが、ホスト名（api.example.internal）を使用した接続は失敗している

前提知識

DNS解決の仕組み

AWSでは、VPC内のインスタンスはデフォルトでAmazonProvidedDNS（VPCのDHCPオプションセットで指定されるDNSサーバー）を使用してDNS解決を行います。ただし、このDNSサーバーは、AWS内のリソースやパブリックインターネット上のドメインの解決は行えますが、オンプレミスネットワーク内の内部ドメイン（例：example.internal）を解決することはできません。

DHCPオプションセット

DHCPオプションセットは、VPC内のインスタンスがネットワーク設定を自動的に取得するための情報を提供します。DHCPオプションセットには、DNSサーバー、NTPサーバー、ドメイン名などを含めることができます。デフォルトのDHCPオプションセットでは、DNSサーバーとしてAmazonProvidedDNSが使用されます。

Route 53 Resolver

Amazon Route 53 Resolverは、VPC内のインスタンスからのDNSクエリを処理するDNSサービスです。Route 53 Resolverルールを使用すると、特定のドメイン名に対するDNSクエリを、指定したDNSサーバー（例：オンプレミスのDNSサーバー）に転送できます。これにより、AmazonProvidedDNSとオンプレミスDNSサーバーの両方を活用することが可能になります。

解くための考え方

問題を解決するには、EC2インスタンスがオンプレミスのAPIサービスのホスト名（api.example.internal）を解決できるようにする必要があります。また、VPC内の他のリソースにも同様の設定を適用する必要があります。

現在の状況を分析すると：

1. IPアドレスを使用した接続は成功している → ネットワーク接続自体は正常
2. ホスト名を使用した接続が失敗している → ホスト名解決（DNS）に問題がある
3. オンプレミスにWindows DNSサーバーがある → おそらくこれらのサーバーが内部ドメイン名を解決できる

最適な解決方法は、VPC全体に適用でき、既存のDNS設定を大幅に変更することなく、特定のドメイン（example.internal）に対するクエリだけをオンプレミスDNSサーバーに転送する仕組みを構築することです。

Route 53 Resolverルールはまさにこの目的のためのサービスです。Route 53 Resolverアウトバウンドエンドポイントを作成し、特定のドメイン（example.internal）に対するDNSクエリをオンプレミスのWindows DNSサーバーに転送するルールを設定することで、VPC内のすべてのリソースがオンプレミスの内部ドメインを解決できるようになります。

Route 53 Resolverを使用したDNS解決の流れ

上の図は、Route 53 Resolverを使用したDNS解決の流れを示しています。EC2インスタンスがオンプレミスの内部APIサービス（api.example.internal）にアクセスしようとすると、以下のプロセスで実行されます：

1. EC2インスタンスがapi.example.internalのDNS解決を要求
2. Route 53 Resolverがルールを確認し、example.internalドメインのクエリはオンプレミスDNSに転送すべきと判断
3. Route 53 Resolverアウトバウンドエンドポイントを通じて、クエリがオンプレミスのWindows DNSサーバーに転送
4. オンプレミスDNSサーバーがapi.example.internalのIPアドレスを解決
5. 解決されたIPアドレスがRoute 53 Resolverに返される
6. Route 53 ResolverがIPアドレスをEC2インスタンスに返す
7. EC2インスタンスが解決されたIPアドレスを使用してAPIサービスにリクエストを送信

このソリューションを使用すると、VPC内のすべてのリソースがオンプレミスの内部ドメインを解決できるようになり、個々のインスタンスで設定を変更する必要がなくなります。また、AmazonProvidedDNSも引き続き使用できるため、AWSサービスの名前解決にも影響を与えません。

参考資料

• Route 53 Resolver とは – Amazon Route 53
• Amazon VPC の DNS 属性 – Amazon Virtual Private Cloud
• Route 53 Resolver のルールの管理 – Amazon Route 53
• VPC の DHCP オプションセット – Amazon Virtual Private Cloud

正解：C

A. すべてのIPアドレス範囲と更新が必要なセキュリティグループを保持するためのAmazon DynamoDBテーブルを作成します。企業が新しいパートナーを追加するときに、DynamoDBテーブルに新しいIPアドレス範囲を更新します。AWS Lambda関数を呼び出して、DynamoDBテーブルから新しいIPアドレス範囲とセキュリティグループを読み取り、セキュリティグループを更新します。このソリューションをすべてのアカウントにデプロイします。

不正解 このアプローチでは、すべてのアカウントにこのソリューションをデプロイする必要があり、Lambda関数の管理や監視が複数のアカウントにわたって必要となります。これにより運用上の複雑さが増し、最も効率的なソリューションとは言えません。また、Lambda関数の実行に関するエラー処理やリトライロジックも考慮する必要があります。

B. 新しいプレフィックスリストを作成します。許可されるすべてのIPアドレス範囲をプレフィックスリストに追加します。Amazon EventBridge（Amazon CloudWatch Events）ルールを使用して、プレフィックスリストに新しいIPアドレス範囲が追加されるたびにセキュリティグループを更新するAWS Lambda関数を呼び出します。このソリューションをすべてのアカウントにデプロイします。

不正解 このアプローチでは、各アカウントでプレフィックスリストを作成し、EventBridgeルールとLambda関数を使用して更新を行います。複数のアカウントにわたるLambda関数とEventBridgeルールの管理が必要になるため、運用上の複雑さが増します。また、各アカウントでプレフィックスリストを個別に管理する必要があり、一元管理という要件を満たしていません。

C. 新しいプレフィックスリストを作成します。許可されるすべてのIPアドレス範囲をプレフィックスリストに追加します。AWS Resource Access Manager（AWS RAM）を使用してプレフィックスリストを異なるアカウントで共有します。セキュリティグループを更新して、パートナーのIPアドレス範囲の代わりにプレフィックスリストを使用します。企業が新しいパートナーを追加するときに、プレフィックスリストを新しいIPアドレス範囲で更新します。

正解 このアプローチでは、一つのプレフィックスリストを作成し、AWS RAMを使用して複数のアカウントでそれを共有します。セキュリティグループはこの共有プレフィックスリストを参照するため、プレフィックスリストの更新はすべてのアカウントに自動的に反映されます。このソリューションは、中央で一度だけIPアドレス範囲を管理し、すべてのアカウントに変更を反映できるため、最も運用効率が高いです。Lambda関数やイベント処理などの追加のコンポーネントも必要ありません。

D. すべてのIPアドレス範囲と更新が必要なセキュリティグループを保持するためのAmazon S3バケットを作成します。企業が新しいパートナーを追加するときに、S3バケットに新しいIPアドレス範囲を更新します。AWS Lambda関数を呼び出して、S3バケットから新しいIPアドレス範囲とセキュリティグループを読み取り、セキュリティグループを更新します。このソリューションをすべてのアカウントにデプロイします。

不正解 各アカウントでLambda関数をデプロイする必要があり、運用が複雑です。また、S3バケットの更新を検出してLambda関数をトリガーする仕組みの実装が必要で手間がかかります。

問われている要件

この問題では、以下の要件を満たすソリューションが求められています：

1. 複数のAWSアカウントにわたるALBセキュリティグループでパートナーのIPアドレス範囲を一元管理する
2. 新しいパートナーのIPアドレス範囲を追加する際のプロセスを簡素化する
3. 最も運用効率の高い方法でこれを実現する

前提知識

プレフィックスリスト

マネージドプレフィックスリストは、セキュリティグループやルートテーブルで使用できるCIDR（Classless Inter-Domain Routing）ブロックのセットです。プレフィックスリストを使用すると、複数のCIDRブロックを一つのエンティティとして管理でき、セキュリティグループルールでの参照が可能になります。

プレフィックスリストの主な特徴：

• 複数のCIDRエントリを単一のリソースとして管理
• セキュリティグループやルートテーブルでの参照が可能
• 一度更新すると、それを参照するすべてのリソースに変更が反映される

AWS Resource Access Manager (AWS RAM)

AWS RAMは、AWSリソースを複数のAWSアカウントで共有するためのサービスです。AWS RAMを使用すると、特定のリソース（VPC、Transit Gateway、プレフィックスリストなど）を複数のアカウントやAWS Organizationsの組織単位（OU）、組織全体で共有できます。

AWS RAMの主な特徴：

• リソースの所有者がリソースを共有および管理
• 複数のアカウントで同じリソースを使用可能
• リソース共有の制御
• AWS Organizationsとの統合

解くための考え方

この問題を解決するための最適なアプローチを検討する際、以下の点を考慮する必要があります：

1. 一元管理: 多数のアカウントにわたるIPアドレス範囲の管理を一元化
2. 変更の容易さ: 新しいパートナーを追加する際のプロセスの簡素化
3. 運用効率: 導入と維持に必要な労力の最小化
4. 信頼性: 更新プロセスの信頼性と予測可能性の確保

プレフィックスリストとAWS RAMを組み合わせたソリューションは、これらすべての基準を満たします：

1. プレフィックスリストはIPアドレス範囲のコレクションを一元管理するための専用リソース
2. AWS RAMにより、単一のプレフィックスリストを複数のアカウントで共有可能
3. プレフィックスリストの更新は、それを参照するすべてのセキュリティグループに自動的に反映される
4. このアプローチではLambda関数やイベント処理などの追加コンポーネントが不要

プレフィックスリストとAWS RAMを使用した一元管理

上の図は、プレフィックスリストとAWS Resource Access Manager（AWS RAM）を使用したパートナーIPアドレス範囲の一元管理を示しています。管理アカウントでプレフィックスリストを作成し、AWS RAMを通じて複数のアカウントと共有します。管理者がプレフィックスリストに新しいパートナーのIPアドレス範囲を追加すると、その変更はプレフィックスリストを参照するすべてのセキュリティグループに自動的に反映されます。

このソリューションのメリット：

1. 一元管理 – 単一のプレフィックスリストで複数アカウントのセキュリティグループを管理
2. 自動更新 – プレフィックスリストの更新がすべてのセキュリティグループに自動反映
3. 運用効率 – Lambda関数やカスタムコードなどの追加コンポーネントが不要
4. スケーラビリティ – 新しいアカウントを追加する場合も同じプレフィックスリストを共有するだけ

プレフィックスリストとAWS RAMを使用したこのソリューションは、複数アカウントにわたるIPアドレス範囲の管理を簡素化し、最も運用効率の高い方法で要件を満たします。

参考資料

• AWS リソースを共有するためのAWS Resource Access Manager
• Amazon VPCのマネージドプレフィックスリスト
• セキュリティグループでのプレフィックスリストの使用
• AWS RAMを使用したVPCリソースの共有

正解：C

A. AWS Network Manager Route Analyzerを使用して、トランジットゲートウェイルートテーブルとVPCルートテーブルのルートを分析します。VPCフローログを使用して、セキュリティグループルールとネットワークACLルールがVPCで受け入れるか拒否するIPトラフィックを分析します。

不正解 AWS Network Manager Route Analyzerはトランジットゲートウェイのルートテーブルは分析できますが、VPCルートテーブルを分析する機能はありません。VPCルートテーブルは別途手動で確認する必要があります。VPCフローログを使用してIPトラフィックを分析する部分は正しいアプローチです。

B. AWS Network Manager Route Analyzerを使用して、トランジットゲートウェイルートテーブルのルートを分析します。VPCルートテーブルが正しいことを確認します。AWS Firewall Managerを使用して、セキュリティグループルールとネットワークACLルールがVPCで受け入れるか拒否するIPトラフィックを分析します。

不正解 AWS Network Manager Route Analyzerを使用してトランジットゲートウェイルートテーブルを分析し、VPCルートテーブルを確認する部分は正しいアプローチですが、AWS Firewall ManagerはセキュリティグループやネットワークACLの一元管理ツールであり、IPトラフィックの分析ツールではありません。トラフィック分析にはVPCフローログが適しています。

C. AWS Network Manager Route Analyzerを使用して、トランジットゲートウェイルートテーブルのルートを分析します。VPCルートテーブルが正しいことを確認します。VPCフローログを使用して、セキュリティグループルールとネットワークACLルールがVPCで受け入れるか拒否するIPトラフィックを分析します。

正解 この選択肢は、トランジットゲートウェイのルーティング分析にAWS Network Manager Route Analyzerを使用し、VPCルートテーブルを手動で確認し、さらにVPCフローログを使用してIPトラフィックを分析するという、トラブルシューティングの正しいアプローチを示しています。この組み合わせにより、ルーティングの問題とセキュリティグループやネットワークACLによるトラフィックのブロックの両方を確認できます。

D. VPC Reachability Analyzerを使用して、トランジットゲートウェイルートテーブルのルートを分析します。VPCルートテーブルが正しいことを確認します。VPCフローログを使用して、セキュリティグループルールとネットワークACLルールがVPCで受け入れるか拒否するIPトラフィックを分析します。

不正解 VPC Reachability Analyzerはリソース間の到達可能性を分析するツールですが、トランジットゲートウェイのルートテーブルを分析するためのツールではありません。トランジットゲートウェイのルートテーブル分析にはAWS Network Manager Route Analyzerが適しています。VPCルートテーブルの確認とVPCフローログの使用部分は正しいアプローチです。

問われている要件

この問題では、異なるAWSリージョンにある2つのEC2インスタンス間の接続問題をトラブルシューティングするための適切なアプローチが求められています。異なるリージョン間の通信では、トランジットゲートウェイが使用されているため、トランジットゲートウェイのルーティング、VPCルーティング、セキュリティグループやネットワークACLの設定など、複数のレイヤーで問題が発生している可能性があります。

前提知識

AWSのグローバルネットワークとトランジットゲートウェイ

AWS Transit Gatewayは、VPCとオンプレミスネットワークを接続するためのネットワークハブです。トランジットゲートウェイピアリングを使用すると、異なるAWSリージョン間でトランジットゲートウェイを接続できます。これにより、複数のリージョンにわたるVPC間の通信が可能になります。

AWS Network Manager Route Analyzer

AWS Network Manager Route Analyzerは、AWS Transit Gatewayネットワーク内のトランジットゲートウェイルートテーブルを分析するためのツールです。このツールを使用すると、送信元から宛先までのルートを可視化し、接続性の問題を診断できます。Network Manager Route Analyzerはトランジットゲートウェイルートテーブルを分析するために特別に設計されています。

VPC Reachability Analyzer

VPC Reachability Analyzerは、VPC内の2つの特定のエンドポイント間の到達可能性を分析し、接続がブロックされている場合はその原因を特定するツールです。これはVPC内の接続性の問題をトラブルシューティングするのに役立ちますが、トランジットゲートウェイのルートテーブルを直接分析するものではありません。

VPCフローログ

VPCフローログは、VPC内のネットワークインターフェイスとの間で送受信されるIPトラフィックの情報をキャプチャするサービスです。これにより、セキュリティグループやネットワークACLのルールによって許可または拒否されたトラフィックを分析できます。

AWS Firewall Manager

AWS Firewall Managerは、複数のアカウントとアプリケーション全体でAWS WAF、AWS Shield Advanced、Amazon VPCセキュリティグループなどのファイアウォールルールを一元的に設定および管理するためのサービスです。これはトラフィック分析ツールではなく、セキュリティポリシーの管理ツールです。

解くための考え方

異なるリージョン間のEC2インスタンス通信アーキテクチャ

上の図は、異なるAWSリージョン間に配置された2つのEC2インスタンス間の通信アーキテクチャと、接続問題が発生した場合のトラブルシューティングアプローチを示しています。

このアーキテクチャでは、以下のコンポーネントが含まれています：

1. リージョンA（us-east-1）とリージョンB（us-west-2）
   • 各リージョンにはVPCが配置されています（VPC AとVPC B）
   • 各VPCには、EC2インスタンス、セキュリティグループ、ネットワークACL、ルートテーブルが含まれています
   • 各リージョンにはトランジットゲートウェイとそのルートテーブルがあります
2. リージョン間接続
   • トランジットゲートウェイAとトランジットゲートウェイBは、ピアリング接続によって接続されています
   • これにより、異なるリージョンのVPC間での通信が可能になります
3. トラブルシューティングステップ
   • AWS Network Manager Route Analyzerを使用してトランジットゲートウェイルートテーブルを分析
   • VPCルートテーブルを手動で確認
   • VPCフローログを使用してセキュリティグループとネットワークACLによるトラフィックの許可/拒否を分析

この接続では、異なるリージョン間の通信が行われるため、複数のコンポーネントが関与しています。問題を効果的にトラブルシューティングするためには、トランジットゲートウェイのルーティング、VPCルーティング、およびセキュリティ設定（セキュリティグループとネットワークACL）を適切なツールを使用して確認する必要があります。

AWS Network Manager Route Analyzerはトランジットゲートウェイのルートを分析するための専用ツールであり、リージョン間通信の問題を特定するのに最適です。VPCルートテーブルは手動で確認し、VPCフローログを使用してセキュリティグループやネットワークACLによるトラフィックのブロックを特定することで、エンドツーエンドの接続問題を効果的にトラブルシューティングできます。

参考資料

• AWS Network Manager Route Analyzer – Amazon VPC
• VPC フローログ – Amazon Virtual Private Cloud
• トランジットゲートウェイを使用したVPCの接続 – Amazon VPC
• リージョン間のトランジットゲートウェイピアリング接続 – Amazon VPC

正解：A, C, F

A. APNパートナーからホステッド接続をリクエストする。

正解 APNパートナーからホステッド接続をリクエストすることは、専用帯域幅を持つ接続を確立するための正しいステップです。ホステッド接続は、APNパートナーが提供するAWS Direct Connectサービスの一種で、専用の帯域幅を確保できます。

B. APNパートナーからホステッドパブリックVIFをリクエストする。

不正解 ホステッドパブリックVIFは、APNパートナーを通じて提供されるサービスですが、この場合はVPCとオンプレミスネットワーク間のプライベート通信が必要なため、パブリックVIFは適切ではありません。

C. AWS Site-to-Site VPN接続を作成する。

正解 AWS Site-to-Site VPN接続を作成することで、Direct Connect接続上でのデータの暗号化が可能になります。Direct Connect自体は暗号化を提供しないため、転送中のデータを暗号化するには、VPN接続を追加する必要があります。

D. AWS Client VPN接続を作成する。

不正解 AWS Client VPN接続は、リモートユーザーがVPCにアクセスするためのものであり、サイト間（VPCとオンプレミスデータセンター間）の接続には適していません。

E. プライベートVIFを作成する。

不正解 プライベートVIFを使用してVPCとオンプレミスネットワーク間の直接接続を確立することはできますが、Site-to-Site VPN接続では、VPNエンドポイントは公開されている必要があり、公開されたエンドポイントにアクセスするにはパブリックVIFが必要です。

F. パブリックVIFを作成する。

正解 パブリックVIFを作成することは、AWS Site-to-Site VPN接続を確立するために必要なステップです。Site-to-Site VPNでは、VPNエンドポイントは公開IPアドレスを使用するため、パブリックVIFが必要になります。

問われている要件

この問題では、以下の要件を満たすソリューションを構築する必要があります：

1. VPCとオンプレミスデータセンター間のデータ転送
2. 専用帯域幅を持つ接続
3. 転送中のデータの暗号化
4. APNパートナーとの協力による接続確立

前提知識

AWS Direct Connect

AWS Direct Connectは、オンプレミスネットワークとAWS間の専用ネットワーク接続を提供するサービスです。Direct Connectには以下の主な特徴があります：

• 専用帯域幅（50Mbpsから100Gbps）
• 一貫したネットワークパフォーマンス
• プライベートネットワーク接続
• パブリックAWSサービスへのアクセス
• 複数のVPCへの接続

ただし、Direct Connect自体は転送中のデータを暗号化しません。

Direct Connectの接続タイプ

1. 専用接続: AWS Direct Connectロケーションでお客様専用のポートを提供
2. ホステッド接続: APNパートナーを通じて提供される接続で、専用ポートの容量を共有

仮想インターフェイス（VIF）の種類

Direct Connectを設定する際、以下の種類の仮想インターフェイス（VIF）を作成できます：

1. プライベートVIF: VPCへのプライベート接続に使用
2. パブリックVIF: AWS公開サービス（S3、EC2など）へのアクセスに使用
3. トランジットVIF: AWS Transit Gatewayへの接続に使用（この選択肢には含まれていません）

AWS Site-to-Site VPN

AWS Site-to-Site VPNは、オンプレミスネットワークとAWS VPC間にIPsecトンネルを作成し、暗号化されたデータ転送を可能にするサービスです。従来のSite-to-Site VPNでは、VPNエンドポイントはパブリックIPアドレスを使用します。

解くための考え方

この問題の要件を満たすには、専用帯域幅と暗号化を組み合わせたソリューションが必要です。

1. 専用帯域幅:
   • AWS Direct Connectを使用することで、専用帯域幅の要件を満たせます。
   • APNパートナーと協力しているため、ホステッド接続が適切です。
2. データの暗号化:
   • Direct Connect自体は暗号化を提供しないため、AWS Site-to-Site VPNを追加する必要があります。
   • これにより、IPsecを使用してトラフィックを暗号化できます。
3. VPNエンドポイントの要件:
   • Site-to-Site VPNでは、VPNエンドポイントはパブリックIPアドレスを使用します。
   • そのため、パブリックVIFが必要になります。

上記の分析に基づくと、次の3つのステップが必要です：

• APNパートナーからホステッド接続をリクエスト
• AWS Site-to-Site VPN接続を作成
• パブリックVIFを作成

Direct ConnectとSite-to-Site VPNを組み合わせたアーキテクチャ

上の図は、AWS Direct ConnectとSite-to-Site VPNを組み合わせたアーキテクチャを示しています。このアーキテクチャは、問題の要件である「専用帯域幅を持つ接続」と「転送中のデータの暗号化」の両方を満たしています。

1. 専用帯域幅: APNパートナーからのホステッドDirect Connect接続により、オンプレミスデータセンターとAWS間に専用帯域幅が確保されます。
2. データの暗号化: AWS Site-to-Site VPNを使用してIPsecトンネルを確立し、転送中のデータを暗号化します。
3. パブリックVIF: Site-to-Site VPNのエンドポイントにアクセスするためにパブリックVIFが使用されます。従来のSite-to-Site VPNではVPNエンドポイントにパブリックIPアドレスが必要であるため、パブリックVIFを介してアクセスする必要があります。

したがって、この要件を満たすためには、以下の3つのステップが必要です：

• APNパートナーからホステッド接続をリクエスト（専用帯域幅のため）
• AWS Site-to-Site VPN接続を作成（データの暗号化のため）
• パブリックVIFを作成（VPNエンドポイントにアクセスするため）

この組み合わせにより、専用帯域幅と暗号化の要件を両立させたソリューションを構築できます。

参考資料

• AWS Direct Connectとは – AWS Direct Connect
• 仮想インターフェイスの作成 – AWS Direct Connect
• AWS Site-to-Site VPNとは – AWS Site-to-Site VPN
• Direct Connect と Site-to-Site VPN の組み合わせ