AWS Certified Solutions Architect - Associate (SAA-C03) #5 Domain 1-4 安全なアーキテクチャ — WAF・Shield・Cognito・Secrets Manager
#4 VPC セキュリティ でネットワーク境界を押さえました。セキュリティドメインの最後となる今回は、さらに一段上の層へ移り、アプリケーション層の攻撃防御 (WAF・Shield) と ユーザー認証・認証情報の管理 (Cognito・Secrets Manager) を扱います。この 4 つのサービスは試験で役割が紛らわしいため、各サービスが何をするものなのかを正確に区別することが重要です。
WAF — Web アプリケーションファイアウォール #
AWS WAF は レイヤー 7 (HTTP/HTTPS) で動作する Web ファイアウォールです。Web ACL (Web ACL) にルールをまとめておき、リクエストを検査して許可・遮断・カウントします。
ルールの種類 #
- マネージドルールグループ — AWS とマーケットプレイスが提供する事前定義ルール (共通の脆弱性、既知の悪意のある IP など)
- SQL injection / XSS マッチング — 代表的な Web 攻撃パターンの遮断
- IP set マッチング — 特定の IP・帯域の許可/遮断
- Geo マッチング — 国単位の遮断/許可
- Rate ベースルール — 一定時間あたりのリクエスト数を超える IP を遮断 (レイヤー 7 フラッディングの緩和)
- 文字列/正規表現マッチング — ヘッダー・URI・ボディのパターン検査
どこに付くか #
WAF は CloudFront、Application Load Balancer (ALB)、API Gateway、AppSync、Cognito User Pool に接続されます。すべてレイヤー 7 のエントリポイントです。NLB (Network Load Balancer) はレイヤー 4 なので WAF を付けられません。 この区別が試験に出ます。
Shield — DDoS 防御 #
| 項目 | Shield Standard | Shield Advanced |
|---|---|---|
| コスト | 無料 (自動適用) | 月 3,000 USD + |
| 防御レイヤー | L3/L4 | L3/L4/L7 |
| 対応サポート | なし | DDoS 対応チーム (SRT) |
| コスト保護 | なし | DDoS による スケーリングコストの返金 |
| WAF | 別途 | WAF 込み |
Shield Standard は すべての AWS 顧客に自動で、無料で 適用される L3/L4 DDoS 防御です。別途の設定は不要です。これに加えて L7 DDoS 防御、専門の対応チーム、DDoS による自動スケーリングコストの返金、詳細レポート が必要なら Shield Advanced (有料) を使います。
試験で「追加コストなしで基本の DDoS 保護があるか?」の答えは Shield Standard (はい、自動・無料) です。「大規模な L7 DDoS とコスト保護、専門の対応が必要だ」なら Advanced です。
Cognito — User Pool vs Identity Pool #
Cognito は 2 つの異なる仕事をします。この 2 つを混ぜると認証問題をほぼ間違えます。
| 区分 | User Pool | Identity Pool (Federated Identities) |
|---|---|---|
| 担う役割 | 認証 (Authentication) — 誰なのか、ログイン | 認可 (Authorization) — AWS リソースへのアクセス |
| 成果物 | JWT トークン (ID/Access/Refresh) | 一時的な AWS 認証情報 (STS) |
| 代表的な機能 | サインアップ・ログイン・MFA・ソーシャル/SAML フェデレーション | 認証されたアイデンティティを AWS 認証情報に交換 |
| 一行で | 「ユーザーをログインさせる」 | 「ユーザーに一時的な AWS アクセスを与える」 |
- User Pool — ユーザーディレクトリであり認証サーバーです。サインアップ・ログイン・MFA・パスワードポリシーを提供し、ソーシャル (Google・Facebook)・SAML・OIDC フェデレーションを付けられます。ログイン成功時に JWT トークンを発行します。
- Identity Pool — 認証されたアイデンティティ (User Pool・ソーシャル・SAML) を受け取って STS の一時的な AWS 認証情報に交換 します。モバイルアプリのユーザーが S3 に直接アップロードする必要があるときのように、アプリに長期キーを埋め込まずに AWS リソースにアクセスさせます。
この 2 つはよく一緒に使われます。User Pool でログイン → そのトークンを Identity Pool に提示 → 一時的な AWS 認証情報を取得、という流れです。
Secrets Manager vs Parameter Store #
認証情報・設定値をコードに埋め込まずに安全に保管する 2 つのサービスです。
| 項目 | Secrets Manager | SSM Parameter Store |
|---|---|---|
| 主な用途 | シークレット (DB 認証情報、API キー) | 設定値 + シークレット (SecureString) |
| 自動ローテーション (rotation) | 組み込みサポート (RDS など) | なし (Lambda で自分で実装) |
| コスト | シークレットあたり月 $0.40 + API | 標準パラメータは 無料 |
| 暗号化 | KMS | KMS (SecureString) |
| クロスアカウント | サポート | 限定的 |
核心の分岐点は 自動ローテーション (rotation) です。「DB 認証情報を定期的に自動ローテーションせよ」という要件なら Secrets Manager が正解です (特に RDS・Redshift・DocumentDB は組み込み統合)。逆に「単純な設定値でコストを節約したい」なら Parameter Store が適しています。Parameter Store も SecureString でシークレットを KMS 暗号化して保存できますが、自動ローテーションは標準では提供されません。
試験の出題パターン #
- 「SQL injection / XSS のような Web 攻撃を防げ。」 → WAF
- 「特定の国 の遮断 / IP の rate 制限。」 → WAF (geo / rate ベースルール)
- 「WAF を NLB に付けられるか?」 → 不可 (L4)。CloudFront/ALB/API GW/AppSync に接続
- 「追加コストなしで 基本の DDoS 保護 があるか?」 → Shield Standard (自動・無料)
- 「L7 DDoS + コスト保護 + 対応チーム。」 → Shield Advanced
- 「ユーザーの ログイン/サインアップ/ソーシャルログイン。」 → Cognito User Pool
- 「認証されたユーザーに 一時的な AWS 認証情報。」 → Cognito Identity Pool
- 「DB 認証情報の自動ローテーション。」 → Secrets Manager
- 「単純な設定値、コスト削減。」 → Parameter Store
よく出会う落とし穴 #
1) WAF を NLB に付けようとする #
WAF はレイヤー 7 のエントリポイント (CloudFront/ALB/API Gateway/AppSync) にのみ付きます。NLB はレイヤー 4 なので対象ではありません。
2) Shield Standard が有料だと思う #
Standard はすべての顧客に自動・無料です。有料は Advanced です。
3) User Pool が AWS 認証情報を与えると誤解する #
User Pool はログインと JWT トークンまでです。AWS 認証情報は Identity Pool が STS で発行します。
4) Parameter Store に自動ローテーションが組み込まれていると思う #
自動ローテーションの組み込みは Secrets Manager です。Parameter Store は自分で実装する必要があります。
まとめ #
この記事で押さえたこと:
- WAF — レイヤー 7 の Web ファイアウォール。SQLi・XSS・geo・rate ルール。CloudFront/ALB/API GW/AppSync に接続 (NLB 不可)
- Shield — Standard は自動・無料 (L3/L4)。Advanced は有料 (L7・対応チーム・コスト保護)
- Cognito — User Pool は 認証 (JWT)、Identity Pool は 一時的な AWS 認証情報。2 つは一緒に使われる
- Secrets Manager vs Parameter Store — 自動ローテーションが必要なら Secrets Manager、単純・低コストなら Parameter Store
これで セキュリティドメイン (30%) を終えます。IAM (アイデンティティ) → KMS (データ) → VPC (ネットワーク) → WAF・Cognito (アプリケーション・ユーザー) とレイヤーを下りながらセキュリティの大きな絵を押さえました。
次へ — Domain 2-1 回復力のあるアーキテクチャ #
次のドメインは 回復力 (26%) です。障害が起きてもサービスが止まらないようにする設計へ移ります。
#6 Domain 2-1 Multi-AZ・Auto Scaling・ELB では、アベイラビリティーゾーン (AZ) を活用した高可用性、Auto Scaling グループの動作とポリシー、ELB の種類 (ALB・NLB・GLB) と選択基準、そしてヘルスチェックで障害インスタンスをふるい落とす構造を整理します。