先に要点
- AWS WAF は WAF(Web Application Firewall) のマネージドサービス。CloudFront / ALB / API Gateway の REST API / AppSync などの 前段でリクエストを検査して悪意あるものを止める。「SQL インジェクション・XSS・Bot・レート過剰」 をエッジで止めるのが主な仕事。
- 核となる概念は Web ACL(Access Control List)。Web ACL の中に ルール を並べ、各ルールが 「条件 → アクション(Allow / Block / Count / Captcha / Challenge)」 の組み合わせ。マネージドルール を使うと、「OWASP Top 10 系の主要攻撃」 を最初から検知できる。
- 典型構成は CloudFront + AWS WAF + S3 / ALB / API Gateway。「グローバル配信」 と 「攻撃を最前段で止める」 が両立する。CloudFront にアタッチした WAF は グローバルスコープ、ALB / API Gateway にアタッチした WAF は リージョナルスコープ。
- 料金は ① Web ACL の月額 + ② ルール本数 + ③ リクエスト数。マネージドルールグループも 1 グループあたり月 1 USD、Bot Control などの高度な保護はさらに追加料金がかかる。「大量リクエスト + 多数のルール」 で予想外に伸びるので、必要なものから段階導入 が現実的。
- 判断軸は 「公開 Web か社内専用か」 「Bot トラフィックや DDoS 被害が想定されるか」 「OWASP Top 10 系の防御を仕組み化したいか」。小規模 / 検証用ならスキップ可、本番公開 Web では入れるのが現代の標準。
「AWS で本番運用を始める時、「WAF を入れるべき」 とよく言われるが、実際に何をしてくれるのか曖昧」 ── これは AWS のセキュリティ層を組む時に最初に当たる疑問です。
ざっくり言うと、AWS WAF は CloudFront / ALB / API Gateway の前段で、悪意あるリクエストを 「通すか止めるか」 判定するレイヤ です。SQL インジェクションや XSS のような OWASP Top 10 系の攻撃、Bot トラフィック、レート過剰、特定地域からのアクセスを マネージドルール でまとめて防御できます。
この記事では、AWS WAF の 仕組み・典型構成・料金・ハマりどころ を、「これから本番に入れる前提」 で読みやすい形に整理します。
AWS WAF の仕組み
AWS WAF は、リクエストごとに Web ACL を評価し、ルールに従って Allow / Block / Count / Captcha / Challenge を返す シンプルな仕組みです。
Web ACL とルール
「 Web ACL」 が WAF の設定単位。中に ルール を順番に並べ、「マッチした最初のルール」 のアクションが適用される。ルールには マネージドルール(AWS / ベンダー提供) と カスタムルール(自社定義) がある。
アクションの種類
Allow(通す)、Block(止める)、Count(カウントだけ取って通す = 「観測モード」)、Captcha(CAPTCHA を出す)、Challenge(ブラウザ JS チャレンジ)。新規ルールは まず Count で観測 → 様子を見て Block が定石。
スコープ: グローバル vs リージョナル
CloudFront にアタッチする WAF はグローバルスコープ(us-east-1)、ALB / API Gateway / AppSync にアタッチする WAF はリージョナルスコープ(リソースのリージョン)。設定画面で混同しやすい点。
ルールの評価順序
「 Priority(優先度数値が小さい順)」 でルールが評価され、「マッチした最初のアクション」 で確定。Allow ルールを先頭近くに置きすぎると、後段の Block ルールが効かない 設計ミスが頻発。
マネージドルールを使うのが現代の標準
「自前でルールを書く」 のは現代では稀で、ほとんどのチームは マネージドルールグループ を組み合わせて使います。
| マネージドルールグループ | 内容 | 典型的な用途 |
|---|---|---|
| AWSManagedRulesCommonRuleSet | OWASP Top 10 系の一般的な攻撃(SQLi、XSS、Local File Inclusion など) | ほぼすべての公開 Web で 最初に入れる基本セット |
| AWSManagedRulesKnownBadInputsRuleSet | 既知の悪意あるペイロードを検知 | Common Rule Set とセットで導入が定石 |
| AWSManagedRulesSQLiRuleSet | SQL インジェクション特化 | DB 連携が中心のアプリ |
| AWSManagedRulesLinuxRuleSet | Linux 系コマンドインジェクション | Linux サーバで動くバックエンド |
| AWSManagedRulesAdminProtectionRuleSet | 管理画面パスのアクセスをブロック | 「/admin」 のような典型パスを攻撃から守る |
| AWSManagedRulesBotControlRuleSet | Bot の検知と分類(検証済み Bot の判別、種類ごとの制御) | スクレイピング・在庫荒らし対策 |
| AWSManagedRulesATPRuleSet | Account Takeover Prevention(ログイン総当たり対策) | ログインフォームを持つ B2C サイト |
| AWSManagedRulesAnonymousIpList | VPN / Tor / Proxy 経由のアクセスを検知 | 地域制限が必要なサービス |
「まず CommonRuleSet + KnownBadInputs を Count モードで導入 → 数日観測 → 偽陽性を除外 → Block に切り替え」 が 事故にならない導入手順 の基本パターンです。
レート制限 — 経済的破壊への防御
WAF の レートベースルール は、「同一 IP からの一定時間あたりリクエスト数」 を超えたらブロックする仕組み。DoS / 経済的破壊 / 総当たり攻撃 を仕組みで止めるのに必須です。
基本ルール
「 同一 IP から 5 分間に 2000 リクエストを超えたら Block」 のような閾値を設定。通常ユーザーが踏まない値 を選ぶのがコツ。
ログインフォーム保護
「 /login パスへの POST のみ 1 分間 10 回まで」(レート制限の下限は 10、評価期間は 1・2・5・10 分から選ぶ)のような パス + メソッド + リクエスト数 の組み合わせで、ログイン総当たり攻撃を止める。「認証側の対策(MFA)」 と併用が現代的。
「 /api/* への過剰アクセス」 を WAF で一律制限し、API Gateway の Usage Plan で API キー単位の細かい制御 を組み合わせると、「誰でも触れる API」 と 「契約済みクライアント向け API」 の両方を守れる。
経済的破壊への対策
「 攻撃者のコスト(数千円) ≪ 防御側のコスト(数十万円の請求)」 という非対称さは、サーバレス時代の典型脅威。Vercel の高額請求 や CloudFront の請求暴発 防止の最前線として、レート制限を 必須として設計する。
CloudFront / ALB / API Gateway 連携
WAF はアタッチ先のリソースで動きが少し変わります。それぞれの組み合わせの定石を整理します。
CloudFront + WAF
- 世界中のエッジで攻撃を止める(エッジ防御)
- DDoS 対策との相性が良い(Shield Standard / Advanced)
- 公開 Web の典型構成
- スコープはグローバル(us-east-1)
- S3 / ALB / API Gateway を CloudFront のオリジンに置けば、後段は WAF 不要にできる
ALB + WAF
- VPC 内アプリへの直接アクセスを保護
- リージョナルスコープ
- CloudFront を経由しない社内システムや内部 API で使う
- API Gateway や CloudFront と独立して導入可能
- ALB へのアクセスログとセットで分析しやすい
API Gateway + WAF
「 CloudFront を最前段に置き、後段で必要に応じて追加」 が AWS 前段選択ガイド と整合する現代的な設計です。
料金構造
AWS WAF の料金は 3 軸 で構成され、「想像より高くなりやすい」 ので最初に押さえておきます。
① Web ACL 月額
Web ACL 1 つあたり 月額固定(2026年10月時点で 5 USD、時間単位で日割り)。本番・ステージング・開発を別 ACL にすると、その分料金が積み上がる。
② ルール本数月額
カスタムルールは 1 本あたり月 1 USD。マネージドルールグループも 1 グループあたり月 1 USD。「とりあえず全部入れる」 で月額が積み上がる典型。
③ リクエスト課金
WAF が検査したリクエスト数で課金(100 万リクエストあたり 0.60 USD。Web ACL の WCU が 1,500 を超えると、500 WCU ごとに 100 万リクエストあたり 0.20 USD が加算)。大量トラフィック × 多数のルール で予想外に伸びる。「Bot Control」 や 「ATP」 のような高度なグループは 追加リクエスト課金 が発生する(Bot Control の Common レベルは Web ACL あたり月 10 USD に加え、毎月 1,000 万リクエストを超えた分に 100 万あたり 1 USD)。
節約のコツ
「 必要なマネージドルールだけ」 を選び、「本当に効いているか CloudWatch で確認」 する。「使っていないルール」 を放置しないこと。Count モードで観測 → 偽陽性除外 → Block 化 のプロセスを経ると、無駄ルールが減る。
ハマりやすい設定と回避策
新規導入時に踏みやすい落とし穴を整理します。
偽陽性で正常リクエストが Block される
マネージドルールは 一般的な攻撃パターン を広く検知するため、「管理画面で長い JSON を投げる」 「特殊な検索クエリ」 が誤検知される。まず Count モードで観測 → 該当ルールをラベル単位で除外 → Block 化 の順で進める。
スコープを間違える
「 CloudFront 用 WAF を作りたいのにリージョナルで作ってしまう」。コンソール上で グローバル(CloudFront) と リージョナル の切り替えを最初に確認する。
ルール優先度の設計ミス
「 先頭に Allow を置きすぎて、後段の Block が効かない」 「マネージドルールの優先度が高すぎてカスタムルールが届かない」。「 一般 → 特殊」 か 「特殊 → 一般」 のどちらかで方針を統一する。
ログを取っていない
「 何が止められたか分からない」 では、偽陽性の調査もできない。WAF ログを CloudWatch Logs / S3 / Amazon Data Firehose(旧 Kinesis Data Firehose)に出力 を初日から有効化する。Athena でクエリすると 「どの IP がどのルールに引っ掛かったか」 が見える。
段階的な導入手順
新規プロダクトで WAF を導入する時の現実的な手順をまとめます。
- 11. Web ACL を作成
CloudFront 用なら グローバル(us-east-1)、ALB / API Gateway 用ならリージョナルで Web ACL を作成。CloudFront を将来挟む予定があれば、最初から CloudFront + WAF 構成を取るのが楽。
- 22. AWSManagedRulesCommonRuleSet を Count モードで導入
基本マネージドルールを "Count" モードで適用。CloudWatch メトリクスで "どのルールがどれだけ発火しているか" を観測。
- 33. KnownBadInputs もセットで Count モード
既知の悪意あるペイロード検知ルールも追加。組み合わせで OWASP Top 10 の入力系はかなりカバーされる。
- 44. 1〜2 週間観測して偽陽性を確認
"正常な業務リクエストが Count されている" パターンを特定。該当ルールをラベル除外 or 別パスへ Allow ルールを足す。
- 55. Block モードに切り替え
偽陽性が許容範囲に収まったら、各ルールを Count → Block に切り替え。最初は "重要度の高いルールだけ" から段階的に。
- 66. レートベースルールを追加
"同一 IP から 5 分間で N リクエスト超" のようなレート制限を追加。ログインフォームは別途厳しめに。
- 77. Bot Control / ATP の追加検討
スクレイピングや在庫荒らしが見えるなら Bot Control、ログイン総当たりが見えるなら ATP を追加。料金が上がるので "本当に必要か" を判断してから。
- 8
「一度に全部 Block」 ではなく、Count → 観測 → Block の段階を踏むのが、本番影響を最小限にする鉄則です。
AWS WAF に関するよくある質問
Q. Cloudflare の WAF と比べてどうですか?
A. どちらも実用十分、選び方は周辺サービス次第。AWS WAF は AWS リソース統合の深さ が強み(CloudFront / ALB / API Gateway / WAF / Shield / GuardDuty が一体で動く)、Cloudflare WAF は 無料プランの厚さと世界配信の速さ が強み。「オリジンが AWS なら AWS WAF」 「Cloudflare を最前段に被せるなら Cloudflare WAF」 が素直な選択。
Q. WAF を入れれば OWASP Top 10 は全部対策できますか?
A. インジェクション系・Bot・レート過剰には強いが、認可ロジック(A01)・設計の不備(A06)・ソフトウェアサプライチェーン(A03) は WAF だけでは防げません(番号は最新の OWASP Top 10:2025)。アプリケーション層での対策 + WAF の 多層防御 が必要です。WAF を入れて満足せず、「コード側の対策と組み合わせる」 のが正解。
Q. AWS Shield との関係は?
A. Shield Standard は DDoS 対策で自動で効く(無料)、Shield Advanced は専門サポート付き有料サービス です。WAF は L7 アプリ層の検査、Shield は L3/L4 の DDoS 対策 と役割分担。CloudFront を使えば Shield Standard が自動適用されるので、「CloudFront + WAF」 で標準的な防御層が揃います。
Q. 小規模サイトに AWS WAF は必要ですか?
A. 用途による が正直なところ。「完全に社内・検証用」 なら不要、「公開している Web / API でユーザーがいる」 なら入れる価値あり。「Cloudflare の無料プラン WAF で代替」 も合理的な選択肢。料金は 「Web ACL 5 USD + マネージドルールグループ 2 つで月 7 USD + リクエスト課金」 程度から始まるので、「公開リスクを下げる保険」 と捉えると安いとも言える。CloudFront の定額プランには AWS WAF が含まれるので、それを使う手もある。
Q. レートベースルールの閾値はどう決めますか?
A. 通常ユーザーの最大値の数倍 が出発点です。CloudWatch で 「1 IP からの最大リクエスト数」 を観測し、「観測値の 3〜5 倍」 を初期閾値に。「プロキシ経由で同一 IP に集約される企業ユーザー」 が居る場合は、「Cookie 単位 / セッション単位」 の制限を併用するのが現実的。
Q. WAF ログはどこに出すのが良いですか?
A. 分析重視なら S3 + Athena、リアルタイム重視なら CloudWatch Logs、SIEM 連携なら Amazon Data Firehose。多くのチームは 「S3 + Athena」 で日次分析、「CloudWatch アラーム」 でリアルタイム異常検知、の組み合わせ。S3 + ライフサイクル で古いログを Glacier に流せばコストも抑えられる。
Q. CloudFront 経由のヘッダで送信元 IP を取得するには?
A. X-Forwarded-For ヘッダ を見ます。CloudFront は元の IP を 「X-Forwarded-For」 に入れて後段に渡すため、「ALB / API Gateway / アプリ」 はこのヘッダから取得します。WAF の IP 条件は デフォルトでは TCP の発信元 IP(直前の接続元)を見る 点に注意します。CloudFront 直下では発信元がほぼ実クライアントになりますが、ALB などの背後で実クライアント IP を使いたい場合は、ルールの 「Forwarded IP configuration」で X-Forwarded-For を明示指定 する必要があります(自動考慮ではありません)。
まとめ
AWS WAF は、CloudFront / ALB / API Gateway の前段で OWASP Top 10 系の攻撃を仕組みで止める サービスです。マネージドルールを上手く使えば、「専門知識がなくても標準的な防御層」 を組めるのが現代的な強み。
導入は Count モードで観測 → 偽陽性除外 → Block 化 の手順を守ることが、本番影響を最小限にする鉄則。料金も 「必要なルールだけ」 の段階導入で抑えられます。「まず CloudFront + WAF + CommonRuleSet」 から始めれば、AWS で公開 Web を運用する時の 標準的な防御ライン に到達できます。
参考リンク
- AWS: AWS WAF
- AWS Docs: AWS WAF Developer Guide
- AWS Docs: AWS Managed Rules
- AWS: AWS WAF Pricing
- AWS Docs: Rate-based rule high-level settings
- AWS: AWS Shield
- AWS Blog: AWS WAF best practices