How to monitor AWS WAF blocked requests and rule metrics?

If you are running AWS WAF in front of your applications, you already have a powerful security layer blocking SQL injections, XSS attacks, and bot traffic. But AWS WAF monitoring is what turns that protection from a passive shield into an active intelligence system.

This guide walks you through every layer of AWS WAF monitoring: the CloudWatch metrics that matter, how to enable Web ACL logging, how to set threshold alerts, and what tools like Datadog, New Relic, or CubeAPM add on top of native AWS capabilities.

What Is AWS WAF Monitoring and Why Does It Matter?

AWS WAF is a managed web application firewall that evaluates every HTTP/S request arriving at your Amazon CloudFront distributions, Application Load Balancers, Amazon API Gateways, AWS AppSync APIs, and AWS Cognito user pools. It processes traffic against ordered sets of rules inside a Web Access Control List (Web ACL), taking actions such as Allow, Block, Count, CAPTCHA, or Challenge on each request.

Without monitoring, WAF operates like a security camera with no recording. You are blocking threats but accumulating no evidence and receiving no warnings. AWS WAF monitoring gives you three critical capabilities:

• Visibility: See which rules are firing, how often, and against what traffic sources.
• Tuning: Use Count mode metrics to validate new rules without disrupting legitimate traffic.
• Alerting: Trigger automated responses when blocked request counts spike beyond a threshold, which often signals an active attack.

According to AWS, the traffic overview dashboard introduced in March 2024 was designed specifically because “protecting application uptime can be a time-consuming challenge of baselining network traffic, investigating suspicious senders, and determining how best to mitigate risks.” 

How AWS WAF Generates Metrics in CloudWatch

Every Web ACL you create publishes metrics to Amazon CloudWatch automatically. No additional configuration is needed to start seeing data in CloudWatch. Metrics arrive under the namespace AWS/WAFV2 and can be filtered by three dimensions:

• Region: The AWS region where the Web ACL is deployed.
• WebACL: The name of your Web ACL.
• Rule: The name of the individual rule or rule group within the Web ACL.

This three-level hierarchy is important. You can view aggregate metrics for the entire Web ACL, or drill down to a specific managed rule group like AWSManagedRulesCommonRuleSet to see exactly how many requests it is blocking.

Core AWS WAF Metrics You Need to Track

The following table summarizes the primary metrics available in CloudWatch for AWS WAF. All metrics use the Sum statistic and report in 1-minute periods by default.

The Rule Dimension: Where the Real Insight Lives

The most actionable use of AWS WAF metrics is filtering by the Rule dimension. When you navigate to CloudWatch Metrics and select AWS/WAFV2, you can chart BlockedRequests for a specific rule name over time. This tells you:

• Which managed rule group is contributing the most blocks (helping isolate rules that may be too aggressive).
• When a specific rule started firing at an unusual rate, correlating with attack start times.
• Whether a rate-based rule is triggering expected protections during traffic spikes.

Per AWS security best practices documentation: “Determine which rule is contributing the most blocked requests over the past few days. This can help you isolate a rule that is not working as intended.” (Source:

Using the AWS WAF Traffic Overview Dashboard

As of March 2024, AWS WAF includes a built-in traffic overview dashboard inside the WAF console for each Web ACL. This dashboard is available by default and requires no additional setup, no CloudFormation, and no extra cost beyond the WAF service itself.

What the Traffic Overview Dashboard Shows

The dashboard provides near real-time summaries of CloudWatch metrics. Key panels include:

• Total requests vs. blocked requests over the selected time window.
• Allowed vs. blocked ratio with trend lines.
• Bot vs. non-bot traffic breakdown, with bot category classification from the Bot Control managed rule group.
• CAPTCHA solve rate, showing what percentage of challenged users completed the CAPTCHA.
• Top 10 matched rules, ranked by request volume.
• Top originating countries for both total and blocked traffic.
• Client device type breakdown (desktop vs. mobile vs. tablet).

You can access default metrics such as total requests, blocked requests, and common attacks blocked, or customize the dashboard with metrics and visualizations that are most important to you. The dashboard has native integration with CloudWatch, so you can navigate directly from a dashboard panel into CloudWatch for more granular metric exploration.

Sampled Requests Tab

The traffic overview dashboard also includes a Sampled Requests tab. This tab shows a graph of rule matches for web requests AWS WAF has inspected, plus a table of up to 100 sample requests that matched a rule and 100 requests that received the default Web ACL action. Samples come from the previous three hours of traffic on protected resources. This is useful for quickly inspecting the headers, URI, and country of blocked requests without running a full Athena query.

How to Enable AWS WAF Web ACL Logging

CloudWatch metrics give you counts and rates. Web ACL logs give you the full story: the source IP, the URI path, the rule that matched, the HTTP headers, the action taken, and whether a token was present. Logging is not enabled by default and must be configured explicitly for each Web ACL.

Step 1: Choose a Log Destination

AWS WAF supports three logging destinations. Choose the one that matches your operational workflow:

Step 2: Enable Logging for a Web ACL

To enable logging via the AWS Management Console:

1. Navigate to the AWS WAF console and select your Web ACL.
2. Choose the Logging and metrics tab.
3. Under Logging, click Enable.
4. Select your logging destination type (CloudWatch Logs, S3, or Kinesis Data Firehose).
5. Select or create the target resource (a log group, S3 bucket, or Firehose delivery stream). For CloudWatch Logs, the log group name must start with the prefix aws-waf-logs-.
6. Optionally configure log filtering to reduce costs by logging only BLOCK actions or specific rule matches.
7. Save the configuration. Logging begins within a few minutes.

Step 3: Query Logs with CloudWatch Logs Insights

Once logs are flowing to CloudWatch Logs, you can run ad-hoc queries using Logs Insights. A useful starting query to find all blocked requests in the last 24 hours:

fields @timestamp, httpRequest.clientIp, terminatingRuleId, action

| filter action = 'BLOCK'

| stats count(*) as blockCount by terminatingRuleId

| sort blockCount desc

fields @timestamp, httpRequest.clientIp, terminatingRuleId, action

| filter action = 'BLOCK'

| stats count(*) as blockCount by terminatingRuleId

| sort blockCount desc

This query surfaces your top-blocking rules ranked by count, which is the first thing to check when investigating an unexpected spike in blocked traffic.

For top blocked source IPs:

fields @timestamp, httpRequest.clientIp, action

| filter action = 'BLOCK'

| stats count(*) as requests by httpRequest.clientIp

| sort requests desc | limit 20

fields @timestamp, httpRequest.clientIp, action

| filter action = 'BLOCK'

| stats count(*) as requests by httpRequest.clientIp

| sort requests desc | limit 20

You can also use Contributor Insights rules to create ongoing visualizations of top IPs and top terminating rules without writing manual queries each time.

How to Set Alerts on AWS WAF Blocked Requests

Monitoring dashboards are reactive. Alerts are proactive. AWS WAF integrates with CloudWatch Alarms to notify you when blocked request counts cross a threshold, which is typically the first signal that an active attack or a misconfigured rule is causing problems.

Create a CloudWatch Alarm for Blocked Requests

To set an alert when BlockedRequests for a Web ACL exceed a threshold:

8. In the CloudWatch console, navigate to Alarms and click Create alarm.
9. Select the metric AWS/WAFV2 > WebACL, Region, Rule > BlockedRequests.
10. Set the statistic to Sum and the period to 1 minute (or 5 minutes for less sensitivity).
11. Define the threshold. For example: BlockedRequests > 1000 for 2 consecutive data points (2 minutes).
12. Set the alarm action to notify an SNS topic, which can send email, SMS, or trigger a Lambda function.
13. Name the alarm and click Create.

To set alerts on a per-rule basis (for example, only alert when AWSManagedRulesKnownBadInputsRuleSet crosses 500 blocks), repeat the same steps but filter the metric by the Rule dimension set to the specific rule group name.

Anomaly Detection Alarms

In addition to static threshold alarms, CloudWatch supports anomaly detection alarms that use machine learning to model the normal behavior of a metric. You can apply an anomaly detection band to BlockedRequests so that CloudWatch alerts you only when the value deviates significantly from the expected pattern for that time of day and day of week. This reduces false alarms from expected traffic surges (like a product launch) while still catching genuine attack spikes.

Advanced AWS WAF Log Analysis with Athena and QuickSight

For teams with high-volume traffic or long-term compliance requirements, querying logs stored in S3 with Amazon Athena provides the most flexible analysis layer.

Setting Up Athena for WAF Logs

When WAF logs land in an S3 bucket, you can create an Athena table that maps directly to the WAF log schema. AWS provides a sample DDL statement in the WAF documentation. Once the table is created, you can run standard SQL:

SELECT terminatingruleid, COUNT(*) AS block_count

FROM waf_logs

WHERE action = 'BLOCK'

  AND from_unixtime(timestamp/1000) > NOW() - INTERVAL '7' DAY

GROUP BY terminatingruleid ORDER BY block_count DESC;

SELECT terminatingruleid, COUNT(*) AS block_count

FROM waf_logs

WHERE action = 'BLOCK'

  AND from_unixtime(timestamp/1000) > NOW() - INTERVAL '7' DAY

GROUP BY terminatingruleid ORDER BY block_count DESC;

You can chain Athena queries with Amazon QuickSight to build managed BI dashboards showing blocked request trends by rule, geo, and URI path. The AWS Security Services Best Practices guide covers this pattern in detail.

AWS WAF Monitoring with Third-Party Tools

Native CloudWatch monitoring is powerful but requires setup time and AWS console access for every investigation. Third-party observability platforms integrate WAF metrics alongside application performance data, providing unified dashboards and more sophisticated alerting.

CubeAPM

CubeAPM is an APM and observability platform that integrates AWS WAF monitoring alongside application performance data, giving security and engineering teams a unified view without switching between the WAF console and CloudWatch.

CubeAPM collects WAF metrics via the CloudWatch API and presents them on pre-built dashboards that cover blocked requests, allowed traffic, bot activity, and rule-level breakdowns. Because it correlates WAF data with traces, error rates, and latency from the same applications protected by WAF, it surfaces the operational impact of both attacks and rule misconfigurations in a single screen.

Datadog

Datadog collects AWS WAF metrics via the AWS integration, which polls CloudWatch on a configurable interval. The Datadog AWS WAF integration surfaces AllowedRequests, BlockedRequests, CountedRequests, and CAPTCHA metrics, all enriched with the Web ACL and Rule dimensions as tags. This means you can build dashboards that correlate WAF block spikes with application error rates or latency increases in the same view.

Key metrics Datadog collects from WAF include aws.waf.allowed_requests, aws.waf.blocked_requests, aws.waf.counted_requests, aws.waf.requests_with_valid_token, and aws.waf.captcha_requests.

New Relic

New Relic’s AWS WAF monitoring integration polls CloudWatch metrics and stores them in NRDB, where you can query them with NRQL. New Relic also supports alert conditions on WAF metrics with anomaly-based baselines.

Site24x7

Site24x7 provides an AWS WAF monitoring integration that pulls CloudWatch data and visualizes it alongside uptime and response time metrics for the protected resources. This is useful for teams that want a single monitoring console rather than switching between WAF console and CloudWatch.

Applications Manager (ManageEngine)

ManageEngine Applications Manager supports AWS WAF monitoring, collecting metrics like AllowedRequests, BlockedRequests, and PassedRequests. It provides threshold-based alerts and historical trend views from within the same console used for infrastructure and application monitoring.

How to Tune AWS WAF Rules Using Monitoring Data

Monitoring is only valuable when it drives action. The most common use of WAF metrics and logs in day-to-day operations is rule tuning: deciding whether a rule is too aggressive (causing false positives) or too permissive (missing attacks).

The Count-Before-Block Workflow

Before switching any new rule to Block mode, run it in Count mode first. This means the rule will match requests and increment CountedRequests without terminating the request. The workflow is:

14. Add the new rule or managed rule group to the Web ACL in Count mode.
15. Wait at least 24 to 72 hours to collect representative traffic data.
16. In CloudWatch, chart CountedRequests filtered by the new rule’s name.
17. Use Logs Insights to sample the actual requests being counted: are they legitimate users or attackers?
18. If the false-positive rate is acceptable, promote the rule to Block mode.
19. Watch BlockedRequests for the same rule over the next 24 hours to confirm there is no legitimate traffic impact.

Identifying Overly Aggressive Rules

If you see a sudden jump in BlockedRequests after deploying a new managed rule group, use the following approach to identify the specific rule causing the issue:

• Filter CloudWatch metrics by the Rule dimension set to the specific managed rule group name.
• If the platform supports sub-rule labels (via WAF log labels field), query Logs Insights for the most frequent labels in blocked requests.
• Review sampled blocked requests in the WAF console Sampled Requests tab to check if legitimate user agents or IPs are included.
• Consider adding IP set overrides or scope-down statements to the rule group to exclude known-good traffic from matching.

AWS WAF Monitoring Best Practices

Drawing from AWS documentation, Datadog, and security engineering guidance, here are the practices that define a mature AWS WAF monitoring posture:

Disclaimer: This article contains pricing estimates based on publicly available AWS CloudWatch Logs rates as of May 2026. Actual costs may vary by AWS region, account type, and usage patterns. Always verify current pricing before making infrastructure decisions.

FAQs