AWS WAF徹底解説：マネージドルール・レート制限・Bot対策で守るWeb防御、GCP Cloud Armor・Azure WAF比較つき
はじめに：WAFは「最後の砦」ではなく、設計で効かせる“運用の仕組み”です
WebアプリやAPIが成長すると、攻撃も“雑”から“現実的”に変わっていきます。たとえば、SQLインジェクションやXSSのような定番攻撃に加え、ログイン試行の自動化、スクレイピング、在庫/予約の買い占め、検索窓への高頻度アクセスなど、ビジネスに直結する嫌なトラフィックが増えやすいです。こうした「アプリ層（Layer 7）の攻撃」に対して、クラウド上で比較的すばやく・統制を効かせながら対策を重ねられるのが AWS WAF（Web Application Firewall）です。:contentReference[oaicite:0]{index=0}
AWS WAFは、保護対象リソースに転送されるHTTP(S)リクエストを監視し、条件に応じて許可・ブロック・カウント（検知のみ）などのアクションを取れる、と公式に説明されています。保護できるリソースとして、CloudFront、API Gateway（REST API）、Application Load Balancer、AppSync、Cognito、App Runner、Verified Access、Amplify などが挙げられています。:contentReference[oaicite:1]{index=1}
この記事では、AWS WAFを「とりあえず入れる」から一段進めて、ルールの組み立て方、誤検知（False Positive）を抑えるコツ、コストの読み方、ログ/運用設計までを、実務の目線で丁寧にまとめます。さらに、同等領域として比較されやすい GCP Cloud Armor と Azure Web Application Firewall（WAF）も並べ、マルチクラウドでも判断がブレにくい“共通の物差し”を作ります。:contentReference[oaicite:2]{index=2}
この記事が役に立つ方：どんなチームに効くのか
1) アプリ開発チーム（バックエンド/フロント）で、防御を「後回し」にしがちな方
WAFはセキュリティ担当だけの道具に見えますが、実際はアプリ改善と密接です。たとえば、検索APIの乱用をレート制限する、ログインのボットを減らす、特定の脆弱性パターンを先にブロックする。こうした施策は、アプリの可用性やコストにも直結します。AWS WAFはSQLiやXSSのような一般的な攻撃パターンのブロック、ボットの監視/ブロック/レート制限などを行える、と紹介されています。:contentReference[oaicite:3]{index=3}
2) SRE/運用担当で、障害時に「攻撃か不具合か」の切り分けがつらい方
障害時にアクセスが急増していると、原因がDDoSっぽいのか、SNS拡散なのか、ボットなのか、アプリ不具合なのか、初動で迷いがちです。WAFのログとルール運用が整っていると、切り分けが格段に速くなります。監視というより“運用の証跡”としてWAFを整えるのがポイントです。
3) 情シス/セキュリティ担当で、監査や顧客要件に「説明できる防御」が必要な方
「WAF入れてます」だけでは足りず、「どのルールで、何を守っていて、誤検知をどう管理していて、例外はどう扱っているか」を問われる場面が増えます。AWS WAFはWeb ACL・ルール・リクエスト数に基づく料金と、ルールの組み立てによる制御が明確なので、設計書に落としやすいです。:contentReference[oaicite:4]{index=4}
1. AWS WAFの全体像：Web ACLとルールで「通してよいリクエスト」を定義する
AWS WAFの基本単位は Web ACL（アクセスコントロールリスト）です。Web ACLの中にルール（またはルールグループ）を並べ、リクエストが来たときに「どの条件に一致するか」を評価して、許可/ブロックなどのアクションを実行します。
この“並べて評価する”という性質は、運用の現場ではとても大事です。なぜなら、同じ攻撃でも、サイトの作りによって「ブロックすべき」「例外として許すべき」が変わるからです。たとえば、CMSや検索機能があると、クエリ文字列に記号が多く含まれやすく、マネージドルールが誤検知することもあります。AWS WAFにはマネージドルールを使って時間を節約できる、と示されていますが、同時に“自分たちのアプリに合わせて調整する余地”を最初から見込むのが現実的です。:contentReference[oaicite:5]{index=5}
2. 保護できる対象：AWS WAFは「入口」に置くのが基本
AWS WAFは、保護対象に転送されるHTTP(S)リクエストを監視する仕組みで、CloudFront、API Gateway（REST API）、Application Load Balancerなど複数の入口リソースを保護できる、と公式に列挙されています。:contentReference[oaicite:6]{index=6}
実務での考え方はシンプルです。
- まず“外部から来る入口”を洗い出す（CDN、ロードバランサー、API入口など）
- 入口にWAFを置いて、アプリに届く前に止められるものを止める
- アプリ内の認可・レート制限などは、WAFと役割分担する
WAFは万能ではないので、「アプリで守るべきもの」「WAFで止めるべきもの」の線引きを先に決めると、ルール設計がぶれにくいです。
3. ルール設計の基本：まず“マネージドルール＋レート制限”から始めるのが安定です
AWS WAFの強みは、ゼロから正規表現で頑張るのではなく、よくある攻撃に対する“マネージドルール”をベースにしながら、必要なところだけ自前ルールで補強できる点です。公式ページでも、SQLiやXSSといった一般的な攻撃パターンをブロックできること、マネージドルールで時間を節約できることが述べられています。:contentReference[oaicite:7]{index=7}
設計のおすすめ順（現場で揉めにくい順）
- まず「検知（Count）」で当ててみる
いきなりBlockにすると、誤検知で正規ユーザーを弾いてしまいがちです。最初はCountでログを取り、どのルールが何に反応しているかを把握します。 - 次に「レート制限（Rate-based）」を入れる
攻撃かどうか判別しづらい“高頻度アクセス”は、最初から抑える価値があります。ログイン、検索、パスワードリセット、在庫照会などに効きます。 - 最後に「業務に合わせた例外（Allow/Scope-down）」を付ける
管理画面のIP制限、ヘルスチェックの除外、特定パスの例外など、運用に必要な穴を“明文化”して入れます。
この順番で進めると、アプリ側の改善（入力検証、エラーレスポンスの整理、ボット耐性）と並行して、WAFを安全に強化できます。
4. 料金の読み方：WAFは「Web ACL数・ルール数・リクエスト数」で効いてきます
AWS WAFの料金は、Web ACL（1つあたり月額）、ルール（またはルールグループ）あたり月額、そして処理されたWebリクエスト数（100万件あたり）という構造で説明されています。米国サイトでは Web ACLが$5/月、ルールが$1/月、リクエストが100万あたり$0.60 という例示があり、具体的なケース計算も掲載されています。:contentReference[oaicite:8]{index=8}
つまり、コスト管理のコツは次の3つです。
- Web ACLを増やしすぎない（環境や用途の境界は必要だが、細分化しすぎると固定費が増えやすい）
- ルールを増やしすぎない（同じ目的のルールが乱立すると、運用もコストも肥大化）
- リクエスト数が多い入口ほど、ルール設計の“効率”が重要（過剰に検査しすぎない）
ボット対策など追加機能（Bot Control等）は別料金になるケースがあるため、導入の際は「どこまでWAFでやるか」を要件として固めてから見積もるのが安全です。:contentReference[oaicite:9]{index=9}
5. 実務サンプル：よくある3パターンを“型”として持っておく
ここからは、チームで共有しやすいように、WAF導入の典型パターンをサンプルとしてまとめます。コードそのものより「考え方」を中心にしています。
サンプルA：APIを守る「マネージドルール＋レート制限」の最小セット
目的：SQLi/XSSなどの定番攻撃を止めつつ、乱用されやすいAPIをレート制限する。
- ルール1：AWS管理のマネージドルールグループ（まずCountで様子見 → 問題なければBlockへ）:contentReference[oaicite:10]{index=10}
- ルール2：
/loginと/password-resetにレート制限（IP単位で分あたりn回など） - 例外：社内IPや監視のヘルスチェックは除外（Allow/Scope-down）
この型は、スピード重視のプロダクトで特に効きます。「完璧な判定」より「悪い影響が大きいものから止める」のがコツです。
サンプルB：静的サイト/フロントを守る「国・IP・パス」ベースの整理
目的：攻撃が特定地域や特定ASから偏っているとき、入口で絞る。
- ルール1：国（Geo）条件で明確に不要な国をブロック
- ルール2：悪性IPレンジをブロック（運用で更新できる形に）
- ルール3：管理画面パス（例：
/admin）はAllowlist（社内IPやVPN）以外ブロック
“国ブロック”はビジネス要件と衝突しやすいので、意思決定の記録（どの国をなぜブロックするか）を残すと、後で揉めにくいです。
サンプルC：誤検知が怖いときの「Count → 段階Block」の運用テンプレ
目的：導入直後の誤検知でユーザー体験を壊さない。
- 週1回、Countログをレビューし、誤検知を洗い出す
- 例外条件を追加（特定パス、特定ヘッダー、特定クエリなど）
- それでも悪性が濃いルールだけ先にBlockへ
- 影響が読めないルールはCountのまま保留（“入れてあるのに効かせていない”状態を許容する）
WAFは「全部Blockにして強い」ではなく、「運用で強くしていける」ことが価値です。最初から完成形を目指さないほうが、長期的にうまくいきます。
6. AWS WAFとAWS Shieldの関係：レイヤーが違うので役割分担が大切
AWSの判断ガイドでは、AWS WAFはアプリケーションレイヤー（Layer 7）でHTTP/SトラフィックをフィルタしてWebアプリを守り、SQLi/XSS/CSRFなどの一般的なWeb攻撃に対処する、と説明されています。:contentReference[oaicite:11]{index=11}
この整理はとても重要で、WAFだけで大規模DDoSのすべてを解決しようとすると、設計が歪みやすいです。レイヤーの違いを理解して、「L7の攻撃・ボット・悪性パターン」はWAF、「ネットワーク層の大規模攻撃」は別の保護（サービス側機能やDDoS対策）へ、と役割を分けると、判断が安定します。
7. GCP Cloud Armorとの比較：WAF＋DDoS保護を“ポリシー”で運用する
GCPの Cloud Armor は、WAFとDDoS対策を含む形で語られることが多く、料金ページには「セキュリティポリシー（保護対象）」「リクエスト（100万あたり）」などの料金軸が提示されています。:contentReference[oaicite:12]{index=12}
また、Enterpriseの概要では、価格が「ポリシー/ルール/リクエスト」などの単位で整理され、一定の基本料金（例：プロジェクトあたり月額）や保護対象リソースあたりの課金が示されています。:contentReference[oaicite:13]{index=13}
AWS WAFと比べたときの整理の仕方としては、次が分かりやすいです。
- AWS：Web ACLとルール（ルールグループ）を積み上げる感覚:contentReference[oaicite:14]{index=14}
- GCP：セキュリティポリシーを中心に、保護対象とリクエストを管理する感覚:contentReference[oaicite:15]{index=15}
設計・運用としてはどちらも「入口でフィルタし、例外を作り、ログでチューニングする」点は同じです。違いは、料金単位と管理の見せ方（ポリシー中心か、ACL中心か）に出やすいです。
8. Azure WAFとの比較：Front Door/App Gatewayなど“入口サービスと一体”で考える
AzureのWeb Application Firewallは、Azure Front Door Premiumに含まれる形で案内されており、Front Door（クラシック）などでは固定月額＋要求ベースなどの料金要素がある、と説明されています。:contentReference[oaicite:16]{index=16}
さらに英語の料金ページでは、Application Gateway for Containers WAFやフロントエンドのWAF policy時間課金など、入口サービスに紐づく課金単位が提示されています。:contentReference[oaicite:17]{index=17}
Azure側は「WAF単体」よりも「どの入口に付けるか」で見え方が変わる印象があります。実務の判断軸は次の通りです。
- CDN/グローバル入口（Front Door）で守りたいのか
- リージョン内のロードバランサー的入口（Application Gateway）で守りたいのか
- その入口が既にあるのか、これから選ぶのか
つまり、AzureのWAF選定は、入口サービス選定と一体で進むことが多いです。料金も「WAFが含まれる」「WAF policyの時間課金がある」など、入口に紐づいて決まるため、設計段階で“入口の形”を先に固めるのが大切です。:contentReference[oaicite:18]{index=18}
9. マルチクラウドでぶれない比較軸：WAF選定はこの6項目で整理すると楽です
AWS WAF、Cloud Armor、Azure WAFを横並びで比較する際、細かな機能差に入る前に、次の6項目で整理すると意思決定が安定します。
- どこに置くか（入口リソース）
- 何を止めるか（SQLi/XSS、ボット、レート制限、国/IP制限など）:contentReference[oaicite:19]{index=19}
- どう例外を作るか（管理画面、ヘルスチェック、正規クローラなど）
- 失敗/誤検知の運用（Countで検知→段階Block、レビュー頻度）
- ログ/監査の設計（誰が見て、どこに保管し、どれだけ保持するか）
- 料金の単位（AWSはWeb ACL/ルール/リクエスト、GCPはポリシー/リクエストなど、Azureは入口サービスと一体になりやすい）:contentReference[oaicite:20]{index=20}
この6項目が揃うと、クラウドが違っても「判断の土台」が同じになり、会議がかなり楽になります。
10. まとめ：AWS WAFは“導入”より“育て方”で価値が決まります
AWS WAFは、HTTP(S)リクエストを監視し、条件に応じて制御できるWebアプリケーションファイアウォールであり、CloudFront、API Gateway、ALBなど複数の入口に適用できると公式に説明されています。:contentReference[oaicite:21]{index=21}
また、SQLi/XSSなどの一般的な攻撃に対するマネージドルールを活用でき、ボットの監視/ブロック/レート制限といった“現実的に困るトラフィック”への対策も取りやすいのが魅力です。:contentReference[oaicite:22]{index=22}
そして、料金はWeb ACL・ルール（ルールグループ）・リクエスト数という単位で積み上がるため、設計の段階からコストの増え方を読みやすいです。:contentReference[oaicite:23]{index=23}
GCP Cloud Armorはポリシー中心の見せ方で料金単位が整理され、Azure WAFはFront DoorやApplication Gatewayなど入口サービスと一体で考える場面が多い、という違いがあります。:contentReference[oaicite:24]{index=24}
ただし、どのクラウドでも本質は同じで、「入口で止められるものを止め、誤検知を運用でチューニングし、例外をルールとして明文化する」ことが、長く効く防御になります。
もし次の一歩を選ぶなら、まずは次のどれか1つから始めてみてください。
- マネージドルールをCountで入れ、誤検知の傾向を1週間だけ可視化する
- ログイン/検索など“乱用されやすいAPI”にレート制限を入れる
- 管理画面の入口をIP制限し、例外運用を手順ではなくルールに落とす
小さく始めて、でも運用は丁寧に。そうするとWAFは、セキュリティだけでなく、可用性とコストにも効く“頼れる仕組み”として育っていきますよ。
参考リンク（公式情報中心）
- AWS WAF（開発者ガイド：概要） :contentReference[oaicite:25]{index=25}
- AWS WAF（製品ページ） :contentReference[oaicite:26]{index=26}
- AWS WAF 料金（グローバル） :contentReference[oaicite:27]{index=27}
- AWS WAF 料金（日本語） :contentReference[oaicite:28]{index=28}
- AWS WAF と AWS Shield の選び分け（Decision Guide） :contentReference[oaicite:29]{index=29}
- Google Cloud Armor 料金 :contentReference[oaicite:30]{index=30}
- Cloud Armor Enterprise overview（価格体系の考え方） :contentReference[oaicite:31]{index=31}
- Azure Web Application Firewall 価格（日本語） :contentReference[oaicite:32]{index=32}
- Azure Web Application Firewall 価格（英語） :contentReference[oaicite:33]{index=33}