AWS WAFは、AWS環境で公開するWebアプリケーションに届くHTTP/HTTPSリクエストを監視し、条件に応じて許可・ブロック・カウントできるWeb Application Firewallです。SQLインジェクションやクロスサイトスクリプティング（XSS）、不審なBotトラフィック、過剰なリクエストなどに対して、ルールベースで防御を組み立てます。
この記事では、AWS WAFの基本的な役割、主な機能、設定の流れ、利用シーンを整理します。初めて導入を検討する場合は、単に有効化するだけでなく、守りたいリソース、許容する通信、監視方法を先に決めておくことが重要です。
AWS WAFでできること
AWS WAFの中心は、Web ACLと呼ばれるアクセス制御の単位です。Web ACLにルールを追加し、CloudFrontやApplication Load Balancer（ALB）などの保護対象に関連付けることで、Webリクエストを評価できます。CloudFrontの使い方をあわせて整理したい場合は、Amazon CloudFrontの実務解説も参考になります。
- 悪意あるリクエストの制御：SQLインジェクション、XSS、不審なHTTPヘッダー、特定のIPアドレスなど、条件に一致する通信をブロックまたはカウントできます。
- トラフィックの可視化：ルールに一致したリクエストやサンプルリクエストを確認し、CloudWatchメトリクスとあわせて傾向を把握できます。
- 柔軟なルール設計：AWSが提供するマネージドルールを利用しつつ、アプリケーション固有の要件に合わせてカスタムルールを追加できます。
- 段階的な導入：最初はカウントで影響を確認し、誤検知が少ないことを見てからブロックへ切り替える運用ができます。
主な機能
マネージドルールとカスタムルール
AWS WAFでは、一般的な攻撃パターンに対応するAWS管理のルールグループや、AWS Marketplaceで提供されるマネージドルールを利用できます。すべてを自作するよりも、よくある攻撃への初期防御を作りやすい点が利点です。
一方で、業務システムや会員サイトでは、正規ユーザーの通信パターンがサービスごとに異なります。特定のIPアドレス、パス、クエリ文字列、HTTPヘッダー、リクエスト内容に基づいてカスタムルールを作ることで、より細かな制御ができます。
IPレピュテーションと匿名化通信への対策
AWS WAFでは、既知の脅威に関係するIPアドレスや匿名化サービス由来の通信に対応するルールグループを利用できます。ただし、IPベースの制御はネットワーク構成の影響を受けるため、プロキシやロードバランサーを経由する場合は、どのIPアドレスを評価しているかを確認する必要があります。
レートベースのルール
レートベースのルールは、短時間に集中するリクエストを抑えるための機能です。特定のIPアドレスや条件に基づいてリクエスト数を集計し、しきい値を超えた通信に対して制限をかけられます。ログイン、検索、問い合わせフォーム、APIエンドポイントなど、過剰アクセスが問題になりやすい箇所では特に有効です。
より詳しいBot対策やレート制限の設計を確認したい場合は、AWS WAFのマネージドルールとレート制限の解説もあわせて確認すると理解しやすくなります。
AWS Shieldとの組み合わせ
AWS WAFはアプリケーション層のWebリクエスト制御に強みがあります。DDoS対策では、AWS Shieldと組み合わせて考えると設計しやすくなります。高い可用性が必要なサービスや、攻撃時の運用体制まで含めて検討する場合は、Shield Advancedの費用、対象リソース、通知・対応フローも確認しておきましょう。DDoS対策全体の考え方は、AWS Shield完全ガイドで詳しく扱っています。
設定の基本手順
- 保護対象を決める：CloudFront、ALBなど、どのリソースにWAFを適用するかを決めます。まずは外部公開されている入口を優先します。
- Web ACLを作成する：AWS Management ConsoleのWAF画面でWeb ACLを作り、対象リソースとスコープを設定します。
- ルールを追加する：マネージドルールを選び、必要に応じてカスタムルールを加えます。重要なフォームやAPIは、個別に条件を設計すると運用しやすくなります。
- Countで影響を確認する：いきなりBlockにせず、まずはCountで検知状況を確認します。正規ユーザーの通信が誤って止まらないかを見るためです。
- 監視と通知を整える：CloudWatchメトリクス、サンプルリクエスト、ログ出力を確認し、異常時に気づける状態にします。
- 段階的にBlockへ切り替える：誤検知が少ないルールからBlockに変更し、運用しながら調整します。
導入前に確認したい設計ポイント
| 確認項目 | 考え方 |
|---|---|
| 守る対象 | 公開範囲が広いリソース、個人情報や取引情報を扱う画面、攻撃を受けやすいAPIを優先します。 |
| 許容する通信 | 国、IP、ヘッダー、パス、リクエスト頻度など、正規ユーザーの通信条件を把握してから制限します。 |
| 誤検知への対応 | 最初はCountで運用し、業務影響を確認してからBlockへ移行します。 |
| ログと監視 | 攻撃の有無だけでなく、どのルールが反応したか、正規通信に影響が出ていないかを確認します。 |
| 費用と運用体制 | ルール数、ログ出力、Shield Advancedの利用有無などにより費用や運用負荷が変わります。 |
活用しやすいシーン
- ECサイトや会員サービス：ログイン、決済、問い合わせフォームなど、攻撃対象になりやすい画面の保護に向いています。
- 金融・業務システム：SQLインジェクションやXSSなど、アプリケーション層の攻撃をルールで補助的に抑えたい場合に役立ちます。
- 高トラフィックなWebサービス：Botや過剰リクエストへの対応を、レートベースのルールやIP制御と組み合わせて設計できます。
- CMSや公開サイト：管理画面、検索、コメント、フォームなど、外部からアクセスされる入口にルールを適用しやすい構成です。
- 新規サービスやスタートアップ：初期段階から最低限のWeb防御と監視を整えたい場合に、マネージドルールを起点に導入できます。
まとめ
AWS WAFは、AWS上のWebアプリケーションをルールベースで保護するための重要な選択肢です。マネージドルールで基本的な攻撃に備え、カスタムルールでサービス固有の要件を補い、CloudWatchなどで継続的に監視することで、より実務的な防御につながります。
導入時は、どの通信を止めるかだけでなく、どの通信を許可すべきか、誤検知が起きたときにどう確認するか、DDoS対策をAWS Shieldとどう分担するかまで考えることが大切です。まずは保護対象を絞り、Countで影響を見ながら段階的に運用へ移すと、安定したセキュリティ強化を進めやすくなります。