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