TL Terralien
Security, Identity, and Compliance

AWS WAF

HTTPリクエストのパターンを見るファイアウォールで、Bedrock AgentCore GatewayやCognitoユーザープールの手前にも配置できます。ただしプロンプトインジェクション対策そのものではありません。

  • B｜実装まわり
  • D3 安全性・セキュリティ・ガバナンス

最終更新: 2026年8月18日

ひとことで言うと

HTTP(S)リクエストを条件で判定して通す・止めるファイアウォールです。IPアドレス・ヘッダー・クエリ文字列といったリクエストの形を見て判断します。

要するに、入館ゲートの持ち物検査です。誰が何を持って入ろうとしているか（送信元IP・ヘッダー・リクエストの形）は見ますが、建物の中で交わされる会話の中身までは判定しません。「悪意のある発言をしようとしている来訪者」を弾くのは、ゲートの持ち物検査ではなく建物内の別の係（Guardrails）の仕事です。

なぜ生まれたか

WAFが無いと受け皿
既知の攻撃パターン（SQLi・XSS等）を個別のアプリで実装するしかないAWS管理ルールグループで既製の防御を適用
大量リクエストによる過負荷・コスト暴走を止められないレートベースのルールで単位時間あたりのリクエスト数を制限
保護対象ごとに別々の仕組みを組むCloudFront・API Gateway・ALB・AppSync・Cognitoユーザープール・Bedrock AgentCore Gatewayなど複数のリソースタイプを同じ仕組みで保護

WAFの保護対象リストにはAmazon Bedrock AgentCore Gatewayが明記されています。エージェントの外向きゲートウェイもHTTP(S)エンドポイントである以上、他のWebアプリと同じ層の防御が効くという位置づけです。

何に使うか

用途使い方関連ドメイン
Bedrock AgentCore Gatewayの保護Web ACLを関連付けてリクエストを検査D2・D3
Cognitoユーザープール（認証フロントエンド）の保護Web ACLをユーザープールに直接関連付けD3
API GatewayやALB経由のGenAIアプリ保護既知の攻撃パターン・ボットをマネージドルールで遮断D3
過剰なAPI呼び出しの抑制レートベースルールで単位時間あたりのリクエスト数を制限D3・D4

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
生成AIチャットボットへのプロンプトインジェクション・ジェイルブレイクを防ぎたいWAFはHTTPリクエストの形しか見ない。自然言語の意味的な攻撃検知はBedrock Guardrailsのコンテンツフィルタ（Prompt Attack）の役目WAFのルールでプロンプトインジェクションを止めようとする
Bedrock AgentCore Gatewayへの既知の攻撃パターン（SQLi・XSS等）を防ぎたいAWS管理ルールグループをWeb ACLに追加Guardrailsだけで済ませようとする（Guardrailsはモデルの入出力層、WAFはHTTP層で役割が異なる）
エージェントのAPIエンドポイントに短時間で大量のリクエストが来て、モデル推論コストが跳ね上がっているレートベースルールでIP単位のリクエスト数を制限ガードレールのしきい値を厳しくして対応しようとする
Cognitoの認証フロントエンド自体への不正アクセスを検査したいWeb ACLをCognitoユーザープールに直接関連付け可能ユーザープールの前段に別途API Gatewayを挟んでそこにだけWAFを付ける

WAFとGuardrailsは防御している層が違います。WAFは「このリクエストの形は正当か」というHTTP層、Guardrailsは「この内容は安全か」というモデル入出力の意味の層です。片方だけで両方を防げるという設計にしないことが試験でも実務でも問われます。

実務でどう使うか

  • ルールグループには自作・AWS管理・マーケットプレイス・他サービス（Shield Advanced等）が提供するものの4種類があります。 ゼロから自作する前に、既製のマネージドルールグループで足りないか確認する方が運用負荷は下がります
  • Web ACLには容量上限（WCU）があります。 ルールグループを積み増していくと上限に達することがあり、保護の優先順位付けが必要になります
  • ルールグループ自体はリソースに直接関連付けられません。 必ずWeb ACL（protection pack）に組み込んでから、保護対象のリソースに関連付けます

WAFのマネージドルールは既知の攻撃シグネチャ・IPレピュテーション・レートを見るもので、自然言語の意図を判定するものではありません。「プロンプトインジェクション対策としてWAFを厳しくする」という発想自体が的外れになりがちです。

取り違えやすいもの

迷う相手切り分けの一言
Bedrock GuardrailsWAFはHTTPリクエストの形（IP・ヘッダー・パターン）を見る。Guardrailsはモデルの入出力の意味（有害性・PII・ジェイルブレイク）を見る。プロンプトインジェクション対策はGuardrails側
Amazon CognitoWAFはリクエストを検査するファイアウォール。Cognitoは誰であるかを認証する仕組み。Cognitoユーザープールの手前にWAFを置く、という組み合わせで使う
AWS ShieldWAFはアプリケーション層（レイヤー7）の攻撃パターンに対応。Shieldはネットワーク層・トランスポート層のDDoS対策で、役割が異なる

想起チェック

Q1. 生成AIチャットボットへのプロンプトインジェクション対策として、WAFは適切な選択肢か？

適切ではありません。 WAFはHTTPリクエストの形（IP・ヘッダー・パターン）を見るファイアウォールで、自然言語の意味的な攻撃は判定できません。プロンプトインジェクション・ジェイルブレイク対策はBedrock Guardrailsのコンテンツフィルタ（Prompt Attack）の役目です。

Q2. AWS WAFが保護対象にできる、生成AI関連のリソースは？

Amazon Bedrock AgentCore GatewayとAmazon Cognitoユーザープールが保護対象リソースに含まれます。エージェントの外向きゲートウェイと、その手前の認証フロントエンドの両方にWeb ACLを関連付けられます。

出典（AWS公式）