SAP-#80

AWS Service Catalog

AWS Service Catalog を使用することで、ユーザーは他のサービスを起動する権限がなくても、新しい環境を簡単に起動できるため正解です。

AWS Service Catalog は、管理者が定義した製品テンプレートから環境を簡単に起動できるようにするサービスです。これにより、テスターが自分の環境を起動できるようになりますが、各ユーザーに幅広いアクセス許可を付与することはありません。AWS Service Catalog を使用して、品質保証 (QA) 部門のユーザーに AWS Service Catalog API のみを使用する許可を与えることができます。これにより、QA 部門のユーザーは、AWS Service Catalog コンソールから環境テンプレートを簡単に起動できます。

※AWS Service Catalog
AWS Service Catalog では、AWS での使用が承認された IT サービスのカタログを作成および管理できます。この IT サービスには、仮想マシンイメージ、サーバー、ソフトウェア、データベース、さらに包括的な多層アプリケーションアーキテクチャまで、あらゆるものが含まれます。AWS Service Catalog により、デプロイ済みの IT サービスやアプリケーション、リソース、さらにメタデータを、一元的に管理できるようになります。一貫したガバナンスを実現して、コンプライアンス要件を満たすために役立ちます。また、ユーザーが必要とする中で、承認済みの IT サービスのみをすばやくデプロイできるようにします。各組織は、AWS Service Catalog の AppRegistry により、各 AWS リソースでのアプリケーションの配置状況を把握できます。 アプリケーションと、そのメタデータを定義および管理することで、コスト、パフォーマンス、セキュリティ、コンプライアンス、運用状態などを、アプリケーションレベルで追跡することが可能です。

AWS Service Catalog を使用する組織は、一元的な場所から、IT サービスのカタログを集中管理できます。AWS Service Catalog では、利用できる IT サービスとそのバージョンや、提供されたサービスでの設定内容を制御できます。さらに個人、グループ、部門、コストセンター別に、アクセス許可を付与する対象の管理も行えます。
参考URL : AWS Service Catalog

■以下は間違いです。
他の選択肢は、承認されたスタックのみを起動するようにユーザーを制約しないため間違いです。

・環境テンプレートから AWS Elastic Beanstalk アプリケーションを作成します。QA 部門のユーザーに、ElasticBeanstalk のアクセス許可のみを使用するアクセス許可を付与します。Elastic Beanstalk CLI で、既存のロールをサービスロールとして環境に渡し、Elastic Beanstalk 環境を起動するようにユーザーを訓練します。
→AWS Elastic Beanstalk は、この問題に対して最も適切なサービスではありません。

AWS Elastic Beanstalk はアプリケーションのデプロイと運用を簡素化するサービスであり、この問題の目的である「テスターが自分の環境を起動できるようにすること」に対して最も適切なサービスではありません。

・AWS CloudFormation テンプレートを Amazon S3 にアップロードします。QA 部門のユーザーに CloudFormation と S3 の API を使用するためのアクセス許可を付与え、その許可をテンプレートとそれが作成するリソースに制限する条件を付与します。CloudFormation コンソールからテンプレートを起動するようにユーザーを訓練します。
→QA 部門のユーザーに CloudFormation と S3 の API を使用するためのアクセス許可を付与すると、アクセス権限が広範囲になりすぎるため間違いです。

・AWS CloudFormation テンプレートを Amazon S3 にアップロードします。QA 部門のユーザーに、マネージャーのロールを引き受ける権限を与え、テンプレートとそれが作成するリソースへの権限を制限するポリシーを追加します。CloudFormation コンソールからテンプレートを起動するようにユーザーを訓練します。
→ユーザーにマネージャーのロールを引き継ぐ権限を与えることで、アクセス許可が広範囲になりすぎるため間違いです。

AWS Schema Conversion Tool(AWS SCT)

異種データベースの移行には AWS Schema Conversion Tool (AWS SCT) が必要であり、AWS Database Migration Service (AWS DMS) を使用して、継続的なデータ同期が実行できます。これにより、ダウンタイムを最小限に抑えることができます。

異種データベースの移行プロセスでは、まず、AWS Schema Conversion Tool (AWS SCT) を使用してスキーマスクリプトを生成し、移行前にそれらをターゲットに適用します。次に、AWS Database Migration Service (AWS DMS) を使用して、オンプレミスのデータベースから AWS へのデータ移行を開始します。最初のデータコピーが完了した後、新しいデータベースに切り替えるまで、AWS DMS を使用してデータベースの同期を維持し続けます。最後に、AWS SCT を使用して、アプリケーションに組み込まれている SQL コードと、手動で実行する必要があるものを特定します。この方法を使用することで、必要な作業量と時間を最小限に抑えつつ、移行を実行することができます。

※AWS DMS と AWS SCT を使用して Oracle データベースを Amazon Aurora MySQL に移行する
・AWS DMS : AWS Database Migration サービス (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、他の種類のデータストアを移行するのに役立ちます。AWS DMS を使用して、オンプレミスのインスタンス間 (AWS クラウドセットアップを使用)、またはクラウドセットアップとオンプレミスセットアップの組み合わせの間で、AWS クラウドにデータを移行できます。
・AWS SCT : AWS Schema Conversion Tool(AWS SCT) は、データベースエンジン間でデータベーススキーマを変換するために使用されます。
参考URL : AWS DMS と AWS SCT を使用して Oracle データベースを Amazon Aurora MySQL に移行する

■以下は間違いです。
・AWS DMS を使用して、データベースエンジンを Amazon EC2 に直接インストールするか、Amazon RDS に移行するか、最適なターゲットデプロイを特定します。次に、AWS DMS を使用してプラットフォームに移行します。AWS Application Discovery Service を使用して、アプリケーションに組み込まれている SQL コードと、手動で実行する必要があるものを特定します。
・AWS DMS を使用して、オンプレミスのデータベースから AWS へのデータ移行を開始します。最初のコピーの後、新しいデータベースに切り替わるまで、AWS DMS を使用してデータベースの同期を維持し続けます。AWS Application Discovery Service を使用して、アプリケーションに組み込まれている SQL コードと、手動で実行する必要があるものを特定します。
→異種データベースの移行には AWS Schema Conversion Tool (AWS SCT) が必要であり、これらの選択肢では AWS SCT の使用が言及されていないため間違いです。

・AWS SCT を使用してスキーマスクリプトを生成し、移行前にそれらをターゲットに適用します。AWS DMS を使用して、現在のスキーマを分析し、最適なデータベースエンジンの推奨事項を提供します。次に、AWS DMS を使用して推奨エンジンに移行します。AWS SCT を使用して、アプリケーションに組み込まれている SQL コードと、手動で実行する必要があるものを特定します。
→AWS SCT と AWS DMS の使用が含まれていますが、変換先のデータベースエンジンが既に決まっているため、最適なデータベースエンジンの推奨事項を提供する必要はありません。この不要なステップが含まれているため間違いです。

サービスコントロールポリシー (SCP)

サービスコントロールポリシー (SCP) を使用することで、メンバーアカウントに対してリザーブドインスタンスの購入を拒否することができます。これには、AWS Organizations ですべての機能を有効にする必要があります。

すべての AWS アカウントが、すべての機能が有効になっている AWS Organizations 構造の一部であることを確認することで、組織全体に対して一元的なポリシーを適用することが可能になります。これにより、SCP を使用してリザーブドインスタンスの購入や変更に関する制限を実施することができます。

ec2:PurchaseReservedInstancesOffering および ec2:ModifyReservedInstances のアクションに対する拒否ルールを含む SCP を作成し、AWS Organizations 構造の各組織単位 (OU) に SCP をアタッチすることで、組織内のすべてのアカウントに対してリザーブドインスタンスの購入および変更を制限することができます。これにより、専門のチームを通じたリザーブドインスタンスの調達や実行の要求プロセスが強制されます。

※サービスコントロールポリシー (SCP)
サービスコントロールポリシー (SCP) は、組織のアクセス許可の管理に使用できる組織ポリシーの一種です。SCP では、組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御できます。SCP は、アカウントが組織のアクセスコントロールガイドラインに従っていることを確認するのに役立ちます。SCP は、すべての機能が有効になっている 組織でのみ使用できます。組織が一括請求機能のみを有効にしている場合、SCP は使用できません。

組織のアカウントにアクセス許可を付与するには、SCP だけでは不十分です。SCP によってアクセス許可を付与することはできません。SCP は、影響を受けるアカウントの IAM ユーザーおよびロールに対しアカウントの管理者が委任するアクションのために、ガードレールを定義するか制限を設定します。管理者は、アイデンティティベースのポリシーまたはリソースベースのポリシーを IAM ユーザーまたはロール、またはアカウントのリソースに割り当てて、実際にアクセス許可を付与する必要があります。有効なアクセス許可とは、SCP によって許可されるアクセスと IAM およびリソースベースのポリシーによって許可されるアクセスの間の論理的な交点のことです。
参考URL : サービスコントロールポリシー (SCP)

※PurchaseReservedInstancesOffering
アカウントで使用するリザーブドインスタンスを購入します。リザーブドインスタンスを使用すると、オンデマンドインスタンスの料金に比べて低い時間料金を支払うことになります。
参考URL : PurchaseReservedInstancesOffering

■以下は間違いです。
・すべての AWS アカウントが、一括請求機能が有効になっている AWS Organizations 構造の一部であることを確認します。
→一括請求 (コンソリデーティッドビリング) は共有課金機能を提供しますが、組織全体のリザーブドインスタンスの購入制限を実施する AWS Organizations の高度な機能は含まないため間違いです。
参考URL : 一括請求 (コンソリデーティッドビリング)

・各 AWS アカウントで、ec2:PurchaseReservedInstancesOffering と ec2:ModifyReservedInstances アクションへの DENY ルールを持つ IAM ポリシーを作成します。
→リザーブドインスタンスの購入や変更を制限するためには、サービスコントロールポリシー (SCP) を使用する必要があり、個別の IAM ポリシーでは組織全体の制御ができないため間違いです。

・AWS Config を使用して、ec2:PurchaseReservedInstancesOffering と ec2:ModifyReservedInstances アクションへのアクセスを拒否する IAM ポリシーのアタッチについてレポートします。
→AWS Config は、設定内容、相互の関連、時間の経過とともに設定と関係がどのように変化するかなど、AWS アカウントに関連付けられたリソースの詳細を提供しますが、リザーブドインスタンスの購入を直接制限する機能は提供していません。このため、リザーブドインスタンスの購入や変更を制限する目的には適していません。

DynamoDB Auto Scaling によるスループット容量の自動管理

Amazon DynamoDB Auto Scaling がプロビジョニングされたスループット容量を需要に応じて改善し、応答時間を改善するためであり、AWS Lambda の例外が主に Amazon DynamoDB によるものであるため、これを改善することが AWS Lambda のパフォーマンス改善につながります。

Amazon DynamoDB Auto Scaling は、需要に応じてプロビジョニングされたスループット容量を適切にスケーリングする機能であり、これにより、ウェブアプリケーションのレスポンス時間を改善します。この問題では、AWS Lambda 関数のエラーが主に Amazon DynamoDB によるものであることが示されています。したがって、Amazon DynamoDB Auto Scaling を実装することで、DynamoDB への呼び出しのパフォーマンスが向上し、結果として AWS Lambda のパフォーマンスも改善されます。これにより、応答時間が短縮され、ウェブアプリケーションのパフォーマンスが向上します。

※DynamoDB Auto Scaling によるスループット容量の自動管理
多くのデータベースワークロードは本質的に循環的なものであり、そうでない場合は前もって予測することは困難です。例えば、日中の時間帯に大部分のユーザーがアクティブなソーシャルネットワーキングアプリがあるとします。データベースは日中のアクティビティを処理できる必要がありますが、夜間のスループットに同じレベルは必要ありません。別の例としては、急速に導入された新しいモバイルゲームアプリが挙げられます。ゲームがあまりに人気になると、利用可能なデータベースリソースを超過し、パフォーマンスが低下して顧客が不満を感じるようになります。この種のワークロードでは多くの場合、手動介入によってデータベースリソースを使用レベルに応じて上下させる必要があります。

Amazon DynamoDB Auto Scaling は AWS Application Auto Scaling サービスを使用し、実際のトラフィックパターンに応じてプロビジョンドスループット性能をユーザーに代わって動的に調節します。これにより、テーブルまたはグローバルセカンダリインデックスで、プロビジョンされた読み込みおよび書き込み容量が拡張され、トラフィックの急激な増加をスロットリングなしに処理できるようになります。ワークロードが減ると、Application Auto Scaling はスループットを低下させ、未使用のプロビジョンされた容量に料金が発生しないようにします。
参考URL : DynamoDB Auto Scaling によるスループット容量の自動管理

■以下は間違いです。
・より適切にパーティション化されたプライマリインデックスを使用して DynamoDB テーブルを再作成します。
→現在のパーティション化されたキーに問題があるかどうかが記載されていないため間違いです。

この問題では、AWS Lambda 関数のエラーが主に Amazon DynamoDB によるものであることが示されており、パーティション化されたキーの問題に関する言及はありません。

・Lambda 関数の同時実行数の制限を増やします。
・API Gateway のスロットリング制限を増やします。
→スロットリングが主要な問題ではないため間違いです。

問題文によると、API Gateway でエラーが発生しており、AWS Lambda 関数のエラーが Amazon DynamoDB への呼び出しに関連していることがわかります。スロットリング制限を増やすことや Lambda 関数の同時実行数の制限を増やすことは、根本的な問題である Amazon DynamoDB のパフォーマンスに対処するものではありません。

Amazon S3 ファイルゲートウェイ

Amazon S3 ファイルゲートウェイを使用することで、SMB プロトコルをサポートし、データを Amazon S3 にシームレスにコピーする方法を提供するため正解です。

オンプレミスの Microsoft SQL Serverデータベースからのエクスポートデータを Amazon S3 にバックアップするために、Amazon S3 ファイルゲートウェイを使用しています。Amazon S3 ファイルゲートウェイは、オンプレミス環境と Amazon S3 との間でデータ転送をシームレスに行うことができるため、最も効率的なソリューションです。また、SMB プロトコルをサポートしているため、既存のワークロードに対して容易に統合することができます。

※Amazon S3 ファイルゲートウェイ
Amazon S3 ファイルゲートウェイは Amazon Simple Storage Service (Amazon S3) へのファイルインターフェイスをサポートし、サービスと仮想ソフトウェアアプライアンスを組み合わせます。この組み合わせを使用することで、ネットワークファイルシステム (NFS) やサーバーメッセージブロック (SMB) などの業界標準のファイルプロトコルを使用して、Amazon S3 でオブジェクトを保存および取得できます。ソフトウェアアプライアンス、またはゲートウェイは、VMware ESXi、Microsoft Hyper-V、または Linux カーネルベースの仮想マシン (KVM) ハイパーバイザーで実行される仮想マシン (VM) として、オンプレミス環境にデプロイされます。ゲートウェイは、S3 内のオブジェクトへのアクセスをファイルまたはファイル共有のマウントポイントとして提供します。
参考URL : Amazon S3 ファイルゲートウェイ

■以下は間違いです。
・新しい S3 バケットを作成します。Direct Connect 接続に接続されている VPC 内に AWS Storage Gateway ボリュームゲートウェイをデプロイします。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートをボリュームゲートウェイの新しい SMB ファイル共有に書き込み、このデータの S3 バケットへのコピーを自動化します。
→AWS Storage Gateway のボリュームゲートウェイは、iSCSI プロトコルを使用して、アプリケーションのブロックストレージボリュームを表示します。SMB プロトコルはサポートしていないため間違いです。

ボリュームゲートウェイは、iSCSI プロトコルを使用してアプリケーションにブロックストレージボリュームを提供します。これらのボリュームに書き込まれたデータは、ボリュームのポイントインタイムスナップショットとして非同期にバックアップされ、Amazon EBS スナップショットとしてクラウドに保存することができます。ただし、このアプローチでは SMB プロトコルをサポートしていないため、Microsoft SQL Serverデータベースからのエクスポートデータを Amazon S3 にバックアップする目的には適していません。
参考URL : ボリュームゲートウェイ

・Direct Connect 接続に接続されている VPC 内に、Amazon FSx for Windows File Server シングル AZ ファイルシステムを作成します。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートを Amazon FSx ファイルシステムの SMB ファイル共有に書き込みます。夜間のバックアップを有効にします。
・Direct Connect 接続に接続されている VPC 内に、Amazon FSx for Windows File Server マルチ AZ ファイルシステムを作成します。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートを Amazon FSx ファイルシステムの SMB ファイル共有に書き込みます。夜間のバックアップを有効にします。
→Amazon FSx for Windows File Server が Windows サーバー上に構築されたフルマネージド共有ストレージを提供するものであり、Amazon S3 にデータを直接コピーするものではないため間違いです。

Amazon FSx for Windows File Server は、Windows ベースの共有ストレージソリューションを提供し、データアクセス、データ管理、および管理機能をサポートします。しかし、このサービスは Amazon S3 にデータを直接バックアップする機能を提供していません。そのため、オンプレミスの Microsoft SQL Serverデータベースからのエクスポートデータを Amazon S3 にバックアップする目的には適していません。
参考URL : Amazon FSx for Windows File Server

Amazon Route 53 でのハイブリッドネットワークの統合 DNS 解決の設定

Route 53 Resolver とアウトバウンドエンドポイントを VPC とオンプレミス間の DNS 解決に使用できるため正解です。

この選択肢では、Amazon Route 53 Resolver とアウトバウンドエンドポイントを使用して、オンプレミスの DNS サーバーと VPC 内の AWS サービス間で DNS リクエストの解決が可能になります。これにより、AWS サービスが VPC の DNS 用 Route 53 Resolver に転送され、オンプレミスの DNS サーバーがアドレスを解決できるようになります。

アウトバウンドエンドポイントを VPC にアタッチし、セキュリティグループがポート 53 上のオンプレミスの DNS サーバーの IP アドレスにアクセスできるようにすることで、Amazon EC2 インスタンスがネイティブの Route 53 エンドポイントを使用してオンプレミスの DNS リクエストを解決できるようになります。また、オンプレミスの指定されたトラフィックをオンプレミスの DNS サーバーにルーティングするために、新しい Route 53 Resolver ルールを作成します。このルールにより、VPC とオンプレミス間の DNS 解決が効率的に行われます。

※Amazon Route 53 でのハイブリッドネットワークの統合 DNS 解決の設定
このパターンでは、完全にハイブリッドなドメインネームシステム (DNS) アーキテクチャをセットアップする方法について説明します。このアーキテクチャでは、オンプレミスのリソース、AWS リソース、インターネット DNS クエリのエンドツーエンドの DNS 解決を、管理オーバーヘッドなしで実行できます。このパターンは、Amazon Route 53 Resolver 転送ルールを設定する方法について説明します。このルールにより、AWS から発信された DNS クエリの送信先がドメイン名に基づいて決定されます。オンプレミスリソースの DNS クエリは、オンプレミス DNS リゾルバーに転送されます。AWS リソースの DNS クエリとインターネット DNS クエリは、Route 53 リゾルバによって解決されます。


・Amazon Route 53 Resolver : Amazon Route 53 Resolver は、ハイブリッドクラウド全体にわたってシームレスな DNS クエリ解決を可能にすることで、エンタープライズのお客様のハイブリッドクラウドを容易にします。オンプレミスのデータセンターと VPC の間にある DNS 名前空間を解決するために、DNS エンドポイントと条件付き転送ルールを作成できます。

・Amazon Route 53 プライベートホストゾーン : プライベートホストゾーンは、Amazon VPC サービスで作成する 1 つ以上の VPC 内のドメインとそのサブドメインへの DNS クエリに対し、Route 53 がどのように応答するかに関する情報を保持するコンテナです。

※Route 53 Resolver エンドポイントの設定
・アウトバウンドエンドポイントを作成します。
→Route 53 リゾルバーは、アウトバウンドエンドポイントを使用して DNS クエリをオンプレミス DNS リゾルバーに送信します。

※転送ルールを設定し、VPC に関連付ける
・オンプレミスドメインの転送ルールを作成します。
→このルールは、オンプレミスドメイン (onprem.mydc.com など) の DNS クエリをオンプレミス DNS リゾルバーに転送するように Route 53 リゾルバーに指示します。このルールを作成するには、オンプレミスの DNS リゾルバーの IP アドレスと、Route 53 リゾルバーのアウトバウンドエンドポイント ID が必要です。
参考URL : Amazon Route 53 でのハイブリッドネットワークの統合 DNS 解決の設定

■以下は間違いです。
・オンプレミスのドメインと同じドメイン名で、Route 53 に新しいプライベート DNS ゾーンを作成します。オンプレミスの DNS サーバーの IP アドレスをレコードのアドレスとして使用して、単一のワイルドカードレコードを作成します。
→これだけでは VPC とオンプレミス間の DNS 解決が効率的に行われることはありません。また、ワイルドカードレコードを作成することも効率的な解決策とはなりません。

・DNS BIND がインストールされ設定された EC2 インスタンスを起動します。EC2 インスタンスのセキュリティグループが、ポート 53 のオンプレミスの DNS サーバーの IP アドレスにアクセスできることを確認します。DNS クエリをオンプレミスの DNS サーバーの IP アドレスに転送するように BIND を設定します。移行した各 EC2 インスタンスの DNS 設定を、BIND サーバーの IP アドレスを指すように設定します。
→DNS BIND を使用した EC2 インスタンスを起動することは、AWS のネイティブサービスである Route 53 を利用しないため間違いです。

・オンプレミスの DNS サーバーの IP アドレスを指すように VPC DHCP オプションセットを構成します。EC2 インスタンスのセキュリティグループが、それらの DNS サーバーの IP アドレス上のポート 53 へのアウトバウンドアクセスを許可していることを確認します。
→VPC DHCP オプションセットを使用してオンプレミスの DNS サーバーの IP アドレスを指すことは、DNS リクエストを効率的に解決しないため間違いです。

地理的一致ルールステートメント

AWS WAF の地理的一致ルールを使用して、選択された国からのトラフィックを制限し、他の国をブロックすることができます。さらに、ブロックされたリクエストをログに記録する機能があるため正解です。

AWS WAF は、AWS が提供する Web アプリケーションファイアウォールです。地理的一致ルールを使用して、選択された国からのトラフィックを制限し、他の国からのトラフィックをブロックすることができます。これにより、特定の国からのユーザーのみがアプリケーションにアクセスできるようになります。

また、AWS WAF は、ブロックされたリクエストをログに記録する機能を持っています。これにより、企業がブロックされたアクセス要求を追跡し、分析することができます。

正解の理由は、以下の通りです :

1.AWS WAF を使用して、選択された国からのトラフィックを制限し、他の国をブロックすることができます。
2.AWS WAF は、ブロックされたリクエストをログに記録する機能があります。
3.AWS WAF は、ALB に関連付けられるため、メンテナンスが最小限に抑えられます。

※地理的一致ルールステートメント
AWS WAF は、Amazon CloudFront 配信、Amazon API Gateway REST API、Application Load Balancer、または AWS AppSync GraphQL API に転送される HTTP および HTTPS リクエストをモニタリングするためのウェブアプリケーションファイアウォールです。AWS WAF では、コンテンツへのアクセスを制御することもできます。リクエストの送信元の IP アドレスやクエリ文字列の値など、指定した基準に基づいて、Amazon CloudFront、Amazon API Gateway、Application Load Balancer、または AWS AppSync は、リクエストされたコンテンツまたは HTTP 403 ステータスコード (禁止) のいずれかでリクエストに応答します。リクエストがブロックされたときにカスタムエラーを返すように CloudFront を設定することもできます。

送信元の国に基づいてウェブリクエストを許可またはブロックするには、1 つ以上の地理的 (Geo) 一致ステートメントを作成します。

これを使用すると、特定の国からのサイトへのアクセスをブロックしたり、特定の国からのアクセスのみを許可したりすることができます。一部のウェブリクエストを許可し、それ以外のウェブリクエストを送信元の国に基づいてブロックする場合は、許可する国に Geo 一致ステートメントを追加し、ブロックする国に 2 つ目のステートメントを追加します。

Geo 一致ステートメントを他の AWS WAF ステートメントとともに使用すると、高度なフィルターを作成できます。例えば、特定の国をブロックするが、その国の特定の IP アドレス群からのリクエストを許可するには、アクションを Block に設定し、次のネストされたステートメントを使用してルールを作成します。

・AND ステートメント
* ブロックする国をリストした Geo 一致ステートメント
NOT ステートメント
** 許可する IP アドレスを指定する IP セットステートメント
参考URL : 地理的一致ルールステートメント

■以下は間違いです。
・指定した国から発信されていないリクエストをブロックするように AWS Shield を設定します。AWS Shield を ALB に関連付けます。
→AWS Shield は DDoS 保護サービスであり、地理的な制限機能は提供していないため間違いです。

AWS Shield は、AWS が提供するマネージド型の分散サービス妨害 (DDoS) に対する保護サービスで、AWS で実行しているアプリケーションを保護します。しかし、AWS Shield は地理的な制限機能を提供していません。そのため、特定の国からのユーザーのみがアプリケーションにアクセスできるように制限する目的には適していません。

※AWS Shield とは何ですか ?
AWS Shield は、AWS で実行されるアプリケーションを DDoS 攻撃から保護するマネージド型のサービスです。AWS Shield Standard は、すべてのお客様に対し追加料金なしで自動的に有効化されます。AWS Shield Advanced は任意で利用できる有料サービスです。AWS Shield Advanced により、Amazon EC2、Elastic Load Balancing (ELB)、Amazon CloudFront、AWS Global Accelerator、Route 53 で実行中のアプリケーションを標的とする、高度化された大規模な攻撃からの保護が強化されます。
参考URL : Q: AWS Shield とは何ですか ?

・指定した国に属する IP 範囲のリストを含む IPSet を作成します。AWS WAF のウェブ ACL を作成します。IPSet 内の IP 範囲から発信されていないリクエストをブロックするルールを設定します。ルールをウェブ ACL に関連付けます。ウェブ ACL を ALB に関連付けます。
・指定した国に属する IP 範囲からのポート 80 と 443 を許可するセキュリティグループのルールを作成します。そのセキュリティグループを ALB に関連付けます。
→IPSet およびセキュリティグループを使用しても、地理的な場所に基づくトラフィックの制御が煩雑になり、ブロックされたリクエストのログ記録ができないため間違いです。

指定した国に属する IP 範囲のリストを含む IPSet やセキュリティグループのルールを作成して、地理的な場所に基づいてトラフィックを制御しようとしています。しかし、この方法では、IP 範囲のリストを定期的に更新する必要があり、メンテナンスが煩雑になります。
さらに、IPSet およびセキュリティグループを使用しても、ブロックされたリクエストをログに記録する機能が提供されていません。この要件は、AWS WAF を使用することで満たすことができます。