WAF

WAF とは

AWS WAF (Web Application Firewall) は、HTTP リクエストの内容を検査して通過と遮断を判定する、アプリケーション層 (L7) のファイアウォールである。検査ルールをまとめた web ACL を作り、それを保護したいリソースに関連付けて初めて効く。単体で立つプロキシではなく、既存の配信経路に検査を差し込む形になる。

関連付けられるリソースは、CloudFront ディストリビューション、Application Load Balancer、API Gateway の REST API、AppSync の GraphQL API、Cognito ユーザープール、App Runner サービス、Verified Access インスタンスなどである (2026 年 8 月時点)。NLB や EC2 に直接付けることはできないため、前段にこれらのいずれかを置く構成が前提になる。

一方、帯域を埋めるだけの L3/L4 の攻撃はリクエストの中身を見る手前で効いてしまうため、WAF の担当範囲ではない。DDoS 対策としては別の仕組みと組み合わせる。

WAF のルール

ルールは「リクエストのどこを、どう照合するか」という条件と、一致したときのアクションの組で書く。条件として使われる代表的なものを以下にまとめる。

ルールは優先度 (Priority) の数値が小さい順に評価され、終端アクションに一致した時点で判定が確定し、残りは評価されない。Allow と Block は終端で、Count は非終端なのでカウンターとラベルを増やすだけで評価が続く。CAPTCHA と Challenge は有効なトークンを持たないリクエストに対しては終端し、持っている場合は次のルールへ進む。どのルールも終端しなければ、web ACL の既定アクションが適用される。この順序があるため、あるルールに引っかかる正当なリクエストを通したい場合は、例外の Allow ルールを対象より小さい優先度に置く必要がある。

よく使うマネージドルール

マネージドルールは AWS 側が中身を更新するルールグループで、新しい攻撃パターンへの追随を自分で書かずに済む。よく使うものを以下にまとめる。

このうちボット対策は別サブスクリプションのアドオンで、残りは追加のサブスクリプション料金なしに使える。マネージドルールは中身が更新されていくため、正当なリクエストを落とす誤検知も起こり得る。導入時はいきなり全体を Block にせず、問題になったルールだけを個別に Count へ落として影響を確認してから戻す。

レートベースルール

レートベースルールの例を示す。

- Name: RateLimit
  Priority: 2
  Statement:
    RateBasedStatement:
      Limit: 2000                # 評価窓あたりの上限リクエスト数 (指定できる下限は 10)
      EvaluationWindowSec: 300   # 60 / 120 / 300 / 600 秒から選択・既定は 300
      AggregateKeyType: IP
  Action:
    Block: {}

評価窓は「チェックのたびにどれだけ過去へさかのぼるか」の長さであり、チェックの間隔ではない。集計は約 10 秒ごとに更新されるため、上限を超えてから遮断が効き始めるまでには数秒から十数秒の遅れがある。公式にも上限との正確な一致は保証されないと明記されているので、境界ぎりぎりの値を前提にした設計はしない。

上限は集約キーごとに独立して数えられる。AggregateKeyType が IP なら「1 つの送信元 IP あたり 2000」であり、web ACL 全体の合計ではない。さらに scope-down ステートメントを付ければ、ログイン API への POST だけを数えるといった絞り込みができる。全リクエストを一律に数えると、正常な回遊が多い経路で先に上限へ達してしまう。

CloudFront + WAF

CloudFront + WAF を図で示す。

ユーザー → CloudFront (WAF) → API Gateway → Lambda
              ↑ ここで攻撃をブロック

WAF を CloudFront に適用すると、エッジロケーションで攻撃トラフィックをブロックし、オリジンへの負荷を軽減する。

WCU (ルールの容量)

WAF はルールの重さを WCU (Web ACL Capacity Unit) という単位で数える。同じ 1 ルールでも、単純なサイズ制限の照合はほとんど消費せず、正規表現パターンセットの照合は多く消費する。web ACL の基本料金には 1,500 WCU までが含まれ、超えた分は段階的な追加料金になり、上限は 5,000 WCU である (2026 年 8 月時点)。

注意が要るのはルールグループの容量で、作成時に決めた値が固定され、後から増やせない。ルールを足していって足りなくなったら、作り直して web ACL の参照を差し替えることになる。容量は CheckCapacity API かコンソールの表示で事前に見積もる。

WAF で防げないもの

WAF を入れれば安全になるわけではない。WAF が見ているのはリクエストの形であって、アプリケーション側の欠陥そのものではない。プレースホルダを使わない SQL 組み立てや認可漏れが残っていれば、既知パターンをすり抜ける入力で通される。WAF の役割は、既知の攻撃と機械的なノイズを手前で落とし、修正までの時間を稼ぐことである。

誤検知 (False Positive) と検知漏れ (False Negative) は両方向に起きる。ルールを厳しくすれば正当なリクエストが落ち、緩めれば攻撃が通る。そのため導入は Count から始め、ログで実害の有無を見てから Block へ切り替える。

検査範囲にも上限がある。リクエストボディを検査できるサイズは、Application Load Balancer と AppSync では 8 KB (8,192 バイト) 固定、CloudFront / API Gateway / Cognito / App Runner / Verified Access では既定 16 KB (16,384 バイト) で、16 KB 刻みで 64 KB まで引き上げられる (既定を超えた分の検査には追加料金がかかる)。上限を超えた部分は検査されないため、大きな JSON を受け取る API では超過したリクエストの扱い (そのまま通すか遮断するか) を明示的に決める。なお gRPC のトラフィックにはボディ検査のルールが適用されない。

コスト

料金は web ACL の数 / ルールの数 / 処理したリクエスト数の 3 つで決まる。以下は 2026 年 8 月時点の公式料金ページの表示である。

マネージドルールグループは中に何十のルールが入っていても 1 グループ $1.00/月 で、内側のルール数では課金されない。一方、自分で作ったルールグループはグループ 1 個分に加えて中のルールも 1 個ずつ課金される。Marketplace で購入するルールグループは出品者の料金が上乗せされる。アクションのうち Allow / Block / Count に追加料金はかからないが、CAPTCHA と Challenge は判定回数に応じて課金される。ボット対策や不正防止の機能は別サブスクリプションのアドオンである。

WAF のログ

ログを S3 に出しておけば、Athena で SQL として集計できる。各レコードには判定を確定させたルールの ID (terminatingRuleId) が入るため、どのリクエストがどのルールで落ちたかを 1 件ずつ特定できる。誤検知を疑うときは、まず該当ルールを Count へ落としてログを溜め、落ちていた条件を読み取ってから例外の Allow ルールを設計する。なお、ボディの中身自体はログに記録されない。

より深く学ぶには関連書籍が役立つ。