以下は、AWS Certified Solutions Architect – Professional（SAP）試験の問題1に関する整理・解説です。
◆ 問題文
ある企業は、多層ウェブアプリケーションをコンテナ化し、そのアプリケーションをオンプレミスのデータセンターから AWS に移動したいと考えています。アプリケーションには、ウェブアプリケーション層とデータベース層が含まれます。会社はアプリケーションをフォールトトレラントでスケーラブルにする必要があります。頻繁にアクセスされるデータは、アプリケーションサーバー間で常に利用できる必要があります。フロントエンドのウェブサーバーはセッションの永続性を必要とし、トラフィックの増加に合わせて拡張する必要があります。
継続的な運用オーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
◆ 選択肢
A. AWS Fargate 上の Amazon Elastic Container Service (Amazon ECS) でアプリケーションを実行します。ウェブ層とアプリケーション層の間で頻繁にアクセスされるデータには、Amazon Elastic File System (Amazon EFS) を使用します。フロントエンドのウェブサーバーのセッションデータを Amazon Simple Queue Service (Amazon SQS) に保存します。
B. Amazon EC2 上の Amazon Elastic Container Service (Amazon ECS) でアプリケーションを実行します。Amazon ElastiCache for Redis を使用して、フロントエンドのウェブサーバーのセッションデータをキャッシュします。複数のアベイラビリティーゾーンに分散している EC2 インスタンスで、マルチアタッチを備えた Amazon Elastic Block Store (Amazon EBS) を使用します。
C. Amazon Elastic Kubernetes Service (Amazon EKS) でアプリケーションを実行します。マネージド型ノードグループを使用するように Amazon EKS を設定します。ReplicaSets を使用して、ウェブサーバーとアプリケーションを実行します。Amazon Elastic File System (Amazon EFS) ファイルシステムを作成します。EFS ファイルシステムをすべての EKS ポッドにマウントして、フロントエンドのウェブサーバーのセッションデータを保存します。
D. Amazon Elastic Kubernetes Service (Amazon EKS) にアプリケーションをデプロイします。マネージド型ノードグループを使用するように Amazon EKS を設定します。EKS クラスター内で Kubernetes デプロイメントとして ウェブサーバとアプリケーションを実行します。フロントエンドのウェブサーバーのセッションデータを Amazon DynamoDB のテーブルに保存します。すべてのアプリケーションがデプロイ時にマウントする Amazon Elastic File System (Amazon EFS) ボリュームを作成します。
◆ 問題文の要件の概要
- 多層構成（Web + DB）
- コンテナ移行（オンプレ → AWS）
- フォールトトレラントかつスケーラブル
- 頻繁に共有されるデータ → 全アプリサーバーで利用可能（共有ストレージ）
- Webサーバーのセッション永続性
- トラフィックに応じてスケール
- 継続的な運用オーバーヘッドを最小限に
◆ 正解の選択肢と解説
正解：D
Amazon EKS + マネージドノードグループ + Kubernetes Deployment + Amazon DynamoDB（セッション永続性）+ Amazon EFS（共有データ）
- Amazon DynamoDB
高速・スケーラブル・マルチAZで、セッションデータの永続性と高可用性を確保可能。 - Amazon EFS
複数アベイラビリティゾーンにまたがってアクセス可能な共有ストレージ。アプリ間の共通データに適。 - Amazon EKS
Kubernetesによるオーケストレーションで、可用性・スケーラビリティ・ローリングアップデートが容易。
→ フォールトトレラント、スケーラブル、運用負荷低減の全てを満たす選択肢。
◆ 不正解の選択肢の理由
A.
- Amazon SQS はメッセージキューであり、セッション情報の保存には向かない（即時性や一貫性に欠ける）。
- セッションの読み書きにはキャッシュ or DB が必要。
B.
- Amazon EBS のマルチアタッチは同一AZ内限定。複数AZでの共有には使えず、フォールトトレラント性に欠ける。
- EC2管理（スケーリング・パッチなど）の運用負荷が大きい。
C.
- EFSにセッションデータ保存は、NFSのロック競合が発生しやすく、スケーラビリティやレスポンスに問題が出やすい。
- DynamoDBやElastiCacheと比べて不適。
◆ SAP試験で押さえておくべきポイント
- セッション永続性の保存先には、ElastiCache（高速）、DynamoDB（永続）を目的に応じて選定。
- 共有ストレージにはEFSが最適。EBSはAZを跨ぐ構成には不向き。
- マネージド型のKubernetes（EKS）やECS + Fargateは、運用負荷を下げる選択肢。
- 用途に応じたサービス選定（キャッシュ、メッセージング、共有ストレージ）を理解しておく。
- **設計要件（可用性、スケーラビリティ、運用性）**をすべて満たす構成を選ぶことが重要。
次の問題も準備ができたら送ってください。続きを解説します。
以下は、SAP試験の問題2に関する整理・解説です。
◆ 問題文
ある企業は、Amazon RDS 上の Microsoft SQL Server DB インスタンスにアクセスする必要がある AWS Lambda 関数を使用して、サーバーレスアーキテクチャを実装しています。同社は、データベースシステムのクローンを含む、開発用と本番用の別々の環境を持っています。
同社の開発者は、開発用データベースの認証情報へのアクセスが許可されています。しかし、本番用データベースの認証情報は、IT セキュリティチームの IAM ユーザーグループのメンバーだけがアクセスできるキーで暗号化する必要があります。このキーは定期的にローテーションする必要があります。
これらの要件を満たすために、ソリューションアーキテクトは本番環境で何をすべきですか?
◆ 選択肢
A.
AWS Key Management Service (AWS KMS) カスタマーマネージドキーで暗号化された SecureString パラメータを使用して、データベース認証情報を AWS Systems Manager Parameter Store に保存します。各 Lambda 関数にロールをアタッチして、SecureString パラメータへのアクセスを提供します。IT セキュリティチームのみがパラメータとキーにアクセスできるように、SecureString パラメータとカスタマーマネージドキーへのアクセスを制限します。
B.
AWS Key Management Service (AWS KMS) のデフォルトの Lambda キーを使用して、データベース認証情報を暗号化します。認証情報を各 Lambda 関数の環境変数に保存します。Lambda コードの環境変数から認証情報を読み込みます。IT セキュリティチームのみがキーにアクセスできるように、KMS キーへのアクセスを制限します。
C.
データベース認証情報を各 Lambda 関数の環境変数に保存します。AWS Key Management Service (AWS KMS) カスタマーマネージドキーを使用して環境変数を暗号化します。IT セキュリティチームのみがキーにアクセスできるように、カスタマーマネージドキーへのアクセスを制限します。
D.
データベース認証情報を、AWS Key Management Service (AWS KMS) カスタマーマネージドキーに関連付けられたシークレットとして AWS Secrets Manager に保存します。各 Lambda 関数にロールをアタッチして、シークレットへのアクセスを提供します。IT セキュリティチームのみがシークレットとキーにアクセスできるように、シークレットとカスタマーマネージドキーへのアクセスを制限します。
◆ 問題文の要件の概要
- Lambda から RDS（SQL Server）への接続
- 認証情報の暗号化保存とアクセス制御
- 開発用と本番用で認証情報の取り扱いが異なる
- 本番環境ではITセキュリティチームのみアクセス可
- 暗号化キーはカスタマーマネージドで定期ローテーションが必要
- 運用負荷を最小限にした設計が求められる
◆ 正解の選択肢と解説
正解：D
AWS Secrets Manager に KMS カスタマーマネージドキーを指定してシークレット（DB認証情報）を保存し、IAMポリシーでアクセスをITセキュリティチームのみに制限。
- Secrets Manager は 自動ローテーション機能により、認証情報とキーの定期更新を実現。
- Lambda は IAM ロールで最小権限に基づきシークレットを安全に取得可能。
- シークレットへのアクセス制御と KMS キーの利用範囲制限も設定可能。
- 本番環境におけるセキュリティと運用負荷の最小化を両立できる。
◆ 不正解の選択肢の理由
A. Parameter Store（SecureString）
- SecureString は KMS 暗号化に対応するが、Secrets Managerのような自動ローテーション機能がない。
- 別途 Lambda や CloudWatch でローテーションを実装する必要があり、運用負荷が高くなる。
B. Lambda 環境変数 + デフォルトKMSキー
- Lambda の環境変数にシークレットを持つと、更新時に関数の再デプロイが必要。
- デフォルトキーはアクセス制御が制限され、セキュリティ要件を満たさない。
C. Lambda 環境変数 + カスタマーマネージドキー
- Bと同様に、自動更新ができない環境変数への保存が問題。
- 鍵だけローテーションしても環境変数の値は古いままで整合性を欠く。
◆ SAP試験で押さえておくべきポイント
- Secrets Manager vs. Parameter Store
- Secrets Manager：機密情報の自動ローテーション、KMS連携、Lambda対応に優れる。
- Parameter Store：セキュア保存は可能だが、自動ローテーションなし。
- KMS カスタマーマネージドキー（CMK） を使うことで、きめ細かなアクセス制御とローテーション管理が可能。
- Lambdaと組み合わせる場合、動的な認証情報取得とセキュアなアクセス制御を両立させる設計が求められる。
- 環境変数はセキュアな管理が困難かつ運用変更が煩雑なため、シークレットストアを使う設計が推奨される。
続けて問題があれば送ってください。次も同じ形式で整理します。
以下は、SAP試験の問題3に関する整理・解説です。
◆ 問題文
ある企業がロードバランサーを使用して、単一のアベイラビリティーゾーンにある Amazon EC2 インスタンスにトラフィックを分散しています。同社はセキュリティを懸念しており、ソリューションアーキテクトに次の要件を満たすソリューションを再構築してもらいたいと考えています。
- インバウンドリクエストは、一般的な脆弱性攻撃に対してフィルタリングする必要があります。
- 拒否されたリクエストは、サードパーティの監査アプリケーションに送信する必要があります。
- すべてのリソースは高可用性である必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢
A.
Auto Scaling グループ + ALB + Amazon Inspector + WAF + Lambda による Inspector レポートの外部送信
B.
ALB + WAF + CloudWatch Logs + Lambda によるログの外部送信（EC2は単一AZ）
C.
ALB + WAF + Firehose によるログ送信 + AWS マネージドルール（EC2は冗長化なし）
D.
Auto Scaling（マルチAZ）+ ALB + WAF（マネージドルール）+ Firehose による拒否ログ送信
◆ 問題文の要件の概要
- 攻撃フィルタリング → WAF で脆弱性攻撃（SQLi, XSS 等）を遮断
- 拒否リクエストの外部送信 → 監査アプリケーションにログを渡す（リアルタイム推奨）
- 高可用性 → マルチAZ + Auto Scaling 必須（単一AZ構成は不可）
◆ 正解の選択肢と解説
正解：D
マルチAZ構成のAuto Scaling Group + ALB + WAF（マネージドルール）+ Kinesis Data Firehose を利用し、サードパーティ監査アプリに拒否ログを転送する構成
✅ 理由：
- Auto Scaling (マルチAZ)：インスタンスの冗長化とスケーリングにより高可用性を実現
- ALB + AWS WAF：HTTPリクエストに対し脆弱性攻撃をリアルタイム検知・遮断
- AWSマネージドルール：OWASP準拠の攻撃パターンを網羅的にカバー
- Kinesis Data Firehose：拒否されたリクエストログをリアルタイムに外部アプリへ配信
◆ 不正解の選択肢の理由
A.
- Amazon Inspector はインスタンスの脆弱性診断ツールであり、HTTPリクエストのフィルタリングはできない
- また、リアルタイムな拒否ログの転送には対応せず、レポートベースでしか出力されないため要件未達
B.
- 単一AZ構成のEC2 → 高可用性の要件を満たさない
- CloudWatch Logs + Lambda 経由の転送は遅延とオーバーヘッドがあり、リアルタイム監査には不向き
C.
- Firehose と WAF マネージドルールの組み合わせは良いが、EC2がマルチAZでない点で高可用性の要件未達
- 可用性が担保されなければ、WAF でログを出しても意味がなくなる構成になる
◆ SAP試験で押さえておくべきポイント
| 要素 | 押さえるべきポイント |
|---|---|
| AWS WAF | ALBに統合してインバウンドHTTPリクエストを検査・遮断する。マネージドルールの使用で運用効率化可能 |
| Kinesis Data Firehose | WAFログのリアルタイム送信先に最適。監査アプリ等への配信に向く |
| Auto Scaling (マルチAZ) | 高可用性の基本構成。単一AZは基本的に不合格扱い |
| Inspector vs WAF | Inspectorはインスタンス脆弱性診断、WAFはリクエストブロック用。役割を混同しないこと |
| CloudWatch Logs vs Firehose | Firehoseはログストリーム処理、CloudWatch Logsは蓄積と分析向け |
この問題では、セキュリティ＋監査＋可用性の3条件をバランスよく同時に満たす構成を選ぶのが正解の鍵です。
引き続き問題があれば送ってください。次もこの形式で解説します。
以下は、SAP試験の問題4に関する整理・解説です。
◆ 問題文
ある企業が、AWS Organizations の組織を使用して、数百の AWS アカウントを管理しています。ソリューションアーキテクトは、Open Web Application Security Project (OWASP) のトップ 10 ウェブアプリケーションの脆弱性に対するベースライン保護を提供するソリューションに取り組んでいます。ソリューションアーキテクトは、組織内にデプロイされているすべての既存および新規の Amazon CloudFront ディストリビューションに AWS WAF を使用しています。
ベースラインの保護を提供する最適な手順の組み合わせを選択してください。（3つ選択）
◆ 選択肢（編集なし）
A. すべてのアカウントで AWS Config を有効にします。
B. すべてのアカウントで Amazon GuardDuty を有効にします。
C. AWS Organizations のすべての機能を有効にします。
D. AWS Firewall Manager を使用して、すべての CloudFront ディストリビューションのすべてのアカウントに AWS WAF ルールをデプロイします。
E. AWS Shield Advanced を使用して、すべての CloudFront ディストリビューションのすべてのアカウントに AWS WAF ルールをデプロイします。
F. AWS Security Hub を使用して、すべての CloudFront ディストリビューションのすべてのアカウントに AWS WAF ルールをデプロイします。
◆ 問題文の要件の概要
- AWS Organizations を利用して数百アカウントを一括管理
- OWASP Top 10 に対するベースライン防御
- CloudFront で AWS WAF を使用中
- すべてのアカウントに 既存 + 新規ディストリビューション両方に自動適用
- ポリシーの中央集権的展開と一貫性が求められている
◆ 正解の選択肢と解説
✅ A. すべてのアカウントで AWS Config を有効にします。
- AWS Config を全アカウントに有効化することで、CloudFront に WAF が適用されているかを監視・評価できる。
- Firewall Manager と連携して 非準拠リソースを検出し、修正ポリシーを自動適用可能。
✅ C. AWS Organizations のすべての機能を有効にします。
- Firewall Manager は Organizations の“すべての機能”モードが必要。
- これにより、SCP・ポリシー統合・サービス展開の集中管理が可能になり、CloudFront に WAF を強制的に適用できるようになる。
✅ D. AWS Firewall Manager を使用して、すべての CloudFront ディストリビューションのすべてのアカウントに AWS WAF ルールをデプロイします。
- AWS Firewall Manager を使うことで、
- CloudFront に対する WAF ルールを一括定義
- 全アカウント・全リソースに対してポリシー展開
- OWASPマネージドルールの自動付与が可能になる
◆ 不正解の選択肢の理由
❌ B. Amazon GuardDuty を有効にします。
- GuardDuty は脅威検出（監視）専用であり、CloudFrontにWAFルールを自動適用する機能はない。
- 防御ではなく検知サービスなので、WAFとの統合は間接的。
❌ E. AWS Shield Advanced を使用して WAF ルールをデプロイします。
- Shield Advanced は DDoS 対策であり、WAF ルールの管理や自動配布はできない。
- また、Enterpriseサポート必須で、本問のWAF展開要件とは無関係。
❌ F. AWS Security Hub を使用して WAF ルールをデプロイします。
- Security Hub はセキュリティ検出結果の統合ダッシュボードであり、WAFルールを設定・配布する機能はない。
- セキュリティ状態の可視化は可能だが、防御策ではない。
◆ SAP試験で押さえておくべきポイント
| 要素 | 学習すべきポイント |
|---|---|
| Firewall Manager | WAF、Shield、VPC Firewall などを組織全体に展開・管理可能。マネージドルールの自動付与も可能。 |
| AWS Config | リソースの構成状態と準拠状態を継続的にモニタリング。Firewall Managerとの組み合わせで準拠強制が可能。 |
| Organizationsの全機能モード | Firewall Manager・SCP・Configなどを全アカウントに適用する前提条件。 |
| GuardDuty / Security Hub | 可視化・検出はできるが防御やルール適用はできない。役割の違いを明確に。 |
| Shield Advanced | DDoS対策に特化し、WAFルールの管理機能は持たない。ネットワーク層の対策に限定される。 |
この問題は、セキュリティポリシーの一元展開・自動適用・準拠監査の観点を評価する良問です。
続けて他の問題も送っていただければ、同様に丁寧に解説します。
以下は、SAP試験の問題5に関する整理・解説です。
◆ 問題文
ある企業は、Amazon Connect を使用してコールセンターを構築しています。同社の運用チームは、AWS リージョン全体にわたる災害復旧 (DR) 戦略を定義しています。コンタクトセンターには、数十の問い合わせフロー、数百のユーザー、数十の電話番号が登録されています。
最も低い RTO で DR を提供するソリューションを選択してください。
◆ 選択肢（編集なし）
A.
Amazon Connect インスタンスの可用性を確認し、使用できない場合に運用チームに通知を送信する AWS Lambda 関数を作成します。5 分ごとに Lambda 関数を呼び出す Amazon EventBridge ルールを作成します。通知後、運用チームに AWS マネジメントコンソールを使用して、2 番目のリージョンに新しい Amazon Connect インスタンスをプロビジョニングするよう指示します。AWS CloudFormation テンプレートを使用して、問い合わせフロー、ユーザー、電話番号をデプロイします。
B.
新しい Amazon Connect インスタンスを、2 番目のリージョンにあるすべての既存ユーザーでプロビジョニングします。Amazon Connect インスタンスの可用性をチェックする AWS Lambda 関数を作成します。5 分ごとに Lambda 関数を呼び出す Amazon EventBridge ルールを作成します。問題が発生した場合、Lambda 関数を構成して、2 番目のリージョンでコンタクトフローと電話番号を規定する AWS CloudFormation テンプレートをデプロイします。
C.
すべての既存のコンタクトフローと請求された電話番号を持つ新しい Amazon Connect インスタンスを 2 番目のリージョンにプロビジョニングします。Amazon Connect インスタンスの URL に対して Amazon Route 53 ヘルスチェックを作成します。失敗したヘルスチェックに対する Amazon CloudWatch アラームを作成します。AWS Lambda 関数を作成して、すべてのユーザーをプロビジョニングする AWS CloudFormation テンプレートをデプロイします。Lambda 関数を呼び出すようにアラームを設定します。
D.
すべての既存のユーザーとコンタクトフローを持つ新しい Amazon Connect インスタンスを 2 番目のリージョンにプロビジョニングします。Amazon Connect インスタンスの URL に対して Amazon Route 53 ヘルスチェックを作成します。失敗したヘルスチェックの Amazon CloudWatch アラームを作成します。AWS Lambda 関数を作成して、要求された電話番号をプロビジョニングする AWS CloudFormation テンプレートをデプロイします。Lambda 関数を呼び出すようにアラームを設定します。
◆ 問題文の要件の概要
- Amazon Connect を使ったマルチリージョンでの DR（災害復旧）
- 数百のユーザー／問い合わせフロー／電話番号 → 復旧手順が複雑
- 要件は 「最も低い RTO」＝最短復旧時間
- 迅速な 自動切替と事前準備の徹底が鍵
◆ 正解の選択肢と解説
✅ D.
セカンダリリージョンに ユーザーと問い合わせフローは事前展開済み、障害発生時に 電話番号のみ CloudFormation で即時デプロイする構成。
Route 53 ヘルスチェックで障害検知 → CloudWatch アラーム → Lambda 発動 → 電話番号をプロビジョニング。
- ✅ **最も重要な要件「最低RTO」**を満たす唯一の選択肢。
- ✅ ユーザーとフローは事前構成済みのため、DR発動時にやるべき作業が最小。
- ✅ 電話番号のプロビジョニングはLambda + CloudFormationで即時対応可能。
- ✅ Route 53 + CloudWatch アラーム + Lambda による完全自動フェイルオーバー設計。
◆ 不正解の選択肢の理由
❌ A.
障害後に手動で Amazon Connect インスタンスを作成
→ RTO が長すぎて要件未達。マネジメントコンソールでの手動操作を含む設計は DR ではNG。
❌ B.
インスタンスとユーザーは事前構成しているが、問い合わせフローや電話番号は障害発生時に構築
→ コンポーネントが揃っていないため切替が遅れる。事前展開が不十分でRTOが長い。
❌ C.
問い合わせフローと電話番号は準備済みだが、ユーザーを切替時に作成
→ 数百人のユーザーをCloudFormationで一括デプロイするのは時間がかかる。これもRTO未達。
◆ SAP試験で押さえておくべきポイント
| 要素 | ポイント |
|---|---|
| Amazon ConnectのDR構成 | ユーザー・問い合わせフロー・電話番号のうち、何を事前にプロビジョニングしておくかでRTOが大きく変わる |
| Route 53 フェイルオーバー + CloudWatch アラーム + Lambda | 完全自動切替構成に不可欠なDR設計パターン |
| 電話番号の扱い | 電話番号は時間がかかるため、可能なら事前取得か、障害時に即時展開できるよう自動化が必須 |
| 最小RTOを実現する構成 | **「事前準備 × 自動切替 × 最小作業」**の3つをセットで考える |
この問題は、**「事前に何を構成しておくか」**が直接 RTO に影響することを理解させる良問です。
他にも問題があれば、引き続き同様の形式で解説します。
以下は、提供いただいた【SAP試験の問題6】の整理・解説です。
◆ 問題文
ある会社は、お客様がオンライン注文するために使用するアプリケーションを更新しています。最近、このアプリケーションに対する悪意者による攻撃が増加しています。
同社は、更新されたアプリケーションを Amazon Elastic Container Service (Amazon ECS) クラスター上でホストします。同社は、アプリケーションデータの保存に Amazon DynamoDB を使用します。パブリック Application Load Balancer (ALB) がエンドユーザーにアプリケーションへのアクセスを提供します。同社は攻撃を防止し、攻撃が続いている間でもサービスの中断を最小限に抑えてビジネスの継続性を確保する必要があります。
これらの要件を最もコスト効率よく満たす手順の組み合わせを選択してください。(2 つ選択)
◆ 選択肢
A. ALB をオリジンとして Amazon CloudFront ディストリビューションを作成します。CloudFront ドメインにカスタムヘッダーとランダム値を追加します。ヘッダーと値が一致する場合、条件付きでトラフィックを転送するように ALB を構成します。
B. アプリケーションを 2 つの AWS リージョンにデプロイします。両方のリージョンに同じ重みでルーティングするように Amazon Route 53 を設定します。
C. Amazon ECS タスクの Auto Scaling を設定する DynamoDB Accelerator (DAX) クラスターを作成します。
D. Amazon ElastiCache を設定して DynamoDB のオーバーヘッドを削減します。
E. 適切なルールグループを含む AWS WAF を使用して、ウェブ ACL をデプロイします。ウェブ ACL を Amazon CloudFront ディストリビューションに関連付けます。
◆ 問題文の要件の概要
- 脅威：アプリケーションに対する悪意ある攻撃（DDoSなど）
- 構成：ECS + ALB + DynamoDB
- 目的：攻撃防止と 継続的なサービス提供（高可用性）
- 制約：コスト効率も重視
◆ 正解の選択肢と解説
✅ A. CloudFront + カスタムヘッダー + ALB条件分岐
- CloudFront経由のみを許可する設計により、ALBへの直接攻撃を遮断できる。
- CloudFrontのDDoS保護（AWS Shield Standard）やキャッシュによりコストと攻撃耐性を両立。
✅ E. AWS WAF を CloudFront に適用
- WAFのマネージドルールで、レイヤ7攻撃（SQLi/XSSなど）をCloudFrontで即時遮断。
- 不要なリクエストをオリジンまで届けず、コスト削減＆可用性確保。
◆ 不正解の選択肢の理由
❌ B. 多リージョンデプロイ + 加重ルーティング
- 多リージョン展開は高可用性には有効だが、DDoS攻撃の分散や遮断には非効率。
- DynamoDB グローバルテーブルなどが必要となり、コストと運用負荷が増加。
❌ C. DAX クラスター作成
- DAX は DynamoDB の読み取り高速化が目的であり、攻撃防御には無関係。
- ECS Auto Scaling との連携もこの文脈では効果なし。
❌ D. ElastiCache 導入
- ElastiCache はアプリ側でのキャッシュ実装が必要で、ALBやECSへの攻撃を防げない。
- 運用コストだけが増え、セキュリティ要件を満たさない。
◆ SAP試験で押さえておくべきポイント
- ✅ CloudFront + ALB + カスタムヘッダー：オリジンへの直接アクセス制限、攻撃経路制御に有効。
- ✅ AWS WAF + CloudFront：アプリ層攻撃のフィルタリングに最適。コスト効率も高い。
- ⚠️ 多リージョン展開 ≠ 攻撃対策：高可用性を目的とした構成と、セキュリティ対策は別。
- ⚠️ ElastiCache / DAX：パフォーマンス改善用であり、セキュリティ・DDoS対策にはならない。
- 🧠 試験では“目的（攻撃防御）”と“構成の意味”をセットで考える思考力が問われる。
次の問題も引き続き対応可能です。どうぞ送ってください。
以下は、いただいたSAP試験問題の整理・解説です。
◆ 問題文（原文ママ）
ある企業が、キャッシュ層として Amazon ElastiCache for Redis クラスターを使用するアプリケーションを実行しています。最近のセキュリティ監査により、同社が ElastiCache に保存時の暗号化を設定していることが明らかになりました。しかし、同社は ElastiCache に転送時の暗号化を設定しませんでした。さらに、ユーザーは認証なしでキャッシュにアクセスできます。
ソリューションアーキテクトは、ユーザー認証を要求し、企業がエンドツーエンドの暗号化を使用していることを確認するように変更を加える必要があります。これらの要件を満たすソリューションを選択してください。
◆ 選択肢（原文ママ）
A.
AUTH トークンを作成します。トークンを暗号化されたパラメータとして AWS Systems Manager Parameter Store に保存します。AUTH を使用して新しいクラスターを作成し、転送中の暗号化を構成します。必要に応じて Parameter Store から AUTH トークンを取得し、認証に AUTH トークンを使用するようにアプリケーションを更新します。
B.
AUTH トークンを作成します。トークンを AWS Secrets Manager に保存します。AUTH トークンを使用するように既存のクラスターを構成し、転送中の暗号化を構成します。必要に応じて Secrets Manager から AUTH トークンを取得し、認証に AUTH トークンを使用するようにアプリケーションを更新します。
C.
SSL 証明書を作成します。証明書を AWS Secrets Manager に保存します。新しいクラスターを作成し、転送中の暗号化を構成します。必要に応じて Secrets Manager から SSL 証明書を取得し、認証に証明書を使用するようにアプリケーションを更新します。
D.
SSL 証明書を作成します。証明書を暗号化されたアドバンストパラメータとして、AWS Systems Manager Parameter Store に保存します。既存のクラスターを更新して、転送中の暗号化を構成します。必要に応じて Parameter Store から SSL 証明書を取得し、認証に証明書を使用するようにアプリケーションを更新します。
◆ 問題文の要件の概要
- ElastiCache for Redis を使っている。
- 保存時の暗号化は実施済み。
- 転送時の暗号化（in-transit encryption）は未設定。
- ユーザー認証なしでアクセス可能。
- 要件：ユーザー認証を有効化し、エンドツーエンド暗号化（保存時 + 転送時）を実現する構成に変更すること。
◆ 正解の選択肢と解説
正解：B
AUTH トークンを作成します。トークンを AWS Secrets Manager に保存します。AUTH トークンを使用するように既存のクラスターを構成し、転送中の暗号化を構成します。必要に応じて Secrets Manager から AUTH トークンを取得し、認証に AUTH トークンを使用するようにアプリケーションを更新します。
解説:
- Redis における認証は
AUTHトークンを使用します。 - Secrets Manager を用いることで、安全にトークンを保存・取得でき、自動ローテーションも可能。
- ElastiCache for Redis は、既存クラスターにも後から認証・転送時暗号化設定を適用可能。
- この構成により、保存時・転送時の暗号化（エンドツーエンド）＋ユーザー認証がすべて満たされます。
◆ 不正解の選択肢の理由
A：Parameter Store + 新しいクラスター作成 → ✕
- Parameter Store には自動ローテーション機能がない。
- わざわざ新規クラスターを作成する必要もない（既存クラスターに適用可能）。
- 運用負荷が高く、選択肢Bの構成より劣る。
C：SSL証明書で認証 → ✕
- Redis は 証明書ベースの認証をサポートしていない（証明書はTLS通信の暗号化にしか使えない）。
- 認証の要件を満たしておらず、選択ミス。
D：SSL証明書 + Parameter Store → ✕
- Cと同じく証明書認証が使えない点に加え、Parameter Storeを使っているため機能性でも劣る。
- 認証できない、暗号化だけ強化されても意味がない。
◆ SAP試験で押さえておくべきポイント
✅ ElastiCache for Redis のセキュリティ構成
- 保存時暗号化：KMSによる暗号化が可能（作成時に設定）。
- 転送時暗号化：TLSを使用してクライアント〜Redis間を保護。
- 認証：AUTH トークンのみ（証明書やIAMでは不可）。
✅ Secrets Manager vs Parameter Store
- Secrets Manager：自動ローテーション対応、機密性が高い値に最適。
- Parameter Store：構成値や非機密データ向け。自動ローテーションなし。
✅ Redisクラスターは後から設定変更が可能
- 既存クラスターでもオンラインで認証やTLSの設定が可能。新規作成は不要。
次の問題も同様の形式で対応できますので、引き続きご提供ください。
