2026.09.30 ｜ Writer：NTT東日本アベ

AWS WAFの設定方法・使い方｜Web ACLやルールの作成、テスト・ログ確認まで解説

AWS WAFを適切に利用するには、Web ACLやルールの役割を理解して設定し、テストやログの確認を通じて継続的に調整することが大切です。設定しただけで運用を終えると、正規の通信を誤って遮断したり、不正な通信を適切に検出・遮断できなかったりする可能性があります。

本記事では、Web ACLと各種ルールの作成方法、条件に一致したリクエストを遮断せずに記録するCountモードを使ったテスト、ログの設定・確認方法を順に解説します。料金の見積もり方や運用時のポイント、運用を外部へ委託する方法も紹介しますので、AWS WAFの導入や設定の見直しにお役立てください。

なお、AWS WAFの新しいコンソールでは、Web ACLが「Protection Pack（Web ACL）」と表示されます。本記事では、原則として「Web ACL」と表記します。

1. AWS WAFを設定する前に確認する4つの要素
2. AWS WAFの設定方法: 2-1. Web ACLの基本情報と保護対象を設定する; 2-2. AWSマネージドルールを追加する; 2-3. カスタムルールとレートベースルールを追加する; 2-4. ルールの優先順位とデフォルトアクションを設定する
3. AWS WAFのルールをテストする方法: 3-1. Countモードで一致するリクエストを確認する; 3-2. サンプルリクエストとメトリクスを確認する; 3-3. 誤検知を調整してBlockへ切り替える
4. AWS WAFのログを設定・確認する方法: 4-1. ログの出力先を準備する; 4-2. Web ACLのログを有効化する; 4-3. ログから検出内容と誤検知を確認する
5. AWS WAFの料金と見積もり方法: 5-1. AWS WAFの基本的な料金項目; 5-2. AWS Pricing Calculatorを用いた月額料金の見積もり方法
6. AWS WAFを運用するときのポイント
7. AWS WAFの設定・運用を支援するNTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」
8. AWS WAFの設定に関するよくある質問: 8-1. AWS WAFの設定はコードで管理できますか？; 8-2. AWS WAFのルールはどの順番で評価されますか？; 8-3. AWS WAFの設定・運用は外部に委託できますか？
9. AWS WAFの設定と運用を継続的に見直そう

1. AWS WAFを設定する前に確認する4つの要素

AWS WAFは、Webアプリケーションへのリクエストを検査し、設定した条件に基づいて許可や遮断などを行うWebアプリケーションファイアウォールです。設定を始める前に、次の4つの要素を整理しましょう。

横にスクロールします

確認する要素	決める内容	主な確認ポイント
保護対象	Web ACLを関連付けるAWSリソース	保護するリソースとリージョンを確認する
防ぎたい脅威	検査・遮断するリクエスト	優先して対処する攻撃やアクセスを明確にする
ルールの構成	利用するルールと評価順序	ルールの種類、優先順位、デフォルトアクションを決める
運用体制	テスト・監視・見直しの方法	テストやログ確認、誤検知対応の手順と担当者を決める

Web ACLとは、リクエストを検査するルールと、どのルールにも一致しなかった場合の処理（デフォルトアクション）などをまとめた設定単位です。リージョンとは、AWSがサービスを提供する地理的な地域です。Web ACLを設定する際は、保護対象に応じて適切なリージョンを選ぶ必要があります。

これらが曖昧なまま設定すると、正規のリクエストを誤って遮断したり、不正なリクエストを適切に検出・遮断できなかったりするおそれがあります。まずは保護対象と目的を絞り、運用できる構成から始めましょう。

関連コラム：AWS WAFとは？用途・メリットや料金体系から設定方法まで解説

2. AWS WAFの設定方法

AWS WAFは、保護対象へ関連付けるWeb ACLを作成し、必要なルールと処理内容を設定して利用します。ここでは、AWSマネジメントコンソールからWeb ACLを設定する方法を4つのステップで解説します。

2-1. Web ACLの基本情報と保護対象を設定する

AWS WAFのコンソールを開き、「Web ACLを作成」を選択します。Web ACL名やリソースタイプを入力し、保護対象に応じてリージョンを指定しましょう。Web ACL名は作成後に変更できないため、環境や用途を識別できる名前にします。

コンテンツ配信サービスであるAmazon CloudFrontを保護する場合は、グローバルのリソースタイプを選択します。Webアプリケーションへの通信を振り分けるApplication Load Balancerや、APIを作成・管理するAmazon API Gatewayを保護する場合は、対象リソースと同じリージョンを選んでください。

次に、保護するAWSリソースをWeb ACLへ関連付けます。リソースはWeb ACLの作成後に関連付けることも可能です。

2-2. AWSマネージドルールを追加する

続いて、「ルールとルールグループを追加」からAWSマネージドルールを選びます。AWSマネージドルールとは、AWSが作成・保守するルールグループです。個別の攻撃パターンを一から定義しなくても、一般的な脅威への対策を始められます。

たとえば、一般的なWebアプリケーションの脆弱性に対処する場合はコアルールセット、既知の不審なIPアドレスからのアクセスに対処する場合はAmazon IP評価リストが候補です。

ルールの追加前にはWCUも確認します。WCU（Web ACL Capacity Units）とは、ルールやルールグループが使用する処理能力を表す単位です。Web ACLで使用するWCUが1,500を超えると、超過分に応じた追加料金が発生します。不要なルールグループを重ねていないかも確認してください。

関連コラム：AWS WAFの「保護パック」をひもといてみた

2-3. カスタムルールとレートベースルールを追加する

AWSマネージドルールだけでは対応できない自社固有の要件には、カスタムルールを追加します。送信元やリクエスト内容などを条件にして、適用する処理を設定できます。

主なルールアクションは次のとおりです。

アクション	処理内容
Allow	条件に一致したリクエストを許可する
Block	条件に一致したリクエストを遮断する
Count	通信は遮断せず、一致したリクエストを記録する
CAPTCHA	利用者へCAPTCHAパズルを提示する
Challenge	ブラウザーへサイレントチャレンジを実行する

一定時間内に多数のリクエストを送信するアクセスを制限したい場合は、レートベースルールを利用します。レートベースルールでは、一定時間内のリクエスト数を集計し、設定した基準値を超えた送信元などに対して処理を適用できるためです。特定のURLだけを対象にしたい場合は、スコープダウンステートメントで対象範囲を絞り込めます。

許可または遮断するIPアドレスが複数ある場合は、IPセットとしてまとめて管理すると、複数のルールから同じ一覧を参照できます。IPアドレスの追加や削除も一か所で行えるため、効率的に管理することが可能です。

関連コラム：AWS WAFを使用したIPアドレス制限の実装方法について解説

2-4. ルールの優先順位とデフォルトアクションを設定する

AWS WAFでは、優先順位が高いルールから順番にリクエストを評価します。優先順位は数値で設定し、数値が小さいほど優先順位が高くなる仕組みです。たとえば、特定の通信を例外として許可したい場合は、許可するルールを先に評価する必要があります。そのため、許可するルールには、遮断するルールよりも小さい数値を設定します。

また、AllowやBlockなどの終了アクションが適用されると、通常は後続のルールが評価されません。そのため、個々のルールだけでなく、Web ACL全体を通した評価順序を確認する必要があります。

どのルールにも一致しなかったリクエストには、デフォルトアクションが適用されます。必要な通信を原則として許可し、問題のある通信をルールで遮断する場合はAllowが基本です。一方、事前に許可した通信だけを通す構成ではBlockを選びましょう。

最後に設定内容と、AWSリソースの状態を監視するAmazon CloudWatchで使用するメトリクス名を確認します。問題がなければ、Web ACLの作成を完了します。

ここまで紹介したように、AWS WAFでは保護対象に応じてルールを選択し、優先順位やデフォルトアクションなどを適切に設定しなければなりません。自社環境に合ったルール設計や設定に加え、設定後の監視や継続的な見直しまで対応することが難しい場合は、外部の運用支援を活用する方法もあります。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」は、AWS WAFと脅威検出サービスであるAmazon GuardDutyの運用を支援するサービスです。AWSマネージドルールとNTT東日本のSOC独自のカスタムルールを組み合わせ、お客さまの環境に応じたチューニングに対応します。

また、アラート分析や許可リスト・ブロックリストの設定、日次点検など、設定後の運用も支援します。AWS WAFのルール設定や設定後の監視・運用に課題を感じている方は、以下の資料から詳しい支援内容をご確認ください。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」の資料はこちら

3. AWS WAFのルールをテストする方法

新しいルールを本番環境ですぐにBlockへ切り替えると、正規のリクエストまで遮断する可能性があります。まずはCountモードで一致したリクエストを記録し、誤検知の有無を確認してからBlockへ切り替えましょう。

3-1. Countモードで一致するリクエストを確認する

Countは、条件に一致したリクエストを記録しながら、通信自体は遮断しないアクションです。カスタムルールをCountに設定すれば、利用者への影響を抑えながら、実際の通信で検出状況を確認できます。

AWSマネージドルールを試す場合は、ルールグループ内のルールアクションをCountで上書きします。テストをする際は、通常時だけでなく、キャンペーンや定期処理などでアクセスが増える時間帯の通信も確認するとよいでしょう。さまざまな通信を確認することで、通常時には現れない誤検知を見つけやすくなります。

3-2. サンプルリクエストとメトリクスを確認する

AWS WAFのダッシュボードやサンプルリクエストでは、どのルールに一致したか、リクエストのどの部分が検出されたかを把握できます。実際の業務で使うURLやパラメータが繰り返し検出されていないかを調べましょう。

AWS WAFのメトリクスを確認すると、許可、遮断、カウントされたリクエスト数の推移を把握できます。特定のルールだけ一致数が急増している場合は、攻撃だけでなく、Webサイトの更新やアクセス傾向の変化も考慮して原因を確認してください。

3-3. 誤検知を調整してBlockへ切り替える

正規のリクエストが検出される場合は、業務への影響と情報セキュリティ上のリスクを確認したうえでルールを調整します。主な調整方法は、以下のとおりです。

正常な通信へ先にAllowを適用する例外ルールを設ける
スコープダウンステートメントで検査対象を絞る
マネージドルール内の特定ルールだけアクションを上書きする

調整後は再びCountで動作を確認します。正規のリクエストが意図せず検出されていないことや、Blockへ切り替えても業務に影響しないことを確認したうえで、対象ルールを段階的にBlockへ切り替えましょう。一度にすべて変更せず、ルール単位で結果を追うと問題の原因を特定しやすくなります。

4. AWS WAFのログを設定・確認する方法

Web ACLのログを有効にすると、検査したリクエストの詳細を確認できます。ログは、ルールの調整や誤検知の確認に加え、不正アクセスが疑われる場合の調査にも役立ちます。

4-1. ログの出力先を準備する

AWS WAFのログは、Amazon CloudWatch Logs、Amazon S3、Amazon Data Firehoseへ出力できます。それぞれの特徴を踏まえ、利用目的に合う出力先を選びましょう。

横にスクロールします

出力先	特徴	適した用途の例
Amazon CloudWatch Logs	ログの検索やメトリクスとの照合を行いやすい	検出状況の監視やアラーム設定
Amazon S3	大量のログを長期間保存できる	監査、長期保存、ほかの分析サービスとの連携
Amazon Data Firehose	ストリーミングデータを指定先へ配信できる	ログを継続的に転送する仕組みとの連携

保存期間や検索・分析の方法、発生する料金を比較し、ロググループやS3バケット、配信ストリームなどを事前に作成します。

4-2. Web ACLのログを有効化する

AWS WAFのコンソールで対象のWeb ACLを選び、ログ設定を開きます。準備した出力先を指定し、ログ記録を有効にしましょう。

リクエストヘッダーなどに機密情報が含まれる可能性がある場合は、該当するフィールドをマスキングします。また、ログフィルターを使うと、特定のアクションや条件に一致するログだけを残せます。保存する情報を減らせる一方、条件を絞りすぎると調査に必要な記録が不足する可能性があるため、利用目的に合わせて設定してください。

4-3. ログから検出内容と誤検知を確認する

ログでは、主に次の項目を確認します。

確認項目	確認する内容
アクション	Allow、Block、Countなど、リクエストに適用された処理
終了ルール	最終的なアクションを決定したルール
送信元IPアドレス	リクエストの送信元
URI・HTTPメソッド	アクセス先とGET・POSTなどのリクエスト方法
一致した条件	ルールが検出したリクエストの特徴

Blockの件数が急増した場合は、攻撃の発生だけでなく、ルールの変更やWebアプリケーションの更新による誤検知も考えられます。変更履歴や通常のアクセス傾向と照らし合わせ、必要に応じてルールや例外設定を見直しましょう。

ログやアラートから検出内容を確認し、対応の要否を判断するには、継続的な監視と分析が必要です。NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」では、AWS WAFやAmazon GuardDutyから発生するアラートを分析し、日次点検や必要に応じた遮断などに対応します。

ログやアラートの確認を含むAWS WAFの監視体制を見直したい方は、以下の資料からサービスの対応範囲をご確認ください。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」の資料はこちら

5. AWS WAFの料金と見積もり方法

AWS WAFでは、Web ACL、ルール、処理したリクエスト数などに応じて料金が発生します。オプション機能やログの出力先にも料金がかかる場合があるため、基本料金だけでなく構成全体で見積もりましょう。

5-1. AWS WAFの基本的な料金項目

東京リージョンでリージョナルリソースを保護する場合、AWS WAFの主な料金項目は以下のとおりです。

料金項目	基本料金
Web ACL	1つにつき月額5USD
ルール	1つにつき月額1USD
リクエスト	100万件につき0.60USD
WCUの超過	1,500WCUを超える場合、追加500WCUごとに100万リクエストあたり0.20USD
本文検査の追加容量	デフォルトの本文検査上限を超える追加16KBごとに、100万リクエストあたり0.30USD

2026年9月時点

通常のAllow、Block、Countには、ルールアクション自体の追加料金はありません。一方、CAPTCHAやChallenge、悪質なボット通信を検知・制御するBot Controlには別料金が発生します。AWS Marketplaceで提供されるマネージドルールにも、別途料金がかかる場合があります。

最新の単価と詳しい条件は、AWS WAFの料金ページからご確認ください。

5-2. AWS Pricing Calculatorを用いた月額料金の見積もり方法

AWS Pricing Calculatorは、AWSサービスの利用条件を入力して料金を試算できる無料のツールです。AWS WAFを追加し、次の項目を入力します。

入力項目	設定内容の例
リージョン	保護対象を配置するリージョン
Web ACL数	作成するWeb ACLの数
ルール・ルールグループ数	Web ACLへ追加する数
月間リクエスト数	AWS WAFが処理する見込みの件数
オプション機能	Bot ControlやCAPTCHAなどの利用量

たとえば、Web ACLを1つ作成し、AWSマネージドルールグループを3つ追加して、月間1,000万件のリクエストを処理する場合は、次のように試算できます。

内訳	計算	月額
Web ACL	1個 × 5USD	5USD
ルールグループ	3個 × 1USD	3USD
リクエスト	1,000万件 × 0.60USD／100万件	6USD
合計		14USD

この例では、有料のマネージドルールやオプション機能を使用せず、WCUの超過や本文検査の追加料金もないものとしています。保護対象となるサービスやログの配信・保存にかかる料金も含みません。実際の請求額を保証するものではないため、AWS Pricing Calculatorで自社の条件を入力してご確認ください。

6. AWS WAFを運用するときのポイント

AWS WAFは、一度設定して終わりではありません。Webアプリケーションの更新やアクセス傾向の変化に合わせて、ルールや設定内容を定期的に見直すことが大切です。変更する場合は、事前に影響を確認してから本番環境へ反映しましょう。

AWSマネージドルールのバージョンを変更する場合も、変更内容を確認して事前にテストします。更新通知を受け取る仕組みを用意し、固定したバージョンの有効期限が切れる前に移行計画を立てることが大切です。

また、継続的に運用するための体制も整えておきましょう。ルールの変更者や承認者、緊急時の対応担当者を決め、変更内容や対応履歴を記録しておくことで、設定変更や問題発生時にも対応しやすくなります。

7. AWS WAFの設定・運用を支援するNTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」

AWS WAFでは、Webアプリケーションやアクセス傾向の変化に応じて、ルールの見直しやアラートの確認などを継続的に行う必要があります。社内だけでこうした運用体制を維持することが難しい場合は、専門事業者による支援を活用することも有効です。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」は、AWS WAFと脅威検出サービスであるAmazon GuardDutyの運用を支援するサービスです。

NTT東日本のSOC（Security Operation Center）では、経験豊富なセキュリティエンジニアが24時間365日体制でAWS環境を監視しています。また、AWSマネージドルールとSOC独自のカスタムルールを組み合わせ、お客さまの環境に応じたチューニングにも対応します。

主な支援内容は以下のとおりです。

AWS WAFとAmazon GuardDutyのアラート分析
許可リスト・ブロックリストの設定
検知内容に関する問い合わせへの説明
日次点検と必要に応じた遮断対応
検知・対応状況をまとめた月次レポートの提供

自社に合ったプランや具体的な支援内容を知りたい方は、以下の資料からサービスの詳細をご確認ください。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」の資料はこちら

8. AWS WAFの設定に関するよくある質問

AWS WAFの設定に関してよくある質問へ回答します。

8-1. AWS WAFの設定はコードで管理できますか？

AWS CloudFormationを利用すると、AWS WAFの設定をコードで管理できます。AWS CloudFormationとは、AWSリソースの構成をテンプレートとして定義し、作成や更新を自動化するサービスです。

テンプレートを利用することで、開発環境と本番環境へ同じ設定を展開しやすくなり、変更内容も確認しやすくなります。保護対象との関連付け方法は、Amazon CloudFrontかリージョナルリソースかによって異なるため、対象サービスの仕様も確認してください。

8-2. AWS WAFのルールはどの順番で評価されますか？

AWS WAFのルールは、優先順位の数値が小さいものから評価されます。AllowやBlockなどの終了アクションが適用されると、通常は後続のルールが評価されません。Countはリクエストを記録したあとも評価を続ける非終了アクションです。

ルールを追加・変更するときは、新しいルールだけを見るのではなく、既存ルールとの順序やアクションの関係を確認しましょう。特に例外として許可するルールと、広い範囲を遮断するルールの順序には注意が必要です。

8-3. AWS WAFの設定・運用は外部に委託できますか？

AWS WAFの設定や運用は、専門事業者へ委託できます。委託先を選ぶ際は、初期設定だけでなく、ルールの調整、監視、通知、検知後の対応など、どこまで支援を受けられるか確認しましょう。自社と委託先の役割分担や、緊急時の連絡方法を事前に決めておくことも大切です。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」では、AWS WAFのルール調整やアラート分析、月次レポートの提供などを通じて運用を支援します。専門人材や監視体制を自社で確保することが難しい場合にも、外部委託によって運用負担を軽減できます。

AWS WAFの設定・運用を外部へ委託する場合の支援範囲を確認したい方は、以下の資料をご覧ください。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」の資料はこちら

9. AWS WAFの設定と運用を継続的に見直そう

AWS WAFでWebアプリケーションを保護するには、Web ACLとルールを作成するだけでなく、実際の通信に合わせて設定を継続的に確認・見直すことが大切です。新しいルールはCountで影響を確認し、誤検知を調整してからBlockへ切り替えます。運用開始後もログやメトリクスを確認し、必要に応じてルールの優先順位や例外設定、レート制限などを調整しましょう。

AWS WAFの設定や継続的な監視・運用に課題を感じている方は、NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」をご検討ください。SOCによるアラート分析やルールの調整を通じて、AWS WAFの運用を支援します。

NTT東日本の「セキュリティオプション（AWS WAF / Amazon GuardDuty）」の資料はこちら