Webアプリケーションを狙う攻撃は、いまやネットワーク防御だけでは防ぎきれません。SQLインジェクションやXSSのように「アプリケーションの隙」を突く攻撃が増え続けています。
そこで注目されているのが、AWSが提供するクラウド型WAF「AWS WAF」です。
ただし、WAFは「入れれば安全になる」ものではありません。実際の現場では、ログインAPIが誤検知でブロックされたり、ルールを増やしすぎてコストが跳ねたりといった落とし穴もよくあります。
本記事では、AWS WAFが何を守るのかという基本から、導入時に気になるメリット・料金・設定手順に加えて、
・どのルールから優先して入れるべきか
・誤検知はどこで起きやすいか
・最小構成（例：CloudFront＋WAF）でどう始めるか
といった“実務で迷うポイント”まで踏み込んで整理しています。
「とりあえず入れる」ではなく、「どう設計・運用するか」までイメージできる内容になっています。
AWS WAFとは？
Webアプリケーションへの攻撃をブロック
AWS WAF（Amazon Web Services Web Application Firewall）は、AWSが提供しているWebアプリケーションファイアウォールサービスです。一般的なファイアウォールやIPS/IDSとの違いは次の通りです。
- ファイアウォールやIPS/IDS
主にネットワーク層（L3〜L4レイヤー）での攻撃を防御 - Webアプリケーションファイアウォール
HTTPリクエストやパラメータを悪用する「アプリケーション層（L7レイヤー）」の攻撃を防御
Webアプリケーションでは、HTTPリクエストやパラメータを使った攻撃を受けることが多く、従来型のファイアウォールでは防御が十分ではありません。そこでAWS WAFを導入することで次のような攻撃を検知・ブロックすることが可能になります。
- Webアプリケーション特有の脆弱性を狙う、SQLインジェクション
- クロスサイトスクリプティング（XSS）
- 悪意のあるBot
- DDoS（分散型サービス拒否攻撃）
様々なAWSサービスと連携が可能
AWS上で稼働する下記のリソースと連携して動作できるため、クラウド環境でのセキュリティ対策をシンプルに実装できる点が大きな特徴です。
- Amazon CloudFront（CDN）
- Application Load Balancer（ALB）
- Amazon API Gateway
- AWS AppSync GraphQL API
- Amazon Cognito
- AWS App Runner
- AWS Verified Access
…など
AWS WAFのメリット
1. AWSとの高い親和性
AWSのサービス群とシームレスに統合できることは、AWS WAFの大きな強みです。例えば、CloudFrontやALB、API Gatewayなどと簡単に連携し、Web ACL（アクセス制御リスト）を設定すれば、即座にアプリケーションへの攻撃対策を適用できます。
2. 初期コストを抑えた導入が可能
AWS WAFは、クラウドベースのサービスとして提供されているため、導入時に専用ハードウェアを購入する必要がありません。導入後も従量課金型で、利用したリクエスト数やルール数に応じて料金が決まるため、初期投資を抑えつつスモールスタートが可能です。
3. 高い拡張性（スケーラビリティ）
物理的な制約を受けないクラウドの利点を活かし、アクセス量が増えた場合にも自動的にスケールします。アプリケーションの負荷に合わせてAWS WAFが処理を拡大するので、DDoSのような大量のリクエスト攻撃にも対応しやすいです。
4. 柔軟なルール設定と管理
AWSが提供しているマネージドルールを利用すれば、一般的なWeb攻撃（OWASP Top10など）への対策をすぐに始められます。加えて、各企業の環境に合わせて独自ルール（カスタムルール）を設定することも可能です。特定のIPアドレスからのリクエストをブロックしたり、国（Geo）ごとにアクセスを制限するなど、柔軟な運用ができます。
AWS WAFの主要機能
1. アプリケーション攻撃の防御
SQLインジェクションやクロスサイトスクリプティング（XSS）のように、Webアプリケーションの脆弱性を狙った攻撃を検知・遮断します。マネージドルールを適用するだけで、代表的な攻撃手法に対してあらかじめ用意されたフィルタリングを有効化可能です。
2. IP制限による不正アクセス遮断
怪しいIPアドレスや悪意あるBotからのリクエストをブロックできます。AWSが収集したIPレピュテーションデータや、ユーザーが独自に作成したIPアドレスリストを活用してアクセスを制御します。
3. DDoS攻撃対策
L7レイヤーのDDoS攻撃に対して、Rate-based ルールで一定の時間に大量リクエストを発生するIPアドレスを自動ブロックするなどの方法があります。また、AWS Shield Standard（無料）と組み合わせればネットワーク層の攻撃にも対応可能です。
4. ログ（アクセス解析）機能
AWS WAFでブロックしたリクエストや許可したリクエストをログ化し、Amazon S3やAmazon Kinesis Data Firehoseに送信して分析できます。セキュリティ監視や、誤検知・過検知の調整にも役立ちます。
5. マネージドルールとカスタムルール
- マネージドルール
AWSやサードパーティが提供する標準ルールセット。OWASP Top10をはじめ、悪意あるBotやWordPress向けの特化型ルールなど多彩な選択肢があります。 - カスタムルール
自社のWebアプリケーションの要件に合わせて、独自条件（IPアドレス、HTTPヘッダー、正規表現マッチなど）を指定できます。
AWS WAFの導入方法
AWS WAFの導入ステップは大きく以下のとおりです。
- AWSコンソールでWAFを有効化
AWSマネジメントコンソールにログインし、WAFサービスを選択します。新規でWeb ACL（アクセスコントロールリスト）を作成するか、既存のWeb ACLを再利用するかを選びます。 - Web ACLの設定
- 名前やCloudWatchで使用するメトリクス名を指定。
- ルール群（マネージドルールや独自ルール）を追加。
- デフォルトのアクション（Allow or Block）を設定。
- ターゲットリソースの関連付け
保護対象となるAWSリソース（例：CloudFront、ALB、API Gatewayなど）をWeb ACLに紐付けます。これで対象リソースへのリクエストはAWS WAFを経由し、攻撃が検知されれば遮断されます。 - テスト運用（Countモード）
いきなり“Blockモード”にすると正規ユーザーのアクセスも誤ってブロックしてしまう可能性があります。まずは“Countモード”でどのようなアクセスが引っかかるかをモニタリングし、問題なければ“Blockモード”に切り替えるのがおすすめです。 - 本番運用開始
“Countモード”の結果を確認・調整しながら、本番環境では最終的に“Blockモード”を有効にします。あとはアプリケーションの変更や新しい脅威が発覚したタイミングでルールをアップデートしていきます。
AWS WAFの料金体系
AWS WAFの利用料金は主に以下の3要素で構成されます。
- Web ACL月額費用
1つのWeb ACLごとに月額料金が発生します。 - ルール月額費用
Web ACLに追加したカスタムルールやマネージドルールごとに月額がかかります。 - リクエスト数
WAFが処理したリクエスト数（100万リクエスト単位）に対して課金が行われます。
具体的な価格はAWS公式の料金ページをご確認ください。
基本的にはWeb ACL数が多い、あるいはルール数が多い、リクエスト数が多いほどコストが増加します。無闇に多くのルールを作成せず、Webアプリケーションの特性に合わせて設計することがポイントです。
AWS WAF導入・運用時のポイント
1. 誤検知（False Positive）の対策
マネージドルールを適用すると、正規ユーザーのリクエストがブロックされてしまう場合があります。最初は”Countモード“で挙動を確認し、誤検知が発生したら例外設定（除外設定）を加えていく運用が一般的です。
2. 運用工数を削減する工夫
AWS WAFは柔軟性が高い反面、運用担当にセキュリティやアプリケーションの知識が求められるため、ルールのチューニングが負担になる場合があります。
外部のWAF自動運用サービスやマネージドセキュリティサービスを利用して、ルールの更新やログ分析を委託する企業も増えています。
3. DDoS対策との組み合わせ
L7レイヤーの大量リクエストをRate-based ルールでブロックするのは有効ですが、さらにネットワーク層のDDoS攻撃から守るためにはAWS Shield StandardやAWS Shield Advancedの導入も検討しましょう。
4. 定期的なルール見直し
Webアプリケーションがバージョンアップしたり、新たなセキュリティ脅威が報告された場合はルールの再調整や追加が必要です。AWS WAFのログやクラウド監視ツールを活用して、定期的にチューニングを行いましょう。
関連するFAQ
Q. AWS WAFは何を防ぐサービスですか？
A. HTTPリクエストを解析し、SQLインジェクションやXSSなどのアプリケーション層（L7）の攻撃を検知・遮断するサービスです。従来のファイアウォールでは防ぎにくい入力値やパラメータを悪用した攻撃に対応します。
Q. AWS Shieldとの違いは何ですか？
A. AWS WAFはアプリケーション層（L7）の攻撃対策、AWS Shieldはネットワーク層（L3/L4）のDDoS対策が中心です。実運用では「Shieldでトラフィックを受け止め、WAFで中身を検査する」という役割分担で併用されることが多いです。
Q. マネージドルールだけで十分ですか？
A. 基本的な防御は可能ですが、それだけでは不十分なケースが多いです。例えばログインAPIや検索機能は誤検知が起きやすく、除外設定やカスタムルールでの調整がほぼ必須になります。
Q. 導入時に気をつけるポイントは？
A. 最初からBlockモードにせず、Countモードでログを確認することが重要です。特に「/login」「/api/*」など動的エンドポイントは誤検知が出やすいため、どのルールが引っかかっているかを確認してから遮断に切り替えます。
Q. AWS WAFの料金はどのように決まりますか？
A. Web ACL数・ルール数・リクエスト数の従量課金です。目安として、Web ACL 1つ＋マネージドルール1つ＋月100万リクエストで数ドル〜十数ドル程度から始まりますが、ルール追加やトラフィック増加で大きく変動します。また、各ルールにはWCU（Web ACL Capacity Unit）があり、上限を超える構成は組めない点にも注意が必要です。
Q. コストが高くなるのはどんなときですか？
A. マネージドルールを複数追加したり、リクエスト数が増えた場合にコストが伸びます。特に「とりあえず全部有効化」は無駄が多く、必要なルールから段階的に適用するのが実務的です。
Q. 小規模なサイトでも導入すべきですか？
A. はい。公開している以上は自動スキャンの対象になります。CloudFront＋WAF＋マネージドルール1つという最小構成で、低コストから始めるケースも一般的です。
Q. 誤検知はどれくらい起きますか？
A. アプリケーションの作りによりますが、初期状態では一定確率で発生します。特にフォーム入力やAPIは影響を受けやすく、「完全にゼロにはならない前提で調整する」のが現実的です。
Q. WAFだけでセキュリティは十分ですか？
A. 不十分です。WAFはあくまでリクエストの入口対策であり、アプリケーションの脆弱性そのものは防げません。入力バリデーションや認証設計など、アプリ側の対策と組み合わせる必要があります。
Q. CloudFrontを使わなくてもAWS WAFは使えますか？
A. はい。ALBやAPI Gatewayなどにも直接適用できます。ただし、CDNとしての防御やキャッシュも含めて考える場合はCloudFront＋WAF構成がよく採用されます。
Q. 運用では何を見ればいいですか？
A. 主に「どのルールでブロックされたか」「どのパスに対して発生しているか」をログで確認します。特定のURLだけ誤検知が多い場合は、そのルールの除外設定を検討するのが基本的な運用フローです。
まとめ
AWS WAFを導入することで、Webアプリケーション層のセキュリティを大幅に強化できます。AWSの各種サービス（CloudFront、ALB、API Gatewayなど）に容易に連携できるうえ、スケーラブルに動作し、初期コストを抑えて導入できるのが最大の魅力です。
一方で、ルール調整や運用管理には一定の知識と工数が必要です。マネージドルールだけでは誤検知が発生する可能性もあるため、事前に”Countモード”で挙動をチェックしながら導入を進めると安心です。
また、DDoSなどの大量リクエスト攻撃や日々進化する新たな脆弱性に対抗するには、AWS ShieldやWAF自動運用サービスとの併用も視野に入れるとよいでしょう。
WebサイトやAPIを安全に公開するためには、AWS WAFは欠かせないクラウド時代のセキュリティサービスです。ぜひ本記事を参考に、自社のWebアプリケーションやAWS環境に最適な導入・運用方法を検討してみてください。