以下は、提供された「問題1」に基づいたSAP形式の整理です。
■ 問題文（文字列を編集せずに出力）
ある企業は、AWS Organizations の企業組織内の開発者アカウント間で、AWS のデータ転送コストとコンピュートコストを最適化したいと考えています。開発者は VPC を構成し、単一の AWS リージョンで Amazon EC2 インスタンスを起動できます。EC2 インスタンスは、Amazon S3 から毎日約 1 TB のデータを取得します。
開発者の活動は、EC2 インスタンスと S3 バケット間の毎月のデータ転送料と NAT ゲートウェイ使用料、そして高いコンピューティングコストにつながります。同社は、開発者が AWS アカウント内にデプロイする EC2 インスタンスと VPC インフラストラクチャに対して、承認されたアーキテクチャパターンを積極的に適用したいと考えています。同社は、この強制が開発者がタスクを実行する速度に悪影響を及ぼすことを望んでいません。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力）
A
SCP を作成して、開発者が未承認の EC2 インスタンスタイプを起動できないようにします。開発者に AWS CloudFormation テンプレートを提供し、承認された VPC 構成と S3 インターフェイスエンドポイントをデプロイします。開発者が CloudFormation でのみ VPC リソースを起動できるように、開発者の IAM 権限の範囲を設定します。
B
AWS Budgets を使用して毎日の予測予算を作成し、開発者アカウント全体の EC2 コンピューティングコストと S3 データ転送コストを監視します。予測コストが実際の予算コストの 75% になった場合、開発者チームにアラートを送信します。実際の予算コストが 100% の場合は、開発者の EC2 インスタンスと VPC インフラストラクチャを終了する予算アクションを作成します。
C
S3 ゲートウェイエンドポイントと承認された EC2 インスタンスで承認された VPC 構成を作成するために、ユーザーが使用できる AWS Service Catalog のポートフォリオを作成します。開発者アカウントとポートフォリオを共有します。AWS Service Catalog の起動制約を構成して、承認された IAM ロールを使用します。開発者の IAM 権限の範囲を設定して、AWS Service Catalog へのアクセスのみを許可します。
D
AWS Config ルールを作成およびデプロイして、開発者 AWS アカウントの EC2 および VPC リソースのコンプライアンスを監視します。開発者が未承認の EC2 インスタンスを起動した場合、または開発者が S3 ゲートウェイエンドポイントなしで VPC を作成した場合は、修復アクションを実行して未承認のリソースを終了します。
■ 問題文の要件の概要
- 毎日1TBのS3からのデータ取得があり、転送コスト・NAT料金・高いコンピュート費用が発生
- 開発者が承認済みの構成のみ利用するよう強制したい
- ただし、開発者の作業スピードに影響を与えたくない
- 最もコスト効率の良い方法を選択することが求められている
■ 正解の選択肢と解説
正解：C
解説：
AWS Service Catalog を使えば、あらかじめ承認された VPC と EC2 構成（例：S3 ゲートウェイエンドポイント付き）をテンプレート化し、開発者はその中からしか起動できないように制限できます。
これにより、転送コスト（NAT経由回避）と高価なインスタンス利用の抑止が可能となり、コスト削減とスピードの両立が実現されます。
■ 不正解の選択肢の理由
A：
CloudFormation と SCP だけでは、開発者が意図的にテンプレートを使わない可能性があり、確実性に欠ける。また、S3インターフェイスエンドポイントはコストが発生し、目的であるコスト最適化に逆行する恐れもある。
B：
AWS Budgets は事後的な対応策であり、予算到達後に開発を停止するリスクがある。アーキテクチャを強制することができず、本質的な解決になっていない。
D：
AWS Config も事後検知のツールであり、評価と修復にタイムラグがある。既に発生したコストを取り戻すことはできず、リアルタイムの防止策にはならない。
■ SAP試験で押さえておくべきポイント
- AWS Service Catalog は、事前に承認されたリソースのみを提供するためのガバナンストール。強制的に最適構成を使用させたい場合に有効。
- S3 Gateway Endpoint を使用することで、VPC内通信により転送コストを回避可能（NAT不要、転送料金無料）。
- Budgets や Config は事後対応の仕組みであり、SAP試験では「事前ガバナンス vs 事後是正」を見極める力が重要。
- SCP（Service Control Policy） は Organizations 単位でのアクセス制御だが、テンプレートの強制やコスト削減構成までは保証しない。
- コスト最適化と開発スピードの両立には、テンプレート強制 + 柔軟な起動手段の提供（Service Catalog）が最善。
次の問題も準備ができましたら、同様に貼り付けてください。引き続き解説をお手伝いします。
以下に、問題2を指定の形式で整理・解説いたします。
◆ 問題文（編集せずにそのまま記載）
ある企業は AWS 上でアプリケーションを実行しています。同社は複数の異なるソースからデータを収集しています。同社は独自のアルゴリズムを使用してデータ変換と集計を実行しています。ETL 処理を行った後、Amazon Redshift のテーブルに結果を保存します。同社はこのデータを他社に販売します。同社は、Amazon Redshift のテーブルからデータをファイルとしてダウンロードし、FTP を使用して複数のお客様にファイルを送信します。お客様の数は大幅に増加して、管理が難しくなってきました。
同社は、AWS Data Exchange を使用して、お客様とデータを共有するために使用できるデータ製品を作成します。同社は、データを共有する前にお客様の身元を確認したいと考えています。また、同社がデータを公開する際、お客様は最新のデータにアクセスする必要があります。
これらの要件を、運用上のオーバーヘッドを最小限に抑えながら満たすソリューションを選択してください。
◆ 選択肢（編集せずにそのまま記載）
A.
AWS Data Exchange for API を使用して、お客様とデータを共有します。サブスクリプションの検証を構成します。データを生成する会社の AWS アカウントで、Amazon Redshift との Amazon API Gateway Data API サービス統合を作成します。お客様にデータ製品へのサブスクライブを要求します。
B.
データを生成する会社の AWS アカウントで、AWS Data Exchange を Redshift クラスターに接続して、AWS Data Exchange データ共有を作成します。サブスクリプションの検証を構成します。お客様にデータ製品へのサブスクライブを要求します。
C.
Amazon Redshift テーブルから Amazon S3 バケットに定期的にデータをダウンロードします。AWS Data Exchange for Amazon S3 を使用してお客様とデータを共有します。サブスクリプションの検証を構成します。お客様にデータ製品へのサブスクライブを要求します。
D.
Amazon Redshift データを AWS Data Exchange のオープンデータに公開します。AWS Data Exchange のデータ製品にサブスクライブするようにお客様に要求します。データを作成する会社の AWS アカウントで、検証済みの AWS アカウントにのみアクセスを許可するために、Amazon Redshift テーブルに IAM リソースベースのポリシーをアタッチします。
◆ 問題文の要件の概要
- 複数の顧客に販売する Redshift データの配信を効率化したい
- 顧客の身元確認（サブスクリプション検証）を行いたい
- データは常に最新である必要がある
- 運用負荷（ファイル配布・FTP管理など）を最小限にしたい
◆ 正解の選択肢と解説
正解：B
理由：
AWS Data Exchange for Amazon Redshift を使えば、Redshift のデータ共有機能を利用して、ETL 処理済みのテーブルをリアルタイムに配信できます。
また、Data Exchange のサブスクリプション検証機能により、顧客の事前確認も自動化されます。
運用面では、ファイル出力・FTP転送などの作業が不要となり、Redshift クラスタと Data Exchange の統合で データの即時反映・共有管理・アクセス制御が一元化されるため、非常に効率的です。
◆ 不正解の選択肢の理由
A：API経由の共有
- AWS Data Exchange for API は REST API による JSON 形式の公開手段であり、Redshift のデータセットそのものを効率よく提供できない。
- Data API や API Gateway との連携は構築・保守が必要で、運用負荷が高い。
C：S3 経由のファイル配信
- Redshift → S3 の定期エクスポートは、リアルタイム性に欠ける（更新遅延あり）。
- さらに、バッチ処理・ストレージ管理が必要で、オーバーヘッドが大きい。
D：オープンデータでの公開
- Data Exchange のオープンデータ機能では、サブスクリプション検証ができないため、顧客制限が不可能。
- セキュリティやライセンス管理が求められる有料サービスには不適切。
◆ SAP試験で押さえておくべきポイント
- AWS Data Exchange は S3 / API / Redshift 向けに製品タイプがあり、それぞれの 利用目的・特性を理解することが重要
- Redshift との統合製品では、データを 即時共有できるため、「最新データアクセス」が求められるシナリオに最適
- サブスクリプション検証（Subscription Verification） を使えば、顧客制限・承認制配布が可能（B2B向けに重要）
- オープンデータ公開は自由アクセスであり、セキュリティやライセンス制御を必要とするシナリオには不向き
- 選択肢が似ていても Data Exchange の製品タイプや更新頻度、運用負荷の違いを見極めるのが合格のカギ
次の問題も、同様の形式で整理しますので、引き続き送ってください。
以下は、問題3の要件整理と詳細な解説です。
■ 問題文（原文のまま）
企業は、仮想プライベートクラウド (VPC) 内の Amazon EC2 インスタンスを使用して、新しいプライベートなイントラネットサービスを導入したいと考えています。VPC は、AWS Site-to-Site VPN を使用して、会社のオンプレミスネットワークに接続されています。新しいサービスは、すでに導入されているオンプレミスのサービスと通信する必要があります。オンプレミスのサービスは、会社が所有するホスト名を使用してアクセスします。例えば、DNS ゾーンです。この DNS ゾーンは完全にオンプレミスであり、会社のプライベートネットワーク経由でのみアクセス可能です。
新しいサービスを現在のサービスに接続するには、ソリューションアーキテクトは、新しいサービスが会社の example ドメインのホスト名を解決できることを保証する必要があります。
これらの基準を満たすソリューションを選択してください。
■ 選択肢（編集なし）
A.
Amazon Route 53 で company.example のための空のプライベートゾーンを作成します。会社のオンプレミス company.example ゾーンに、Route 53 の新しいプライベートゾーンの権限のあるネームサーバーを指す追加の NS レコードを追加します。
B.
VPC の DNS ホスト名を有効にします。Amazon Route 53 Resolver を使用して新しいアウトバウンドエンドポイントを設定します。company.example へのリクエストをオンプレミスのネームサーバーに転送するための Resolver ルールを作成します。
C.
VPC の DNS ホスト名を有効にします。Amazon Route 53 Resolver を使用して新しいインバウンドリゾルバーエンドポイントを設定します。company.example のリクエストを新しいリゾルバーに転送するようにオンプレミスの DNS サーバーを構成します。
D.
AWS Systems Manager を使用して、必要なホスト名を含む hosts ファイルをインストールする実行ドキュメントを設定します。インスタンスが実行状態になっているときに、Amazon EventBridge (Amazon CloudWatch Events) ルールを使用してドキュメントを実行します。
■ 問題文の要件の概要
- VPC 内の EC2 インスタンスから、オンプレミスのホスト名（例:
company.example）を解決できる必要がある - オンプレミス DNS サーバーが権威を持つゾーン
- Site-to-Site VPN 経由で接続済み
- オンプレミス DNS のホスト名解決を、VPC 側からシームレスに行いたい
■ 正解の選択肢と解説
正解：B
VPC の DNS ホスト名を有効にし、Amazon Route 53 Resolver アウトバウンドエンドポイントを作成し、Resolver ルールでオンプレミスの DNS に転送
- Route 53 Resolver アウトバウンドエンドポイント を構成することで、VPC 内から出ていく DNS クエリ（例：
company.example）をオンプレミスの DNS サーバーへ転送可能 - Resolver ルール によって、
company.exampleにマッチするクエリのみをオンプレミスにルーティング - DNS ホスト名を有効にすることで、インスタンス側では自動的にその名前解決を利用できる
■ 不正解の選択肢の理由
A.
空の Route 53 プライベートホストゾーンを作成して NS レコードを追加する構成は、既存レコードが AWS 側に複製されないため、DNS 解決に失敗します（NXDOMAIN）。この構成はオンプレミス側の権威 DNS を壊してしまいます。
C.
インバウンドエンドポイントは「オンプレミス → AWS」方向の DNS 解決用で、本問の「VPC → オンプレミス」には使えません。方向が逆。
D.
hostsファイルによる静的な名前解決は拡張性と可用性に欠ける。名前の追加・変更に毎回ファイル更新と配布が必要で、メンテナンス性が極めて悪い。
■ SAP試験で押さえておくべきポイント
- Amazon Route 53 Resolver は、ハイブリッド DNS 解決 における重要機能
- アウトバウンドエンドポイント：VPC からオンプレミスへの DNS フォワーディング
- インバウンドエンドポイント：オンプレミスから VPC 内のホスト名を解決したい場合に使用
- Resolver ルール：特定ドメイン名に対する転送先を柔軟に設定できる
- Route 53 プライベートホストゾーンは、既存のオンプレミスゾーンとバッティングする場合注意が必要（権威分割の誤り）
- 静的な hosts ファイルでの DNS 解決は非推奨。特に可用性や変更頻度の高い環境では運用コストが高すぎる
必要であれば、図解やRoute 53 Resolverの構成例も補足できますのでお知らせください。
以下は、問題4の整理・解説です。
◆ 問題文
ある会社が人気オンラインゲームの続編を制作しています。発売後 最初の 1 週間で、世界中から多数のユーザーがこのゲームをプレイする予定です。現在、ゲームは 1 つの AWS リージョンにデプロイされた以下のコンポーネントで構成されています。
- ゲームアセットを保存する Amazon S3 バケット
- プレーヤーのスコアを保存する Amazon DynamoDB のテーブル
ソリューションアーキテクトは、レイテンシーを減らし、信頼性を向上させ、実装に最小限の労力で済むマルチリージョンソリューションを設計する必要があります。
これらの要件を満たす最適な方法を選択してください。
◆ 選択肢
A.
S3 バケットからアセットを提供するために Amazon CloudFront ディストリビューションを作成します。S3 クロスリージョンレプリケーションを構成します。新しいリージョンに新しい DynamoDB テーブルを作成します。新しいテーブルを DynamoDB グローバルテーブルのレプリカターゲットとして使用します。
B.
S3 バケットからアセットを提供するために、Amazon CloudFront ディストリビューションを作成します。S3 同一リージョンレプリケーション (SRR) を設定します。新しいリージョンに新しい DynamoDB テーブルを作成します。AWS Database Migration Service (AWS DMS) と変更データキャプチャ (CDC) を使用して、DynamoDB テーブル間の非同期レプリケーションを設定します。
C.
新しいリージョンに別の S3 バケットを作成し、バケット間で S3 クロスリージョンレプリケーション (CRR) を構成します。Amazon CloudFront ディストリビューションを作成し、各リージョンの S3 バケットにアクセスする 2 つのオリジンでオリジンフェイルオーバーを構成します。Amazon DynamoDB Streams を有効にして DynamoDB グローバルテーブルを設定し、新しいリージョンにレプリカテーブルを追加します。
D.
同じリージョンに別の S3 バケットを作成し、バケット間で S3 同一リージョンレプリケーション (SRR) を構成します。Amazon CloudFront ディストリビューションを作成し、S3 バケットにアクセスする 2 つのオリジンでオリジンフェイルオーバーを構成します。新しいリージョンに新しい DynamoDB テーブルを作成します。新しいテーブルを DynamoDB グローバルテーブルのレプリカターゲットとして使用します。
◆ 問題文の要件の概要
- ゲームサービスをマルチリージョン化して レイテンシー削減 と 信頼性向上 を実現したい
- できるだけ 実装の労力を少なく
- コンポーネント：S3（静的アセット）、DynamoDB（スコア）
◆ 正解の選択肢と解説
正解：C
- S3 クロスリージョンレプリケーション（CRR）：データを複数リージョンに自動複製し、冗長性と高速アクセスを確保
- CloudFront のオリジンフェイルオーバー：プライマリ S3 が利用不可でも自動的にセカンダリへ切替、可用性向上
- DynamoDB グローバルテーブル（＋Streams）：リージョン間でスコアデータを自動複製、各地域のユーザーに低遅延で提供
- マネージド構成なのでコード不要・最小構成で要件達成
◆ 不正解の選択肢の理由
A：CloudFront オリジンが1つで単一障害点
- S3は複製されていてもCloudFrontは1つのオリジンしか参照しないため、障害発生時のフェイルオーバーが効かない
- 冗長性・可用性の要件未達
B：SRR（同一リージョン複製）は冗長性を提供しない
- リージョン障害には対応できず、地理分散も実現しない
- DMS＋CDCは構成が複雑で実装労力が大きく、管理工数も増える
D：S3バケットが同一リージョン内で冗長性不足
- CloudFrontのオリジンフェイルオーバーを構成していても、同一リージョン内に2つのバケットでは両方が同時に停止しうる
- レイテンシー改善も不可
◆ SAP試験で押さえておくべきポイント
- **S3 CRR（クロスリージョンレプリケーション）**はリージョンをまたいだ冗長性を提供し、CloudFrontとの併用で高速かつ可用性の高い配信が可能
- CloudFront のオリジンフェイルオーバーは高可用性設計で重要。オリジンが1つでは片系障害に弱い
- DynamoDB グローバルテーブルはマルチリージョン・マルチマスター構成が可能で、レプリケーションは自動・整合性あり
- SRRやDMSは使いどころが限られ、マルチリージョン分散設計には適さない
- マネージドサービス（CloudFront・DynamoDB GT・S3 CRR）を組み合わせることで、最小構成でレイテンシー・信頼性・実装コストの最適解を導ける
次の問題もあれば、同様の形式で解説いたしますので、お送りください。
以下は問題5の整理と解説です：
■ 問題文（そのまま）
ある企業は、Auto Scaling グループ内の Amazon EC2 スポットインスタンスを使用してコンピューティングワークロードを実行しています。起動テンプレートは、2 つのプレイスメントグループと 1 つのインスタンスタイプを使用しています。
最近、監視システムから、システムユーザーの待ち時間が長くなることと相関する、Auto Scaling インスタンスの起動エラーが報告されました。同社は、ワークロードの全体的な信頼性を向上させる必要があります。
この要件を満たすソリューションを選択してください。
■ 選択肢（そのまま、正解は伏せています）
A. 属性ベースのインスタンスタイプの選択を使用する Auto Scaling グループを使用するには、起動テンプレートを起動設定に置き換えます。
B. 属性ベースのインスタンスタイプの選択を使用する新しい起動テンプレートのバージョンを作成します。新しい起動テンプレートのバージョンを使用するように Auto Scaling グループを構成します。
C. 起動テンプレートの Auto Scaling グループを更新して、プレイスメントグループの数を増やします。
D. より大きなインスタンスタイプを使用するように起動テンプレートを更新します。
■ 問題文の要件の概要
- スポットインスタンスを使用中
- 起動失敗と待ち時間の増加が発生
- 起動テンプレートでは1種類のインスタンスタイプのみ指定
- ワークロードの信頼性向上が目的
■ 正解の選択肢と解説
正解：B. 属性ベースのインスタンスタイプの選択を使用する新しい起動テンプレートのバージョンを作成します。新しい起動テンプレートのバージョンを使用するように Auto Scaling グループを構成します。
解説：
属性ベースのインスタンスタイプ選択は、CPU、メモリ、ストレージなどの要件に合う 複数のインスタンスタイプ候補を自動的に選び、より広いスポットプールを活用できるため、起動失敗のリスクを軽減できます。
- 新しいテンプレートバージョンを作成し、既存の Auto Scaling Group に適用するだけで切り替え可能。
- ワークロードの信頼性と起動成功率を大幅に改善します。
■ 不正解の選択肢の理由
A. 起動テンプレートを起動設定に置き換える
- 起動設定（Launch Configuration）は古い仕組みであり、属性ベースのインスタンスタイプ選択は非対応。
- 選択肢Aは機能制約上不正解。
C. プレイスメントグループの数を増やす
- プレイスメントグループはネットワーク最適化用途であり、スポットキャパシティ不足とは無関係。
- インスタンス起動失敗の根本原因解決にならない。
D. より大きなインスタンスタイプに変更
- サイズを大きくすると希少なスポットプールになりやすく、起動失敗率はむしろ上がる可能性がある。
- 多様化しないとリスク回避できない。
■ SAP試験で押さえておくべきポイント
- 属性ベースのインスタンスタイプ選択は、スポットインスタンスのベストプラクティスの1つ。
- Auto Scaling Group で 複数インスタンスタイプ・複数AZを指定可能にするには、起動テンプレートで構成する必要がある。
- 起動設定（Launch Configuration）は現在非推奨、機能制限あり。
- スポットの起動失敗対策は「多様性（多AZ、多インスタンスタイプ）＋属性ベース指定」が基本戦略。
必要であれば、このトピックに関連する図表や AWS 公式ドキュメントリンクも提示できます。次の問題があれば、続けてください。
以下に、問題6の内容を指定の形式で整理・解説いたします。
◆ 問題文
ある環境企業は、大気の質を測定するために全国の主要都市にセンサーを設置しています。センサーは AWS IoT Core に接続し、時系列データを取り込みます。同社はデータを Amazon DynamoDB に保存しています。
事業継続のために、同社は 2 つの AWS リージョンにデータを取り込んで保存できる必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢
A.
両方のリージョンで AWS IoT Core データエンドポイントの値を持つ Amazon Route 53 エイリアスフェイルオーバールーティングポリシーを作成します。Amazon Aurora グローバルテーブルにデータを移行します。
B.
各リージョンで AWS IoT Core のドメイン構成を作成します。Amazon Route 53 レイテンシーベースのルーティングポリシーを作成します。両方のリージョンの AWS IoT Core データエンドポイントを値として使用します。Amazon MemoryDB for Redis にデータを移行し、クロスリージョンレプリケーションを構成します。
C.
各リージョンで AWS IoT Core のドメイン構成を作成します。ドメイン設定の健全性を評価する Amazon Route 53 ヘルスチェックを作成します。AWS IoT Core ドメイン設定からのドメイン名の値を使用して、フェイルオーバールーティングポリシーを作成します。DynamoDB テーブルをグローバルテーブルに更新します。
D.
Amazon Route 53 レイテンシーベースのルーティングポリシーを作成します。両方のリージョンの AWS IoT Core データエンドポイントを値として使用します。DynamoDB Streams とクロスリージョンデータレプリケーションを構成します。
◆ 問題文の要件の概要
- センサーが送信するデータを 複数リージョンで同時に取り込み、保存したい。
- データは時系列データであり、永続性と高可用性が求められる。
- 保存先は Amazon DynamoDB を継続利用。
- 事業継続性（BCP）を強化する構成が必要。
◆ 正解の選択肢と解説
正解：C
各リージョンで AWS IoT Core のドメイン構成を作成し、Route 53 のヘルスチェックとフェイルオーバールーティングを設定、DynamoDB をグローバルテーブルに変更する。
- 理由：
- AWS IoT Core ドメイン構成により、複数リージョンで独立した取り込みポイントを作成でき、TLS証明書やセキュリティを維持。
- Route 53 ヘルスチェック + フェイルオーバー設定により、片方のリージョン障害時に自動でもう一方へ切り替え。
- DynamoDB グローバルテーブルを使えば、両リージョンでの書き込みがサポートされ、自動レプリケーションで整合性と冗長性を確保。
◆ 不正解の選択肢の理由
A:
Aurora Global Databaseは読み取り専用のセカンダリリージョンしか持たないため、同時書き込みが必要な本件には不適。また、Route 53 の**フェイルオーバーは片方向（Active-Passive）**であり、常時両方のリージョンで取り込む要件を満たせない。
B:
MemoryDB は インメモリデータベースであり、長期保存や大量の時系列データ保存に不向き。また、レプリケーションラグがあるため、リアルタイムな正確性を要する用途には向かない。
D:
DynamoDB Streams を用いたクロスリージョンレプリケーションは自前で実装が必要（例：Lambda + Streams）。これは運用負荷や整合性問題が増大するため、試験の趣旨である「高可用・低運用」の観点に反する。
◆ SAP試験で押さえておくべきポイント
✅ DynamoDB グローバルテーブル は、リージョン間での自動レプリケーションができる数少ない マネージド型・多リージョン同時書き込み対応データベース。
✅ AWS IoT Core では、リージョンごとに カスタムドメイン設定を使ってエンドポイントを分離しつつ、一貫性あるセキュリティ管理が可能。
✅ Route 53 フェイルオーバールーティング と ヘルスチェックの組み合わせで、障害時の自動切替を構成できる。レイテンシールーティングはあくまでパフォーマンス目的であり、可用性対策とは異なる。
✅ Aurora Global Database は 読み取り専用のセカンダリという制限があるため、書き込み要件に注意。
次の問題があれば、引き続き対応いたします。どうぞお送りください。
以下は、提供いただいた「問題7」のAWS SAP形式の整理・解説です。
◆ 問題文（編集せずにそのまま掲載）
ある企業のパブリック API は、Amazon Elastic Container Service (Amazon ECS) 上のタスクとして実行されます。タスクは Application Load Balancer (ALB) の背後の AWS Fargate で実行され、CPU 使用率に基づいてタスクの Service Auto Scaling を使用して構成されます。このサービスは数か月間順調に稼働しています。
最近、API のパフォーマンスが低下し、アプリケーションが使用できなくなることがありました。同社は、API に対してかなりの数の SQL インジェクション攻撃が発生し、API サービスが最大量までスケールしていることを発見しました。
ソリューションアーキテクトは、SQL インジェクション攻撃が ECS API サービスに到達するのを防ぐソリューションを実装する必要があります。ソリューションでは、正規のトラフィックの通過を許可し、運用効率を最大化する必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢（そのまま表示）
A: 新しい AWS WAF を使用して、ウェブ ACL を作成して、ECS タスクの前にある ALB に転送される HTTP リクエストと HTTPS リクエストを監視します。
B: 新しい AWS WAF Bot Control 実装を作成します。AWS WAF Bot Control の管理ルールグループにルールを追加して、トラフィックを監視し、ECS タスクの前にある ALB への正当なトラフィックのみを許可します。
C: 新しい AWS WAF を使用して、ウェブ ACL を作成します。SQL データベース (SQL Database) マネージドルールグループに一致するリクエストをブロックする新しいルールを追加します。これらのルールに一致しない他のすべてのトラフィックを許可するように ウェブ ACL を設定します。ECS タスクの前にある ALB にウェブ ACL をアタッチします。
D: 新しい AWS WAF を使用して、ウェブ ACL を作成します。AWS WAF で新しい空の IP セットを作成します。新しいルールをウェブ ACL に追加して、新しい IP セットの IP アドレスから発信されるリクエストをブロックします。SQL インジェクション攻撃を送信する IP アドレスの API ログを収集する AWS Lambda 関数を作成し、それらの IP アドレスを IP セットに追加します。ECS タスクの前にある ALB にウェブ ACL をアタッチします。
◆ 問題文の要件の概要
- 課題: SQLインジェクション攻撃によりFargateサービスがスケールしすぎ、パフォーマンスが低下。
- 要件:
- SQLインジェクションの防止
- 正規トラフィックの許可
- 運用効率の最大化（＝運用負荷を抑える）
◆ 正解の選択肢と解説
正解: C
理由:
AWS WAF の「マネージドルールグループ（AWSManagedRulesSQLiRuleSet）」を使用することで、SQLインジェクションの特徴を持つリクエストを自動で検出・ブロックできます。ALBにアタッチされた Web ACL は、リクエストが ECS に到達する前に悪質なトラフィックをフィルタリングします。
これによりスケールアウトの無駄も防ぎ、正規トラフィックはそのまま通過できるため、セキュリティ・性能・運用性をすべて満たします。
◆ 不正解の選択肢の理由
A:
WAFでACLを作成してALBに適用しても、ルールを設定しなければ「監視（Count）」だけで実際にブロックしません。問題文では「防ぐ必要がある」ので不適。
B:
「AWS WAF Bot Control」はボット検出専用であり、SQLインジェクションのようなアプリケーション層攻撃を対象としていないため、要件不一致。
D:
IPセットを手動で更新するアプローチは、即時性に欠け、運用負荷が高くなります。攻撃者のIPは頻繁に変わるため、実用的ではありません。
◆ SAP試験で押さえておくべきポイント
- WAFの使い方:
- Web ACL は ALB、API Gateway、CloudFront などにアタッチ可能。
- マネージドルールグループを活用すると、個別ルール作成・保守の手間を省ける。
- Count vs Block の違いを理解。
- 攻撃種別と対策のマッチング:
- SQLインジェクション → SQLiRuleSet
- Botトラフィック → Bot Control
- IP制限 → IPセット（補助的）
- 最小の運用コストで最大のセキュリティを得るためにはマネージドルールを活用する。
次の問題もあれば続けてどうぞ。SAP対策に最適な形式で解説します。
