先に要点
- AWS WAF は WAF(Web Application Firewall) のマネージドサービス。CloudFront / ALB / API Gateway / 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 グループあたり追加月額 がかかる。「大量リクエスト + 多数のルール」 で予想外に伸びるので、必要なものから段階導入 が現実的。
- 判断軸は 公開 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 検知と分類(Good Bot / Bad Bot / Verified Bot) | スクレイピング・在庫荒らし対策 |
| AWSManagedRulesATPRuleSet | Account Takeover Prevention(ログイン総当たり対策) | ログインフォームを持つ B2C サイト |
| AWSManagedRulesAnonymousIpList | VPN / Tor / Proxy 経由のアクセスを検知 | 地域制限が必要なサービス |
「まず CommonRuleSet + KnownBadInputs を Count モードで導入 → 数日観測 → 偽陽性を除外 → Block に切り替え」 が 事故らない導入手順 の基本パターンです。
レート制限 — 経済的破壊への防御
WAF の レートベースルール は、「同一 IP からの一定時間あたりリクエスト数」 を超えたらブロックする仕組み。DoS / 経済的破壊 / 総当たり攻撃 を仕組みで止めるのに必須です。
基本ルール
「 同一 IP から 5 分間に 2000 リクエストを超えたら Block」 のような閾値を設定。通常ユーザーが踏まない値 を選ぶのがコツ。
ログインフォーム保護
「 /login パスへの POST のみ 1 分間 5 回まで」 のような パス + メソッド + リクエスト数 の組み合わせで、ログイン総当たり攻撃を止める。「認証側の対策(MFA)」 と併用が現代的。
「 /api/* への過剰アクセス」 を WAF で一律制限し、API Gateway の Usage Plan で API キー単位の細かい制御 を組み合わせると、「誰でも触れる API」 と 「契約済みクライアント向け API」 の両方を守れる。
経済的破壊への対策
「 攻撃者のコスト(数千円) ≪ 防御側のコスト(数十万円の請求)」 という非対称さは、サーバレス時代の典型脅威。Vercel の高額請求 や CloudFront の請求暴発 防止の最前線として、レート制限を 必須として設計する。
CloudFront / ALB / API Gateway 連携
WAF はアタッチ先のリソースで動きが少し変わります。それぞれの組み合わせの定石を整理します。
「 CloudFront を最前段に置き、後段で必要に応じて追加」 が AWS 前段選択ガイド と整合する現代的な設計です。
料金構造
AWS WAF の料金は 3 軸 で構成され、「想像より高くなりやすい」 ので最初に押さえておきます。
② ルール本数月額
カスタムルールは 1 本あたり月額(約 1 USD)。マネージドルールグループも グループ単位で月額(数 USD 〜)。「とりあえず全部入れる」 で月額が積み上がる典型。
③ リクエスト課金
WAF が検査したリクエスト数で課金(100 万リクエストあたり約 0.6 USD)。大量トラフィック × 多数のルール で予想外に伸びる。「Bot Control」 や 「ATP」 のような高度なグループは 追加リクエスト課金 が発生する。
節約のコツ
「 必要なマネージドルールだけ」 を選び、「本当に効いているか CloudWatch で確認」 する。「使っていないルール」 を放置しないこと。Count モードで観測 → 偽陽性除外 → Block 化 のプロセスを経ると、無駄ルールが減る。
ハマりやすい設定と回避策
新規導入時に踏みやすい落とし穴を整理します。
偽陽性で正常リクエストが Block される
マネージドルールは 一般的な攻撃パターン を広く検知するため、「管理画面で長い JSON を投げる」 「特殊な検索クエリ」 が誤検知される。まず Count モードで観測 → 該当ルールをラベル単位で除外 → Block 化 の順で進める。
スコープを間違える
「 CloudFront 用 WAF を作りたいのにリージョナルで作ってしまう」。コンソール上で グローバル(CloudFront) と リージョナル の切り替えを最初に確認する。
ルール優先度の設計ミス
「 先頭に Allow を置きすぎて、後段の Block が効かない」 「マネージドルールの優先度が高すぎてカスタムルールが届かない」。「 一般 → 特殊」 か 「特殊 → 一般」 のどちらかで方針を統一する。
ログを取っていない
「 何が止められたか分からない」 では、偽陽性の調査もできない。WAF ログを CloudWatch Logs / S3 / Kinesis Firehose に出力 を初日から有効化する。Athena でクエリすると 「どの IP がどのルールに引っ掛かったか」 が見える。
段階的な導入手順
新規プロダクトで WAF を導入する時の現実的な手順をまとめます。
「一度に全部 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)・設計の不備(A04)・古いコンポーネント(A06) は WAF だけでは防げません。アプリケーション層での対策 + 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 で代替」 も合理的な選択肢。「料金は月額数百円〜数千円から始まる」 ので、「公開リスクを下げる保険」 と捉えると安いとも言える。
Q. レートベースルールの閾値はどう決めますか?
A. 通常ユーザーの最大値の数倍 が出発点です。CloudWatch で 「1 IP からの最大リクエスト数」 を観測し、「観測値の 3〜5 倍」 を初期閾値に。「プロキシ経由で同一 IP に集約される企業ユーザー」 が居る場合は、「Cookie 単位 / セッション単位」 の制限を併用するのが現実的。
Q. WAF ログはどこに出すのが良いですか?
A. 分析重視なら S3 + Athena、リアルタイム重視なら CloudWatch Logs、SIEM 連携なら Kinesis Firehose。多くのチームは 「S3 + Athena」 で日次分析、「CloudWatch アラーム」 でリアルタイム異常検知、の組み合わせ。S3 + ライフサイクル で古いログを Glacier に流せばコストも抑えられる。
Q. CloudFront 経由のヘッダで送信元 IP を取得するには?
A. X-Forwarded-For ヘッダ を見ます。CloudFront は元の IP を 「X-Forwarded-For」 に入れて後段に渡すため、「ALB / API Gateway / アプリ」 はこのヘッダから取得します。WAF のルール条件で 「送信元 IP」 を選ぶと自動で 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 Shield
- AWS Blog: AWS WAF best practices