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

正解：C

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

不正解 Network Load Balancer（NLB）をALBの前に配置することは技術的には可能ですが、NLBは単一リージョン内で動作するサービスであり、世界中の拠点からの接続に対してグローバルなルーティング最適化は提供しません。また、リージョンごとに異なる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アドレスを提供するため、各拠点のファイアウォールではこれら2つの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. リソースが存在する各リージョンにgame.example.comのAmazon Route 53プライベートホストゾーンを作成します。各プライベートホストゾーンをそのリージョンのVPCに関連付けます。各プライベートホストゾーン内に、対応するリージョンのリソースのDNSレコードを作成します。

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

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

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

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

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

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

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

全体的な説明

問われている要件

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

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

前提知識

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

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

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

DNSサフィックス

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

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

クロスリージョンDNS解決

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

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

解くための考え方

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

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

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

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

この構成により、どのVPCからでも同じDNS名を使用してリソースにアクセスできるようになります。例えば、リージョンAのVPC内のインスタンスからdb1.game.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. ap-southeast-2（シドニー）リージョンに新しいトランジットゲートウェイを作成します。新しいトランジットゲートウェイと既存のトランジットゲートウェイをピアリングします。既存のSite-to-Site VPN接続を変更し、新しいトランジットゲートウェイをターゲットゲートウェイとして設定します。

不正解 : 新しいトランジットゲートウェイをap-southeast-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はバーチャルプライベートゲートウェイではなく、トランジットゲートウェイをターゲットとする場合にのみ設定可能です。

新しいトランジットゲートウェイをap-southeast-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を使用してクラウドリソースの現在の状態を継続的に記録します。金融規制のセキュリティ要件を反映するConfig Rulesを作成します。非準拠リソースに対する自動修復アクションを設定します。

正解 – 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ゲートウェイは時間単位料金と処理データ量に応じた料金が発生するため、既に導入済みのファイアウォールアプライアンスのNAT機能を活用しない分、不必要なコストが生じます。

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機能を活用している点はコスト効率的ですが、ロードバランサーに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 フローログの使用