AWS WAFのメトリクスについて

AWS WAFのメトリクスとは、AWS WAFが処理したWebリクエストの状況をCloudWatch上で数値として確認できる指標です。

主に、以下のような内容を把握できます。

• どれくらいのリクエストが許可されたか
• どれくらいのリクエストがブロックされたか
• テスト中のルールにどれくらい一致したか
• CAPTCHAやChallengeがどれくらい発生したか
• どのルールで検知・ブロックされたか
• 国別、ルール別、リソース別にどのような傾向があるか

AWS WAFのメトリクスは、CloudWatchの AWS/WAFV2 名前空間で確認できます。

Web ACLやルールごとの状況を把握できるため、WAFの効果確認、攻撃検知、誤検知の調査、ルール調整、アラート設計などに活用されます。

ただし、CloudWatchメトリクスだけでは、IPアドレス、URI、User-Agent、リクエストヘッダーなどの詳細までは確認できません。

詳細調査を行う場合は、AWS WAFログやSampled requestsと併用する必要があります。

AWS WAFメトリクスで確認できること

AWS WAFのメトリクスでは、WAFがどのようにリクエストを処理したかを確認できます。

たとえば、正常な通信がどれくらい許可されているか、攻撃やBotと思われる通信がどれくらいブロックされているか、テスト中のルールがどれくらい反応しているかを数値で把握できます。

主な確認項目

確認したい内容	主に使うメトリクス
許可されたリクエスト数	AllowedRequests
ブロックされたリクエスト数	BlockedRequests
Countモードに一致したリクエスト数	CountedRequests
CAPTCHAが適用されたリクエスト数	CaptchaRequests
Challengeが適用されたリクエスト数	ChallengeRequests
CAPTCHAを解けた数	CaptchasSolved
Challengeに成功した数	ChallengesSolved
有効なCAPTCHAトークン付きリクエスト数	RequestsWithValidCaptchaToken
有効なChallengeトークン付きリクエスト数	RequestsWithValidChallengeToken

AWS WAFのメトリクスは、日常的な監視だけでなく、ルール追加時の影響確認にも役立ちます。

特に本番環境で新しいルールを導入する場合、最初からBlockにするのではなく、Countモードで様子を見ることで誤検知のリスクを抑えられます。

AWS WAFの主要メトリクス

AWS WAFでは、複数のメトリクスを使ってリクエストの処理状況を確認します。

ここでは、実務で特によく使う主要メトリクスを紹介します。

AllowedRequests

AllowedRequests は、AWS WAFによって許可されたWebリクエスト数を示すメトリクスです。

Web ACLのルール評価を通過し、最終的に許可されたリクエストがカウントされます。

サイト全体の正常トラフィック量を把握したい場合に使います。

たとえば、以下のような場面で確認します。

利用シーン	確認できること
通常時のアクセス監視	平常時のトラフィック量
広告配信後のアクセス確認	流入増加の有無
キャンペーン時の監視	想定どおりアクセスが増えているか
障害調査	急激にアクセスが減っていないか

AllowedRequests が増えている場合でも、それだけで正常アクセスと断定できるわけではありません。

Botやクローラー、スクレイピングアクセスが許可されている可能性もあるため、BlockedRequests やWAFログとあわせて確認することが重要です。

BlockedRequests

BlockedRequests は、AWS WAFによってブロックされたWebリクエスト数を示すメトリクスです。

AWS WAFの運用で最も重要なメトリクスのひとつです。

攻撃、Bot、不審なスキャン、レート制限、マネージドルールへの一致などによってブロックされたリクエストを確認できます。

BlockedRequestsで分かること

状況	考えられる原因
急激に増加している	攻撃、Bot、スキャン、スクレイピング
特定ルールだけ増えている	SQLインジェクション、XSS、Rate-based ruleなど
特定国から増えている	海外Bot、地域限定の攻撃
リリース直後に増えた	正常リクエストの誤検知
ずっと0のまま	攻撃がない、またはルールが機能していない可能性

BlockedRequests が増加した場合、単純に「攻撃を防げている」と判断するのは危険です。

正常ユーザーのリクエストが誤ってブロックされている可能性もあります。

特に、問い合わせフォーム、購入フォーム、ログイン画面、会員登録画面、広告LPなどでブロックが増えている場合は、コンバージョンへの影響を確認する必要があります。

CountedRequests

CountedRequests は、Countアクションに一致したWebリクエスト数を示すメトリクスです。

Countアクションは、リクエストをブロックせずに「ルールに一致した」という事実だけを記録するための設定です。

そのため、新しいルールを本番環境に導入する前の検証によく使われます。

CountedRequestsの主な用途

用途	内容
新規ルールのテスト	どれくらいのリクエストが一致するか確認
マネージドルールの影響確認	正常リクエストが誤検知されないか確認
Block前の事前検証	いきなりブロックせず安全に調査
ルール調整	除外条件やスコープダウン条件の検討

実務では、以下のような流れで使うのがおすすめです。

1. 新しいルールをCountモードで追加する
2. CountedRequests を数日間確認する
3. WAFログで一致したURIやUser-Agentを確認する
4. 誤検知があれば除外条件を追加する
5. 問題がなければBlockへ変更する

ただし、CountedRequests はルールグループの種類や所有者によって、CloudWatch上で見えるディメンションが異なる場合があります。

AWS Managed RulesやMarketplaceルールグループなどでは、Web ACL単位ではなく、Rule、RuleGroup、Region などのディメンションで確認が必要になるケースがあります。

CaptchaRequests

CaptchaRequests は、CAPTCHA制御が適用されたWebリクエスト数を示すメトリクスです。

AWS WAFのCAPTCHAは、Botによる自動アクセスを抑制し、人間によるアクセスかどうかを確認するために使われます。

ログイン、問い合わせフォーム、会員登録、コメント投稿、検索フォームなど、Botによる悪用が起きやすい箇所で利用されることがあります。

注意点として、CaptchaRequests はCAPTCHAが適用されたリクエスト数を示すものであり、有効なCAPTCHAトークンを持って通過したリクエストは含みません。

有効なCAPTCHAトークンを持つリクエストは、RequestsWithValidCaptchaToken として別に集計されます。

CAPTCHA関連メトリクス

メトリクス	意味
CaptchaRequests	CAPTCHA制御が適用されたリクエスト数
CaptchasAttempted	CAPTCHA解答が試行された数
CaptchasSolved	CAPTCHAが正常に解かれた数
RequestsWithValidCaptchaToken	有効なCAPTCHAトークンを持つリクエスト数

CaptchaRequests が多い一方で、CaptchasSolved が少ない場合、Botをうまく排除できている可能性があります。

一方で、正常ユーザーがCAPTCHAで離脱している可能性もあるため、フォーム完了率やコンバージョン率もあわせて確認することが重要です。

ChallengeRequests

ChallengeRequests は、Challenge制御が適用されたWebリクエスト数を示すメトリクスです。

Challengeは、CAPTCHAのようにユーザーへ明示的なパズルを表示するのではなく、主にブラウザ側でサイレントに検証する仕組みです。

ユーザー体験への影響を抑えながら、Botや自動化アクセスを判定したい場合に有効です。

ChallengeRequests も、CAPTCHAと同様に、有効なChallengeトークンを持つリクエストは含みません。

有効なChallengeトークン付きリクエストは、RequestsWithValidChallengeToken として別に集計されます。

Challenge関連メトリクス

メトリクス	意味
ChallengeRequests	Challenge制御が適用されたリクエスト数
ChallengesAttempted	サイレントChallengeへの応答試行数
ChallengesSolved	Challengeに成功した数
RequestsWithValidChallengeToken	有効なChallengeトークンを持つリクエスト数

また、ChallengesAttempted や ChallengesSolved には、Challengeアクションによるものだけでなく、CAPTCHAアクションの一部として実行されたChallengeも含まれます。

PassedRequests

PassedRequests は、ルールグループの評価を通過したリクエスト数を示すメトリクスです。

具体的には、ルールグループ内のどのルールにも一致しなかったリクエストが対象です。

Web ACL全体で許可されたリクエストを示す AllowedRequests とは意味が異なります。

実務では、Web ACL全体の監視よりも、ルールグループ単位の評価状況を確認したい場合に使います。

AWS WAFメトリクスのディメンション

AWS WAFのメトリクスは、ディメンションを使って分類・絞り込みできます。

ディメンションとは、メトリクスを確認するための切り口です。

たとえば、Web ACL単位、ルール単位、国別、リソース別などでメトリクスを確認できます。

主なディメンション

ディメンション	内容
Region	AWSリージョン
WebACL	Web ACLのメトリクス名
WebACLArn	Web ACLのARN
Rule	ルールのメトリクス名
RuleGroup	ルールグループのメトリクス名
ResourceType	保護対象リソースの種類
Resource	保護対象リソースのARN
Country	リクエスト元の国
Attack	攻撃種別
Device	デバイスタイプ
ManagedRuleGroup	AWSマネージドルールグループ
ManagedRuleGroupRule	マネージドルール内の個別ルール
LoadBalancerArn	ロードバランサーARN
VulnerabilityCategory	脆弱性カテゴリ

ディメンションを使うことで、単に「ブロック数が増えた」だけでなく、「どのルールで」「どの国から」「どのリソースに対して」増えているのかを確認できます。

ディメンションの活用例

確認したいこと	使うディメンション
Web ACL全体のブロック数	WebACL
どのルールがブロックしているか	Rule
どのマネージドルールに一致しているか	ManagedRuleGroup, ManagedRuleGroupRule
国別のブロック状況	Country
ALBやCloudFrontなどリソース別の状況	ResourceType, Resource
攻撃種別ごとの傾向	Attack
デバイス別の傾向	Device

たとえば、BlockedRequests を Rule ディメンションで確認すれば、どのルールによってブロックが発生しているかが分かります。

また、Country ディメンションで確認すれば、特定国からのアクセスに偏っているかどうかを把握できます。

Labelメトリクス

AWS WAFでは、リクエスト評価中にラベルが付与されることがあります。

Labelメトリクスは、そのラベルが付与されたリクエストに対して、どのようなアクションが適用されたかを確認するためのメトリクスです。

たとえば、AWS Managed RulesやBot Controlでは、リクエストの特徴に応じてラベルが付与されます。

このラベルを確認することで、単なるブロック数だけでは分からない検知理由や攻撃傾向を把握しやすくなります。

Labelメトリクスの主な種類

メトリクス	内容
AllowedRequests	ラベル付きリクエストが許可された数
BlockedRequests	ラベル付きリクエストがブロックされた数
CountedRequests	Countアクションのルールにより追加されたラベル数
CaptchaRequests	CAPTCHAが適用されたラベル付きリクエスト数
ChallengeRequests	Challengeが適用されたラベル付きリクエスト数
AllowRuleMatch	Allowで評価終了したラベル付きルール一致数
BlockRuleMatch	Blockで評価終了したラベル付きルール一致数
CountRuleMatch	Countされたラベル付きルール一致数

なお、1つのWebリクエストに対して、メトリクスに反映されるラベル数には上限があります。

大量のラベルが付与されるケースでは、すべてがメトリクス上で確認できるとは限りません。

また、Labelメトリクスの CountedRequests は、ルールグループの所有者かどうかによって見え方が変わる場合があります。

ルールグループ所有者でない場合、CountラベルメトリクスがAllowやBlockなどの終端アクション側に集約されることがあります。

Free bot visibility metrics

AWS WAFには、Bot Controlを使用していない場合でもBotトラフィックの傾向を把握できるFree bot visibility metricsがあります。

これは、AWS WAFがWebリクエストのサンプルにBot Control managed rule groupを適用し、Botらしいアクセスの傾向を可視化するためのメトリクスです。

Bot Controlを本格導入する前に、現在のサイトにどの程度Botトラフィックが来ているかを確認する材料になります。

Free bot visibility metricsの主なメトリクス

メトリクス	内容
SampleAllowedRequest	サンプル上で許可されたリクエスト数
SampleBlockedRequest	サンプル上でブロックされたリクエスト数
SampleCaptchaRequest	サンプル上でCAPTCHA対象になったリクエスト数
SampleChallengeRequest	サンプル上でChallenge対象になったリクエスト数
SampleCountRequest	サンプル上でCount対象になったリクエスト数

Free bot visibility metricsの主なディメンション

ディメンション	内容
BotCategory	Botのカテゴリ
VerificationStatus	Botの検証状態
Signal	Bot判定に関連するシグナル

これらを確認することで、検索エンジンBot、悪質Bot、自動化アクセスなどの傾向を把握しやすくなります。

ただし、あくまでサンプリングベースの情報であり、すべてのBotアクセスを完全に集計するものではありません。

Account metrics

Account metricsは、アカウント全体のCAPTCHAやChallengeに関するメトリクスです。

特に、AWS WAFのJavaScript APIを通じて提供されたCAPTCHAやChallengeの試行・成功状況を確認するために使います。

Account metricsの主なメトリクス

メトリクス	内容
CaptchasAttemptedSdk	JavaScript API経由のCAPTCHA解答試行数
CaptchasSolvedSdk	JavaScript API経由のCAPTCHA成功数
ChallengesAttemptedSdk	JavaScript API経由のChallenge試行数
ChallengesSolvedSdk	JavaScript API経由のChallenge成功数

ChallengesAttemptedSdk や ChallengesSolvedSdk には、Challengeアクションによるものだけでなく、CAPTCHAアクションの一部として実行されるChallengeも含まれます。

Usage metrics

AWS WAFには、通信処理に関するメトリクスとは別に、利用しているWAFリソース数を確認するUsage metricsがあります。

Usage metricsは、CloudWatchの AWS/Usage 名前空間で確認できます。

主に、Web ACL、ルールグループ、IP set、Regex pattern setなどのリソース数を監視するために使います。

ResourceCount

ResourceCount は、アカウント内で使用しているAWS WAF関連リソース数を示すメトリクスです。

サービスクォータに近づいていないかを確認する用途で使われます。

アラームを作成する場合は、基本的に Maximum 統計を使うのが適しています。

Usage metricsで確認できる主なリソース

Resource値	内容
WebAclsPerAccountCloudFront	CloudFront用Web ACL数
WebAclsPerAccountRegional	リージョン内Web ACL数
RuleGroupsPerAccountCloudFront	CloudFront用ルールグループ数
RuleGroupsPerAccountRegional	リージョン内ルールグループ数
IpSetsPerAccountCloudFront	CloudFront用IP set数
IpSetsPerAccountRegional	リージョン内IP set数
RegexPatternSetsPerAccountCloudFront	CloudFront用Regex pattern set数
RegexPatternSetsPerAccountRegional	リージョン内Regex pattern set数

Usage metricsは、攻撃検知というよりも、AWS WAFのリソース管理やクォータ監視に使うメトリクスです。

CloudWatchでAWS WAFメトリクスを確認する方法

AWS WAFのメトリクスは、CloudWatchコンソールから確認できます。

確認手順

1. AWSマネジメントコンソールでCloudWatchを開く
2. 「メトリクス」または「すべてのメトリクス」を開く
3. 名前空間 AWS/WAFV2 を選択する
4. Web ACL、Rule、Region、Countryなどのディメンションを選択する
5. AllowedRequests、BlockedRequests、CountedRequests などをグラフで確認する

CloudWatch上では、名前空間として AWS/WAFV2 を使います。

ただし、コンソールの表示やドキュメント上では AWS::WAFV2 と表記される場合もあります。

CLIで確認する方法

AWS CLIでは、以下のコマンドでAWS WAFのメトリクス一覧を確認できます。

aws cloudwatch list-metrics --namespace "AWS/WAFV2"

特定のメトリクスが見つからない場合は、リージョン、Web ACLのメトリクス名、ルールのメトリクス名、ディメンションの組み合わせを確認してください。

CloudFrontでAWS WAFを使う場合の注意点

CloudFrontに関連付けたAWS WAFのメトリクスは、CloudWatchのリージョンを us-east-1、つまり米国東部バージニア北部に切り替えて確認する必要があります。

これは、CloudFrontがグローバルサービスとして扱われるためです。

CloudFront利用時の確認ポイント

項目	内容
CloudWatch確認リージョン	us-east-1
WAFスコープ	CLOUDFRONT
CLI / APIのリージョン	us-east-1
よくあるミス	東京リージョンなどで探して見つからない

ALB、API Gateway、AppSync、Cognitoなどのリージョナルリソースに紐づけている場合は、そのリソースが存在するリージョンでメトリクスを確認します。

AWS WAFメトリクスとWAFログの違い

AWS WAFを運用する際は、CloudWatchメトリクスとWAFログを使い分けることが重要です。

メトリクスは、リクエスト数やブロック数などの傾向を把握するのに向いています。

一方、WAFログは、実際にどのリクエストがどのルールに一致したのかを詳しく調査するのに向いています。

メトリクスとログの違い

項目	CloudWatchメトリクス	AWS WAFログ
主な用途	監視、アラート、傾向把握	詳細調査、原因分析
分かること	件数、ルール別、国別など	IP、URI、ヘッダー、User-Agent、ルール一致内容
粒度	集計値	リクエスト単位
アラート	向いている	Logs Insightsやメトリクスフィルターと併用
保存先	CloudWatch Metrics	CloudWatch Logs、S3、Data Firehose
長期分析	やや不向き	S3 + Athenaなどで分析しやすい

使い分けの考え方

状況	使うもの
ブロック数が増えたか知りたい	CloudWatchメトリクス
どのルールが反応したか知りたい	CloudWatchメトリクス + ディメンション
どのURLがブロックされたか知りたい	WAFログ
どのIPから攻撃されているか知りたい	WAFログ
User-Agentやヘッダーを見たい	WAFログ
一部サンプルだけ確認したい	Sampled requests
長期的に攻撃傾向を分析したい	S3保存 + Athena

基本的には、CloudWatchメトリクスで異常を検知し、WAFログで詳細を調査する流れがよいです。

Sampled requestsとの違い

AWS WAFには、Sampled requestsという機能もあります。

Sampled requestsは、WAFが評価したリクエストの一部をサンプルとして確認できる機能です。

CloudWatchメトリクスのような集計値ではなく、実際のリクエスト内容を一部確認できます。

Sampled requestsの特徴

項目	内容
確認できる内容	サンプルされたリクエスト情報
最大件数	最大500件
対象期間	過去3時間以内
サンプル対象	指定時間範囲内の最初の5,000件からランダム抽出
用途	簡易的な原因調査

Sampled requestsは便利ですが、すべてのリクエストを確認できるわけではありません。

特にアクセスが急増している場合、指定した時間範囲全体から均等に抽出されるわけではなく、その時間範囲内の最初の5,000件からサンプリングされます。

そのため、本格的な調査や証跡保存が必要な場合は、WAFログを有効化する必要があります。

AWS WAFメトリクスのよくある監視パターン

AWS WAFのメトリクスは、単に数値を見るだけでなく、目的に応じて監視パターンを決めることが重要です。

攻撃やBotの急増を検知する

攻撃やBot流入を検知したい場合は、BlockedRequests、ChallengeRequests、CaptchaRequests などを監視します。

メトリクス	見るポイント
BlockedRequests	ブロック数が急増していないか
ChallengeRequests	Bot判定が急増していないか
CaptchaRequests	フォームやログインへのBot流入が増えていないか
CountedRequests	テスト中ルールへの一致が急増していないか

たとえば、BlockedRequests の5分合計が通常時の数倍になっている場合、攻撃やBotアクセスが発生している可能性があります。

ただし、広告配信やキャンペーンによる正規アクセスの増加に伴って、WAFの反応数も増えることがあります。

メトリクスだけで判断せず、WAFログやアプリケーション側の指標とあわせて確認することが大切です。

誤検知を見つける

WAF運用で特に注意すべきなのが誤検知です。

誤検知とは、本来許可すべき正常なリクエストをWAFが攻撃と判断してブロックしてしまうことです。

誤検知が発生すると、問い合わせ、購入、会員登録、ログインなどに影響が出る可能性があります。

誤検知調査で見るべき項目

確認項目	内容
BlockedRequests by Rule	どのルールがブロックしているか
BlockedRequests by Country	特定国のユーザーだけ影響していないか
WAFログのURI	正常なページやAPIが止まっていないか
WAFログのUser-Agent	特定ブラウザや端末だけ影響していないか
アプリ側の4xx	ブロックや拒否が増えていないか
コンバージョン率	ビジネス成果に影響していないか

リリース直後やWAFルール追加直後に BlockedRequests が増えた場合は、誤検知を疑うべきです。

特に、広告LP、問い合わせフォーム、購入フォーム、会員登録フォーム、ログイン画面は重点的に確認するとよいでしょう。

新規ルールを安全に導入する

AWS WAFで新しいルールを追加する場合は、いきなりBlockにするのではなく、まずCountモードで導入するのがおすすめです。

新規ルール導入の流れ

1. 新しいルールをCountモードで追加する
2. CountedRequests を確認する
3. WAFログで一致したリクエストを確認する
4. 正常リクエストが含まれていないか確認する
5. 必要に応じて除外条件を追加する
6. 問題がなければBlockに変更する
7. 変更後も BlockedRequests とCVRを監視する

この手順を踏むことで、正常ユーザーを誤ってブロックするリスクを下げられます。

Rate-based ruleの効果を確認する

Rate-based ruleを使っている場合は、一定時間内に大量アクセスしているIPやBotを制限できます。

Rate-based ruleの効果を見るには、該当ルールの BlockedRequests を確認します。

Rate-based ruleで見るべき項目

確認項目	内容
BlockedRequests by Rate-based rule	レート制限で止めたリクエスト数
WAFログのIP	どのIPが大量アクセスしているか
WAFログのURI	どのURLが狙われているか
WAFログのUser-Agent	Botやツールの傾向
CloudFront / ALBのリクエスト数	WAF前後の負荷変化

ログイン画面、検索API、在庫確認API、問い合わせフォーム、WordPressのログインページなどでは、Rate-based ruleが特に有効です。

AWS WAFメトリクスのアラーム設計

AWS WAFのメトリクスは、CloudWatch Alarmと組み合わせることで、異常検知や通知に活用できます。

最低限設定したいアラーム

アラーム対象	目的
BlockedRequests の急増	攻撃、Bot、誤検知の検知
AllowedRequests の急減	サイト障害や過剰ブロックの検知
CountedRequests の急増	テスト中ルールの影響確認
CaptchaRequests の急増	Bot流入やフォーム攻撃の検知
ChallengeRequests の急増	自動化アクセスの増加検知

アラーム設定の考え方

サイト規模	条件例
小規模サイト	BlockedRequests の5分合計が100を超えたら通知
中規模サイト	BlockedRequests の5分合計が1,000を超えたら通知
大規模サイト	通常時の2〜3倍を超えたら通知
ECサイト	決済・ログイン・カート周辺のブロック増加を重点監視
BtoBサイト	問い合わせ・資料請求フォームのブロック増加を重点監視

固定しきい値だけでは、アクセス数の多い時間帯やキャンペーン時に誤通知が増える可能性があります。

できれば、平常時のトラフィック量を把握したうえで、時間帯や曜日を考慮したアラーム設計を行うとよいでしょう。

AWS WAFメトリクスが表示されないときの確認ポイント

CloudWatchでAWS WAFのメトリクスが表示されない場合は、いくつかの原因が考えられます。

主な確認ポイント

確認項目	内容
Web ACLがリソースに関連付けられているか	関連付けていないと実トラフィックが流れない
CloudWatchMetricsEnabled が有効か	VisibilityConfigを確認する
対象リージョンが正しいか	CloudFrontは us-east-1
メトリクス名が正しいか	Web ACL名ではなくメトリクス名を見る
非ゼロ値があるか	一致リクエストがないと表示されない場合がある
ルールに実際に一致しているか	ルール条件に合っていない可能性がある
ディメンションが正しいか	Web ACL、Rule、RuleGroupなどを確認する

特に多いのは、CloudFront用のWeb ACLを使っているのに、東京リージョンなど別リージョンでCloudWatchメトリクスを探しているケースです。

CloudFrontの場合は、CloudWatchを us-east-1 に切り替えて確認してください。

また、Firewall ManagerでデプロイされたWeb ACLや、AWS Managed Rules、Marketplaceルールグループなどでは、メトリクスの見え方が通常と異なる場合があります。

特にCountアクションのメトリクスは、Web ACL単位ではなくRuleGroup単位で確認が必要になることがあります。

AWS WAFメトリクスを見るときの実務上の注意点

AWS WAFのメトリクスは便利ですが、数値だけで判断すると誤った結論になることがあります。

BlockedRequestsの増加だけで攻撃と判断しない

BlockedRequests が増えている場合、攻撃やBotをブロックできている可能性があります。

しかし、正常ユーザーを誤ってブロックしている可能性もあります。

特に、以下のタイミングでは注意が必要です。

• サイトリニューアル直後
• フォーム仕様変更後
• 新しいWAFルール追加後
• AWS Managed Rules更新後
• 広告キャンペーン開始後
• 海外向け配信開始後

ブロック数が増えた場合は、必ずWAFログでURI、ルールID、IP、User-Agent、ラベルを確認しましょう。

CountedRequestsは検証用として活用する

新しいルールを追加する場合は、まずCountモードで動かすのが安全です。

CountedRequests を確認すれば、正常ユーザーに影響を与えずに、どれくらいのリクエストがルールに一致するかを確認できます。

ただし、AWS Managed Rulesや他アカウント所有のルールグループでは、CloudWatch上で期待した場所にCountメトリクスが出ないことがあります。

その場合は、Rule、RuleGroup、Region などのディメンションを確認してください。

CAPTCHAとChallengeはユーザー体験も確認する

CAPTCHAやChallengeはBot対策に有効ですが、ユーザー体験に影響を与える可能性があります。

特にCAPTCHAは、ユーザーに明示的な操作を求めるため、フォーム完了率や購入率に影響することがあります。

以下の指標をあわせて確認するとよいでしょう。

確認指標	理由
CaptchaRequests	CAPTCHA要求数
CaptchasSolved	CAPTCHA成功数
フォーム完了率	正常ユーザーが離脱していないか
CVR	マーケティング成果への影響
直帰率	CAPTCHA表示による離脱増加
問い合わせ数	フォーム送信障害の有無

WAFのセキュリティ強化とユーザー体験は、バランスを取りながら調整する必要があります。

AWS WAFメトリクスのおすすめダッシュボード構成

AWS WAFを継続的に運用するなら、CloudWatchダッシュボードを作成しておくと便利です。

ダッシュボードに入れたい項目

パネル	表示する内容
全体トラフィック	AllowedRequests, BlockedRequests, CountedRequests
ルール別ブロック	BlockedRequests by Rule
国別ブロック	BlockedRequests by Country
CAPTCHA状況	CaptchaRequests, CaptchasAttempted, CaptchasSolved
Challenge状況	ChallengeRequests, ChallengesAttempted, ChallengesSolved
テストルール	CountedRequests by Rule
Bot傾向	Free bot visibility metrics
リソース別状況	ResourceType, Resource
WAFリソース数	AWS/Usage の ResourceCount

あわせて見るとよい関連指標

関連指標	理由
CloudFront Requests	アクセス母数の確認
CloudFront 4xx / 5xx	WAF以外のエラー確認
ALB 4xx / 5xx	アプリケーション側の異常確認
オリジン負荷	WAFで負荷軽減できているか確認
GA4セッション数	正常流入との比較
CVR	誤検知による成果影響の確認
フォーム完了率	問い合わせ・登録への影響確認

特にWebマーケティングやECサイトでは、WAFメトリクスだけでなく、CVRやフォーム完了率などのビジネス指標も一緒に見ることが重要です。

AWS WAFメトリクスのまとめ

AWS WAFのメトリクスは、WAFがWebリクエストをどのように処理しているかを確認するための重要な指標です。

基本的には、以下のメトリクスから確認するとよいでしょう。

優先的に見るべきメトリクス

優先度	メトリクス	用途
高	BlockedRequests	攻撃、Bot、誤検知の検知
高	AllowedRequests	正常トラフィック量の把握
高	CountedRequests	新規ルールの検証
中	CaptchaRequests	CAPTCHA適用状況の確認
中	ChallengeRequests	Challenge適用状況の確認
中	CaptchasSolved	CAPTCHA成功状況の確認
中	ChallengesSolved	Challenge成功状況の確認
中	Label metrics	マネージドルールやBot判定の深掘り
低〜中	ResourceCount	WAFリソース数・クォータ監視

AWS WAFの運用では、CloudWatchメトリクスだけで完結させるのではなく、WAFログやSampled requestsと組み合わせることが大切です。

基本的な流れは、以下のようになります。

1. CloudWatchメトリクスで異常を検知する
2. ディメンションでルールや国、リソースを絞り込む
3. WAFログで実際のリクエスト内容を確認する
4. 誤検知があれば除外条件を追加する
5. 新規ルールはCountモードで検証してからBlockにする
6. セキュリティ指標だけでなく、CVRやフォーム完了率も確認する

AWS WAFメトリクスを正しく活用すれば、攻撃やBotへの対策を強化しながら、正常ユーザーへの影響を最小限に抑えた運用がしやすくなります。

以上、AWSWAFのメトリクスについてでした。

最後までお読みいただき、ありがとうございました。