AWS WAF（Web Application Firewall：Webアプリケーションファイアウォール）は、AWSが提供するクラウド型のWAFです。CloudFrontやALB（Application Load Balancer）に届くHTTP/HTTPSリクエストをアプリケーション層（L7）で検査し、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃をリアルタイムに遮断します。
マネージドルールを選んで有効化するだけで基本的な防御は始まりますが、それだけで保護が完結するわけではありません。誤検知への対応やルールの継続的な更新といった運用設計を導入時から組み込んでおかないと、実質的に守られていない状態が生まれます。
そこでこの記事では、AWS WAFの仕組みと保護対象リソース、料金体系、導入手順、そして運用で押さえるべき要点までを解説します。
WAFは通信の入口で既知の攻撃パターンを遮断しますが、アプリケーション固有の脆弱性まではカバーしきれません。その防御範囲外まで検査して守りを固めたい場合は、脆弱性診断ツール「Vex」や専門家による診断サービスを提供するユービーセキュア公式サイトから一度ご相談ください。
AWS WAFとは？ 仕組みと防御できる攻撃の範囲
AWS WAFの防御は、リクエストの中身をアプリケーション層（L7）で検査する点に支えられています。9種類のAWSリソースを保護できる一方で、ネットワーク層（L3/L4）のDDoS（Distributed Denial of Service：分散型サービス拒否攻撃）やアプリケーション固有の脆弱性は防御対象外です。
ファイアウォール・IPS/IDS・WAFの違い
パケットフィルタ型の従来のファイアウォール（FW）は、主にネットワーク層・トランスポート層（L3/L4）で動作し、IPアドレスやポート番号を手がかりに通信を制御します。
この方式では、正規に開放されたHTTP/HTTPS（80番・443番ポート）を通ってくるリクエストは「正当な通信」として扱われ、その中身に攻撃コードが仕込まれていても判別できません。
WAFはこの空白を埋めます。L7で動作し、リクエストのURL・ヘッダー・ボディを分析して、SQLインジェクションやXSSといった攻撃パターンを検知・遮断します。3つの技術は競合ではなく、守るレイヤーが異なる補完関係にあります。
| 技術 | 動作レイヤー | 主な検査対象 | 役割 |
|---|---|---|---|
| ファイアウォール（FW） | L3/L4 | IPアドレス・ポート番号 | 通信の可否を制御する |
| IDS | L3/L4中心 | パケット・通信パターン | 不正な通信を検知して通知する |
| IPS | L3/L4中心 | パケット・通信パターン | 不正な通信を検知して遮断する |
| WAF | L7 | HTTPリクエストのURL・ヘッダー・ボディ | Webアプリケーションへの攻撃を遮断する |
保護できるAWSリソース
AWS WAFは単独で動くのではなく、既存のAWSリソースに関連付けて機能します。保護できるのは以下の9種類のリソースです（※1）。
| リソース | 主な用途 |
|---|---|
| Amazon CloudFront | コンテンツ配信（CDN） |
| Application Load Balancer（ALB） | Webアプリケーションへの負荷分散 |
| Amazon API Gateway（REST API） | APIの公開・管理 |
| AWS AppSync（GraphQL API） | GraphQL APIの構築 |
| Amazon Cognito ユーザープール | ユーザー認証・サインイン |
| AWS App Runner サービス | コンテナアプリケーションの実行 |
| AWS Verified Access インスタンス | 社内アプリケーションへの安全なアクセス制御 |
| AWS Amplify | Web／モバイルアプリケーションのホスティング |
| Amazon Bedrock AgentCore Gateway | 生成AIエージェント向けゲートウェイの保護 |
いずれもAWSマネジメントコンソールから有効化するだけで導入が完了し、専用のハードウェアやソフトウェアを別途デプロイする必要はありません。
WebACL・ルール・アクションの基本構造
AWS WAFは、リクエストを受け取ってから許可・遮断を判断するまでの処理を、WebACL・ルール・アクションという3層で制御します。
WebACL（Web Access Control List）は、複数のルールをまとめる管理単位です。保護対象リソース1つにつき、関連付けられるWebACLは1つだけと決まっています。反対に、1つのWebACLを複数のリソースに関連付けることは可能です（ただしCloudFront用のWebACLは他のリソース種別には使えません）。その中に置く個々のルールが、リクエストを評価する条件を持ちます。
ルールはPriority（プライオリティ）の数字が小さい順に評価されます。あるルールでAllow（許可）またはBlock（遮断）が確定した時点で評価は終了しますが、Count（カウント）は記録するだけで評価が次のルールへ続く点が特徴です。この評価順序を意識しないと、許可したいリクエストが先にブロックされるといった事故につながるため、Priority設計は誤検知防止に直結します。
ルールに設定できるアクションは、Allow・Block・Countのほかに、CAPTCHAとChallengeがあります。CAPTCHAはパズルの表示、Challengeはブラウザへの自動的な検証で、いずれもボット対策に使います。この2つは、リクエストが有効なトークンを持っていればCountと同じように扱われて評価が続き、トークンがない・期限切れの場合はBlockと同じように評価を打ち切ります。
AWS WAFで防げる攻撃と防げない攻撃
AWS WAFはHTTPリクエストの中身を検査する仕組みのため、防御できるのはリクエストの内容に攻撃の痕跡が現れるタイプに限られます。
防御範囲を正確に把握せずに導入すると、カバーされていない攻撃への対策が手薄になってしまうため、確認をしておきましょう。
防げる攻撃
AWS WAFの主な防御対象は、SQLインジェクション、XSS、レートベースルールで緩和できる大量リクエスト（L7 DDoS。自動的なL7 DDoS防御はAWS Shield Advancedの機能）、そして悪意あるボットによるアクセスです。いずれもHTTP/HTTPSリクエストの中身に現れる攻撃であり、L7で内容を検査するWAFが得意とする領域にあたります。
ただし、これらは自動的に防がれるわけではなく、対応するルールを設定して初めて機能します。SQLインジェクションやXSSはAWSマネージドルール（コアルールセットなど）で対応し、ボット対策はBot Controlマネージドルールグループ、不正ログインやなりすまし登録への対策はFraud Control（ATP／ACFP）が担当します。
防げない攻撃
一方で、ネットワーク層・トランスポート層（L3/L4）を狙うDDoS攻撃は、AWS WAFの対象外です。この種の攻撃には、全AWSユーザーに無料かつ自動で適用されるAWS Shield Standardが対処します。L3/L4はShield、L7はWAFと役割が分かれていると整理すると分かりやすくなります。
もう一つの範囲外が、アプリケーション固有の脆弱性です。ロジックの不備や認証・認可の欠陥などは、汎用的な攻撃パターンに一致しないためWAFでは検知しきれません。リクエストの形式そのものは正常で、正規利用との区別がつかないためです。WAFはあくまで攻撃を遮断して被害を抑える対策であり、脆弱性そのものを修正するものではない点は変わりません。
※1 Amazon Web Services｜「AWS WAF、AWS Shield Advanced、AWS Shield ネットワークセキュリティディレクター、AWS Firewall Manager とは」2026年AWS WAFの料金はいくら？ 課金の仕組みと月額の目安
AWS WAFは従量課金制で、初期費用や最低利用料金はありません。基本料金はWebACL数・ルール数・リクエスト数という3つの要素で決まるシンプルな構造です。
そのため小さく始めやすい料金体系ですが、有料マネージドルールを追加すると費用は変わります。
3つの課金要素（WebACL・ルール数・リクエスト数）
基本料金の単価は以下のとおりです（※1）。3つの要素の合計が月額になるため、構成が決まれば見積もりが立てられます。
| 課金要素 | 単価（USD） |
|---|---|
| WebACL | 1つあたり月5.00 USD |
| ルール（ルールグループまたはルール） | 1つあたり月1.00 USD |
| リクエスト | 100万件あたり0.60 USD |
単価はAWSリージョンによって異なる場合があり、月額分は時間単位で按分されます。
ルール数の数え方には注意が必要です。AWSやAWS Marketplaceが提供するマネージドルールグループは、中に何個ルールが入っていても「1つ＝1.00 USD」で計算します。一方、自分で作成したルールグループは「ルールグループ1つ＋その中のルール数」が課金対象です。
AWSの試算例では、5件のルールを含む自作ルールグループ1つと単独ルール9件で、ルール料金は15.00 USDになります。
規模別の月額コストイメージ
公式単価をもとに、ユービーセキュアにて規模別に試算しました。特定製品どうしのスペック比較ではなく、自社のコスト感をつかむための目安として見てください。
| ユースケース | 構成（WebACL／ルール／月間リクエスト） | 月額の目安 |
|---|---|---|
| 中小企業サイト | WebACL 1／ルール 3／50万リクエスト | 約8ドル |
| 大規模ECサイト | WebACL 1／ルール 7／1億リクエスト | 約72ドル |
いずれもマネージドルールの追加機能（Bot Control、Fraud Control）を使わない場合の金額です。
業務用APIシステムのように、リクエスト量やルール数が両者の中間に位置する構成では、月額もその間に収まると考えて差し支えありません。
ただしトラフィックが急増した月はリクエスト課金がそのまま膨らみ、Bot Controlを追加すればサブスクリプション料金も乗ります。なお、AWS WAFはルールの処理負荷をWCU（Web ACL Capacity Unit）という単位で管理しており、既定の1,500 WCUを超えると100万リクエストあたりの追加料金が発生します。またリクエストボディの検査も既定の16KBを超える分は追加課金の対象です。ルール数だけでは読み切れない部分があるため、複雑なルール構成を組む場合は注意が必要です（※1）。
実際の請求額はトラフィックとルール構成で変動するため、公式料金ページの単価で自社構成に当てはめて試算しておくと安全です。
※1 Amazon Web Services｜「AWS WAF 料金」AWS WAFの設定方法は？ 導入からBlock移行までの流れ
AWS WAFの導入は、WebACLの作成、ルールの選定、保護対象リソースへの関連付け、Countモードでの検証という4ステップで進めます。すべてAWSマネジメントコンソールで操作できます。同じ設定はAWS CLIやCloudFormation、Terraformからも行えるため、複数環境に展開する場合はコード管理が現実的です。
ただし、作った直後に防御を全開にするのは危険です。まずCountモードで様子を見て、誤検知がないと確認してからBlockへ移行する段階的な進め方が、本番障害を避ける鍵になります。AWSのドキュメントでも、本番トラフィックに適用する前に検証環境でテストし、そのうえで本番トラフィックに対してCountモードで調整することが推奨されています（※1）。全体の流れは次のとおりです。
- Step 1. WebACLを作成する
- Step 2. マネージドルールとカスタムルールを選定する
- Step 3. WebACLを保護対象リソースに関連付ける
- Step 4. Countモードで検証してからBlockへ切り替える
Step 1. WebACLを作成する
最初にWebACLを作成します。ここで設定する主な項目は、名前・リージョン・デフォルトアクションの3つです。
コンソールではリージョンではなく、まず「CloudFrontディストリビューション」か「リージョナルリソース」かを選びます。CloudFrontを保護する場合は、us-east-1（バージニア北部）を選ぶ必要があります。ALBやAPI Gatewayを保護する場合は、そのリソースと同じリージョンを指定します。
デフォルトアクションは、どのルールにも一致しなかったリクエストをどう扱うかを決める設定です。不特定多数がアクセスする一般公開のWebサービスでは、まず通してから危険なものだけを弾く「Allow（ブロックリスト型）」を基本とします。
逆にすべてを遮断する設定にすると、正規の利用者まで閉め出してしまいます。社内向け管理画面や、アクセス元が固定されたAPIのように利用者を限定できる場合は、Blockを既定にして許可条件だけを並べる「許可リスト型」の方が安全です。
Step 2. マネージドルールとカスタムルールを選定する
次に、WebACLの中身となるルールを選びます。AWSがあらかじめ用意したマネージドルールを自社環境に合わせて選定・組み合わせることで、攻撃防御を素早く構築できます。
AWSマネージドルールの主な種類
押さえておきたいマネージドルールは次の4つです。用途に応じて複数を組み合わせて使います。
| ルールグループ | 主な用途 |
|---|---|
| Core Rule Set（CRS） | OWASP Top 10相当の一般的な攻撃を広くカバーする基本ルール |
| Known Bad Inputs | 既知の不正な入力パターンや脆弱性を突くリクエストを遮断する |
| SQL Database | SQLインジェクションに特化して検知する |
| Amazon IP Reputation List | ボットや脅威として知られる送信元IPを遮断する |
この4つは、ルール1件分の料金（月1.00 USD）以外の追加費用なしで利用できます。一方、Bot ControlやFraud Control（ATP／ACFP）、L7 DDoS防御のマネージドルールグループは、別途サブスクリプション料金とリクエスト従量課金が発生します（※2）。
カスタムルールの活用場面
マネージドルールでは対応できない自社固有の要件は、カスタムルールで補います。たとえば特定IPアドレスからのアクセスを常に許可する、特定の国からのアクセスだけを制限する、独自の条件でリクエストを判定するといった場面です。
この段階では、マネージドルールもカスタムルールも、いったんすべてCountモードで設定することを強く推奨します。いきなりBlockにすると、どのルールがどのリクエストに反応するかを確認する前に、正規の通信を遮断してしまうためです。
Step 3. WebACLを保護対象リソースに関連付ける
ルールを組んだWebACLを、CloudFrontやALB、API Gatewayなどの保護対象リソースに関連付けます。この関連付けが導入の最終ステップです。
関連付けが完了した瞬間から、そのリソースに届くリクエストの検査が始まります。ただし、WebACLの作成や変更の内容が全体に行き渡るまでには数秒から数分の伝播時間があります。関連付け直後に設定が反映されていないように見えても、少し待ってから確認してください。
Step 4. Countモードで検証してからBlockへ切り替える
Countモードは、検知して記録するだけで実際には遮断しない状態です。つまりWAFとして保護されていません。関連付けが終わった安心感からCountのまま運用を続けてしまうと、攻撃を素通りさせ続けることになります。
切り替えの判断基準はログです。数日から数週間ほどCountで運用し、出力されたログを確認して、正規リクエストが誤って検知されていないことを見極めます。
誤検知が見当たらないルールから順に、ルール単位で段階的にBlockへ移行していきます。問題が起きたときにどのルールが原因かを切り分けやすくするためにも、全ルールを一度にBlock化することは避けましょう。
※1 Amazon Web Services｜「AWS WAF での保護の設定」2026年※2 Amazon Web Services｜「AWS WAF 料金」
「入れただけ」で終わらせない運用の3つの要点
Blockモードへ移行できても、そこで運用が終わるわけではありません。
運用開始後は、誤検知への対応、ログの分析、ルールの更新という3つのタスクを継続しなければ、防御の質が落ちるか、正規ユーザーへの悪影響が放置されてしまいます。ここでは、運用における3つのポイントについてご紹介します。
1. 誤検知の発見と除外設定の進め方
マネージドルール、特にCore Rule Setは、正規のリクエストを攻撃と誤認することがあります。
よくあるのが、長文を含む問い合わせフォームの送信や、ファイルアップロードが突然403でブロックされるパターンです。利用者からの「送信できない」という声で初めて気づくことも起こります。
誤検知がわかったら、WAFログを確認し、そのリクエストがどのルールに一致してブロックされたか、ルール名を突き止めます。原因ルールが分かったら、そのルールをCountに戻す（Countオーバーライド）か、該当リクエストを通すための許可リストを設定していきます。
2. ログの出力先と確認すべきポイント
誤検知の発見も攻撃の把握も、すべてログが起点になります。そのため、ログの出力先については自社に合った方法を選択できるようにしておきましょう。
| 出力先 | 特性 |
|---|---|
| Amazon S3 | 低コストで長期保存に向く。後からまとめて分析する運用に適する |
| Amazon CloudWatch Logs | リアルタイムに近い監視・検索がしやすい |
| Amazon Data Firehose（旧Amazon Kinesis Data Firehose） | 外部のSIEMなど他システムへ連携しやすい |
出力先はWebACLごとに1つだけ設定できます（※1）。また、ログの保管費用はCloudWatch LogsやS3側で発生します。WAFリクエスト100万件あたり500MBぶんの取り込みは基本料金に含まれますが、それを超える分は別途請求されるため、大量トラフィックのサイトではログフィルターで対象を絞る、S3へ出力するといったコスト設計が必要です（※2）。
ここで注意したいのが、コンソールで手軽に見られるサンプルログです。サンプルログは直近3時間分から最大100件程度のランダム抽出にとどまり、運用監視には量が足りません。継続的に監視するなら、上記いずれかの出力先へフルログを出力する設定を有効にしてください。
ログで最低限確認すべきは、ブロックされたリクエストの送信元IPアドレス、アクセス先のURI、そして一致したルール名です。この3点を押さえれば、それが本物の攻撃なのか誤検知なのかを判断できます。
3. ルール更新への追従と定期見直し
マネージドルールについては、AWS側が新たな攻撃手法に合わせて自動でシグネチャを更新します。そのため、利用者が個別にシグネチャを管理する負担はほとんどありません。
一方で、カスタムルールやレートベースルールの閾値は自動更新されません。アプリケーションを改修してURL構成やフォーム項目が変わったとき、あるいはトラフィックが定常的に増減したときは、その変化に合わせてユーザー自身が見直す必要があります。四半期ごとなど時期を決めて棚卸しすると、設定の陳腐化を防げます。
WAFの防御範囲外を埋める脆弱性診断の役割
誤検知対応・ログ分析・ルール更新という3つの運用タスクを着実に回せるようになっても、守り切れない領域が残ります。
AWS WAFはSQLインジェクションやクロスサイトスクリプティングといった既知の攻撃パターンをL7で遮断しますが、認証・認可の不備やビジネスロジックの欠陥は、攻撃者が正規のHTTPリクエストの形式に乗せて送り込んでくるため、汎用的なシグネチャでは検知が困難です。
具体例を挙げると、「ログイン済みの一般ユーザーが、URLのパラメータを書き換えるだけで他のユーザーのデータを参照できる」といった認可の不備は、リクエスト自体は完全に正常なHTTP GETです。同様に、「ECサイトの購入フローで決済ステップをスキップして注文が完了する」というビジネスロジックの欠陥も、通常のフォーム送信と見た目は変わりません。
こうした脆弱性は設計・実装の段階に起因するため、WAFによる入口対策とは別に、アプリケーション自体を検査して欠陥を発見・修正するアプローチが必要です。
ユービーセキュアは、こうしたWAFの防御範囲外にある脆弱性の検出を専門とする脆弱性診断ツール「Vex」と、専門家による脆弱性診断サービスを提供しています。AWS WAFで通信レベルの防御を固めながら、アプリケーション固有のリスクを診断で補完する体制を整えたい場合は、ユービーセキュア公式サイトからご相談ください。
※1 Amazon Web Services｜「LoggingConfiguration - AWS WAFV2」
※2 Amazon Web Services｜「AWS WAF 料金」
AWS WAFの導入と運用のまとめ
AWS WAFは、初期費用なく手軽に導入できるWebアプリケーションファイアウォールです。導入の際には、Countモードで誤検知を検証してからBlockへ移すプロセスや、導入後の継続運用を設計に組み込むことなど「入れただけ」で終わらないような工夫を施しましょう。
運用負荷を自社で担えるか不安な方は、まず小さな構成で始めて負荷感をつかむのがおすすめです。料金は従量課金のため、テスト環境で一度Countモード運用を試し、ログ確認の手間を体感してから本番へ広げる進め方が取りやすいはずです。
WAFで守り切れない領域は脆弱性診断で補い、入口対策とアプリケーション検査の両輪で多層防御を組み立ててください。
-1.png)
