はじめに
Web アプリケーションを公開すると、SQL インジェクションや XSS、bot による不正アクセスなど、アプリケーション層を狙った攻撃への対策が必要になります。AWS では、これらをマネージドサービスとして扱える AWS WAF が用意されています。導入を検討する際は、何を保護でき、どう構成し、料金がどう決まるのかを先に押さえておくと、設計の判断がしやすくなります。
- AWS WAF が保護できる AWS リソースと適用範囲
- Web ACL・ルールといった構成要素の関係
- マネージドルールやレートベースルールの使い分けと、料金の考え方
AWS WAF は、HTTP・HTTPS リクエストを検査して許可やブロックなどを行う、マネージド型の L7（アプリケーション層）ファイアウォールです。CloudFront や ALB など複数の AWS リソースに関連付けて利用し、Web ACL に登録したルールでリクエストを制御します。料金は Web ACL 数・ルール数・リクエスト数に応じた従量制です。本記事はこれらの全体像を示すハブとして、個別のトピックは各スポーク記事へ案内します。
AWS WAF とは（AWS のマネージド型 L7 ファイアウォール）
AWS WAF は、保護対象のリソースへ転送される HTTP・HTTPS リクエストを監視し、指定した条件に基づいてリクエストを許可・ブロック・カウントするサービスです。送信元 IP アドレス、HTTP ヘッダー、URI パス、クエリ文字列、既知の攻撃パターンなどを条件に指定できます。
参考: AWS WAF Developer Guide
“AWS WAF is a web application firewall that lets you monitor”
（AWS WAF は、Web アプリケーションへのリクエストを監視できる Web アプリケーションファイアウォールです）
https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html
現行のバージョンは AWS WAFv2 です。旧世代の AWS WAF Classic とは API やリソース構成が異なります（Classic の扱いと移行は後半の「設計・運用のポイント」で取り上げます）。
WAF そのものの仕組みや提供形態（クラウド型・アプライアンス型・ホスト型など）の一般的な分類については、別記事『WAF とは｜仕組みと種類』で扱います。本記事は AWS WAF に絞って解説します。
他のセキュリティサービスとの違い
AWS には複数のセキュリティサービスがあり、保護するレイヤーが異なります。AWS WAF はアプリケーション層（L7）を対象とし、DDoS 対策の AWS Shield やネットワーク層の AWS Network Firewall とは役割が分かれます。
| サービス | 対象レイヤー | 主な対象 | 用途 |
|---|---|---|---|
| AWS WAF | L7（アプリケーション層） | HTTP・HTTPS リクエスト | SQLi・XSS・bot などの Web 攻撃の検査と制御 |
| AWS Shield | L3/L4（ネットワーク・トランスポート層） | パケット・接続 | DDoS 攻撃の緩和 |
| AWS Network Firewall | L3/L4（VPC 内） | VPC のトラフィック | VPC サブネット間のパケット検査と制御 |
AWS Shield には、追加料金なしで全利用者に自動適用される Shield Standard と、有料で高度な緩和機能を提供する Shield Advanced があります。AWS WAF は L7 でのリクエスト検査を担うため、両者は併用されることが多く、L3/L4 の大規模攻撃を Shield で吸収し、L7 の不正リクエストを WAF で制御する構成が一般的です。
保護できるリソース
AWS WAF は、Web ACL を AWS リソースに関連付けることで保護を有効にします。2026 年時点で関連付けできるリソースは次の 8 種類です。
- Amazon CloudFront ディストリビューション
- Amazon API Gateway の REST API
- Application Load Balancer（ALB）
- AWS AppSync の GraphQL API
- Amazon Cognito ユーザープール
- AWS App Runner サービス
- AWS Amplify アプリケーション
- AWS Verified Access インスタンス
Amazon ECS で動くアプリケーションは、AWS WAF を有効にした ALB を経由させることで保護できます。
参考: AWS WAF Developer Guide – Resources that you can protect
“AWS WAF is available globally for CloudFront distributions”
（AWS WAF は CloudFront ディストリビューションに対してグローバルに利用できます）
https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works-resources.html
スコープ（CLOUDFRONT と REGIONAL）
Web ACL には二つのスコープがあり、保護対象によって使い分けます。
CLOUDFRONT スコープ: CloudFront ディストリビューション（および Amplify）が対象。Web ACL とそれが使うリソースは US East（バージニア北部、us-east-1）で作成します。コンソールの「Global （CloudFront）」を選ぶことは us-east-1 を選ぶことと同じです。
REGIONAL スコープ: ALB、API Gateway、AppSync、Cognito、App Runner、Verified Access が対象。AWS WAF が利用可能な各リージョンで作成します。
Web ACL が参照するルールグループ・IP Set・正規表現パターンセットは、保護対象リソースと同じリージョンに置く必要があります。
関連付けの制約
関連付けには次のルールがあります。
- 1 つの AWS リソースには 1 つの Web ACL のみ関連付けできます。
- 1 つの Web ACL は複数のリソースに関連付けできます（一対多）。
- CloudFront に関連付けた Web ACL は、他のリソースタイプには関連付けできません。
AWS WAF の構成要素
AWS WAF は、Web ACL を頂点とした階層構造で構成されます。リクエストは Web ACL 内のルールを上から順に評価し、最初にマッチしたルールのアクションが適用されます。どのルールにもマッチしない場合は、Web ACL に設定したデフォルトアクション（Allow または Block）が適用されます。
主な構成要素は次のとおりです。
- Web ACL: ルールとルールグループをまとめる入れ物。デフォルトアクションを設定し、保護対象リソースに関連付けます。
- ルール（Rule）: 検査条件を定めるステートメントと、マッチ時のアクションの組。
- ルールグループ（Rule Group）: 再利用可能なルールの集合。自分で作成するものと、AWS や第三者が提供するマネージドルールグループがあります。容量は作成時に固定され、後から変更できません。
- IP Set: IP アドレスや CIDR の集合。IPv4・IPv6 の双方を登録できます。
- 正規表現パターンセット: 検査に使う正規表現の集合。
- アクション: Allow、Block、Count、CAPTCHA、Challenge の 5 種類。Count はブロックせず一致のみ記録するため、ルールの影響を本番前に検証する用途に向きます。
容量（WCU）とリクエストボディの検査サイズ
ルールの処理コストは WCU（Web ACL Capacity Units）という単位で管理されます。ルールの複雑さに応じて消費量が決まり、Web ACL あたりの容量上限は 5,000 WCU です。基本料金には 1,500 WCU まで含まれ、これを超えると段階的な追加料金が発生します（料金は後半で扱います）
なお WCU は容量の管理単位であって、無料枠の境界ではありません。1,500 WCU を超えても、追加できなくなるのではなく追加料金がかかる、という関係です。
参考: Web ACL capacity units （WCUs） in AWS WAF
https://docs.aws.amazon.com/waf/latest/developerguide/aws-waf-capacity-units.html
リクエストボディの検査サイズは、CloudFront・API Gateway・Cognito・App Runner・Verified Access ではデフォルト 16 KB で、設定により引き上げられます。ALB と AppSync は 8 KB で固定されています。
ルールの種類と使い分け
Web ACL に登録するルールには、自分で条件を定義するものと、AWS や第三者が用意したものがあります。代表的な種類と適用場面を整理します。
マネージドルール（AWS Managed Rules）
AWS が管理する、すぐ使えるルールグループです。コアルールセット、Known Bad Inputs（既知の不正な入力）、SQL Database（SQLi 対策）、Linux/Windows などの OS 別ルール、Admin Protection、Amazon IP 評価リストなどがあります。OWASP Top 10 の大半は、コアルールセットに Known Bad Inputs と SQL Database、該当する OS ルールセットを組み合わせることで広くカバーできます。
AWS Marketplace では、F5・Fortinet・Imperva といった第三者ベンダーのルールグループも提供されており、こちらはベンダーが設定した価格で課金されます。
レートベースルール
送信元 IP（または JA3 TLS フィンガープリント、HTTP ヘッダー、Cookie などのカスタム集約キー）ごとに、直近 5 分間のリクエスト数を継続的に集計し、閾値を超えたときにアクションを適用するルールです。ログインエンドポイントへの総当たりや、credential stuffing、急増する大量アクセスへの第一防御に向きます。基本のルール料金に含まれるため、簡易な bot 対策は Bot Control より低コストで実装できます。
IP 制限（IP Set）
IP Set に登録した IP アドレスや CIDR を使って、許可リストや拒否リストを構成します。社内からのアクセスのみを許可する用途などに使われますが、IPv6 優先のアドレス選択との組み合わせで意図せずブロックが起こることがあります。具体的な事例と対処は、関連記事『AWS WAF の IP 制限が効かない原因と CloudFront で IPv6 を無効化する手順』で扱っています。
Bot Control
bot トラフィックを検出・分類するマネージドルールグループです。検証済みの good bot（Google、Bing など）、既知の bad bot、未分類の bot を、リクエストのフィンガープリントや挙動から判別します。機械学習を用いる高度な機能で、基本料金とは別の料金体系です。ログインや決済など重要なパスに絞って適用する（スコープダウンする）ことで、コストを抑えられます。同様に、ログイン・新規登録ページを保護する Fraud Control（ATP／ACFP）も別料金です。
料金の考え方
AWS WAF の料金は、固定の月額料金と従量のリクエスト料金の組み合わせです。2026 年時点の基本料金は次のとおりです（料金は変更されることがあるため、最新は公式の Pricing ページで確認してください）。
参考: AWS WAF Pricing
“Pricing is the same across all AWS Regions”
（料金は全 AWS リージョンで共通です）
https://aws.amazon.com/waf/pricing/
| 課金対象 | 料金（2026 年時点、USD） |
|---|---|
| Web ACL | $5.00/月 |
| ルール／ルールグループ | $1.00/月（時間単位でプロレート） |
| リクエスト | $0.60/100 万リクエスト |
| Fraud Control（ATP／ACFP） | 各 $10.00/月＋段階的なリクエスト料金 |
マネージドルールグループも、ルールと同じく $1.00/月で課金されます（コアルールセットなどの標準的なものは、この料金以外に追加のリクエスト料金はかかりません）。Bot Control は月額サブスクリプションと段階的なリクエスト料金が別途発生します。
このほか、Web ACL の容量が 1,500 WCU を超えると 500 WCU ごとにリクエスト料金が加算され、リクエストボディの検査をデフォルトの 16 KB より大きくした場合も追加料金がかかります。AWS WAF に無料枠はありませんが、AWS Shield Advanced を契約している場合は、保護対象リソースの WAF 基本料金が追加費用なしで含まれます。
コストを抑える設計のヒント
- 1 つの Web ACL を複数のリソースで共有する。同じルールを適用するなら、リソースごとに Web ACL を作らず共有することで月額料金を節約できます。
- スコープダウンステートメントで、Bot Control などの高価なルールを重要なパスだけに限定する。
- 簡易な bot 対策やレート制限は、Bot Control ではなくレートベースルールで実装する。
- まず無料で使えるマネージドルール（コアルールセットなど）から始め、必要に応じて拡張する。
設計・運用のポイント
導入後の運用で押さえておきたい点を整理します。
ログの出力と分析
AWS WAF は、検査したトラフィックの詳細をログとして出力できます。出力先は CloudWatch Logs、Amazon S3、Amazon Data Firehose（旧 Kinesis Data Firehose）の 3 つです。
- CloudWatch Logs: コンソール上で CloudWatch Logs Insights を使い、検索や可視化ができます。
- Amazon S3: Amazon Athena で SQL を使ってログを分析できます。長期保管にも向きます。
- Amazon Data Firehose: 外部のログ基盤や保管先へ連携する場合に使います。
ログの出力先となるロググループやバケットの名前は、aws-waf-logs- で始める必要があります。CloudFront に関連付けたグローバル Web ACL のログは us-east-1 に出力します。
Count モードによる段階的な導入
新しいルールをいきなり Block で適用すると、正規のリクエストまで遮断する誤検知のリスクがあります。まず Count アクションで一致状況だけを記録し、ログで影響を確認してから Block へ切り替えると、安全に導入できます。マネージドルールも、最初は Count で挙動を観測する運用が向きます。
AWS WAF Classic からの移行
旧世代の AWS WAF Classic は、サポートが終了しています。これから構築する場合は、現行の AWS WAFv2 を使います。
参考: AWS WAFV2 API Reference
“AWS WAF Classic support will end on September 30, 2025”
（AWS WAF Classic のサポートは 2025 年 9 月 30 日に終了します）
https://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html
既存の Classic 環境を運用している場合は、AWS が提供する移行の仕組みで WAFv2 へ移すことが推奨されます。移行時はルールの対応関係を確認し、Count モードで挙動を検証しながら切り替えると安全です。
まとめ
本記事では、AWS WAF の保護対象・構成要素・ルール・料金を、導入の起点となる全体像として整理しました。AWS WAF は HTTP・HTTPS リクエストを L7 で検査するマネージドサービスで、Web ACL を中心に複数の AWS リソースを保護できます。個別のトピックの詳細は、関連するスポーク記事で扱います。
- AWS WAF は L7 でリクエストを検査するマネージド型の WAF
- 保護対象は CloudFront・ALB・API Gateway など 8 種類
- Web ACL を頂点にルール・ルールグループ・IP Set で構成
- マネージドルールで OWASP Top 10 の主要リスクをカバー
- 簡易な bot 対策やレート制限はレートベースルールが低コスト
- 料金は Web ACL・ルール・リクエストの 3 要素が基本
- ログは CloudWatch Logs・S3・Data Firehose へ出力可能
以上、最後までお読みいただきありがとうございました。
