I checked the results of operating AWS WAF Anti-DDoS managed rules on CloudFront for one year

Introduction

In February 2025, our site received a spike of 50,000 requests per hour from ClaudeBot. Since then, traffic spikes from AI crawlers have continued to occur at a pace of once every one to two months. Looking at the Bot Control CategoryAI standard, spikes exceeding 2σ are recorded about eight times per year. This background is summarized in a previous article.

https://dev.classmethod.jp/articles/aws-waf-bot-control-claudebot-spike/

On June 12, 2025, the AWS WAF Anti-DDoS managed rule (AWSManagedRulesAntiDDoSRuleSet) became generally available (GA). Takakuni's article provides a detailed overview of the feature.

https://dev.classmethod.jp/articles/aws-waf-automatic-application-layer-ddos-protection/

As additional insurance against the regularly occurring spikes, our site adopted this Anti-DDoS managed rule. This article reports the results of practicing the commonly recommended approach of "first observe in count mode" for a full year.

This article examines the following four points.

• DDoS event detection results (did the rule fire over 13 months?)
• The reality of traffic spikes (were spikes actually occurring?)
• Service impact during spikes (did error rates worsen?)
• Operational costs (how much did it cost over 13 months?)

Verification Details

Web ACL Configuration

The Anti-DDoS managed rule was placed at Priority 100, and the entire rule group along with all sub-rules have been operated in Count mode. The Challenge Sensitivity is set to HIGH and SensitivityToBlock is set to LOW. API paths and static assets are excluded via ExemptUriRegularExpressions.

The relevant portion of the configuration is excerpted below (account IDs and resource IDs are masked).

{
    "WebACL": {
        "Name": "my-waf-bot-webacl",
        "ARN": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/my-waf-bot-webacl/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "Rules": [
            {
                "Name": "AWS-AWSManagedRulesAntiDDoSRuleSet",
                "Priority": 100,
                "Statement": {
                    "ManagedRuleGroupStatement": {
                        "VendorName": "AWS",
                        "Name": "AWSManagedRulesAntiDDoSRuleSet",
                        "ManagedRuleGroupConfigs": [
                            {
                                "AWSManagedRulesAntiDDoSRuleSet": {
                                    "ClientSideActionConfig": {
                                        "Challenge": {
                                            "UsageOfAction": "ENABLED",
                                            "Sensitivity": "HIGH",
                                            "ExemptUriRegularExpressions": [
                                                {
                                                    "RegexString": "\\/api\\/|\\.(acc|avi|css|gif|ico|jpe?g|js|json|mp[34]|ogg|otf|pdf|png|tiff?|ttf|webm|webp|woff2?|xml)$"
                                                }
                                            ]
                                        }
                                    },
                                    "SensitivityToBlock": "LOW"
                                }
                            }
                        ],
                        "RuleActionOverrides": [
                            {
                                "Name": "ChallengeAllDuringEvent",
                                "ActionToUse": { "Count": {} }
                            },
                            {
                                "Name": "ChallengeDDoSRequests",
                                "ActionToUse": { "Count": {} }
                            },
                            {
                                "Name": "DDoSRequests",
                                "ActionToUse": { "Count": {} }
                            }
                        ]
                    }
                },
                "OverrideAction": { "Count": {} },
                "VisibilityConfig": {
                    "SampledRequestsEnabled": true,
                    "CloudWatchMetricsEnabled": true,
                    "MetricName": "AWS-AWSManagedRulesAntiDDoSRuleSet"
                }
            }
        ]
    }
}

OverrideAction and the RuleActionOverrides for all three sub-rules (ChallengeAllDuringEvent / ChallengeDDoSRequests / DDoSRequests) are all set to Count, making this an observation-only configuration. The plan was to first confirm activation status in Count mode, then switch to the actual actions once detection was confirmed. Specifically, this would involve changing OverrideAction from Count to None and removing the RuleActionOverrides for each sub-rule. This would enable the default actions of Challenge / Block for each sub-rule.

DDoS Event Detection Results

Since we are operating in Count mode, if the rule fires, data points will remain in CloudWatch metrics. We checked the metrics for the entire operating period from around June 2025 (before and after GA) through July 18, 2026, for both the overall rule and each sub-rule.

The result was zero data points for all sub-rules. Within the CloudWatch metrics we reviewed, no requests matching any of the three Anti-DDoS sub-rules were recorded over 13 months. In particular, since ChallengeAllDuringEvent, which matches challengeable requests during an event, was also zero, no behavior indicating DDoS event detection was observed.

On the other hand, AWSManagedIPDDoSList from the Amazon IP Reputation List, a separate managed rule group, reacts on a daily basis. The trend over the past 8 days is as follows (July 18, 2026 is a partial value as of the data retrieval point).

Looking at the completed days of July 11–17, the IP DDoS List reacts at a pace of about 20 to 170 hits per day, indicating that access from IP addresses AWS has identified as involved in DDoS activity arrives on a regular basis. However, this is an evaluation based on IP reputation and is separate from the "DDoS event detection" performed by the Anti-DDoS managed rule.

For reference, the sub-rule structure of the Anti-DDoS managed rule is as follows. All three sub-rules take effect after a DDoS event is detected, so they will not activate if no event is detected.

Traffic Spike Analysis

Perhaps the Anti-DDoS rule did not fire because no spikes occurred in the first place. Let's verify with daily traffic statistics.

The aggregation period was set to 18 months (January 18, 2025 to July 18, 2026). The starting point is 18 months before the data retrieval date. By including the approximately five months before Anti-DDoS was introduced as a baseline, we can confirm the presence or absence of spikes both before and after the introduction.

Using mean + 2σ (approximately 3.28 million requests/day) as the threshold and extracting days that exceeded it, the following four days were identified. Note that this is a 2σ exceedance based on total traffic, which is a different metric from the "8 times per year" mentioned in the Introduction based on the Bot Control CategoryAI standard.

Let's take a closer look at the largest spike on April 9–10, 2026, at an hourly granularity. Note that daily aggregations are based on UTC, while hourly analysis is expressed in JST. Some of the increase that occurred on April 10 in JST is included in the April 9 entry in the UTC-based daily table.

On April 10, CountedRequests reached 7.3 million, but the Anti-DDoS managed rule showed zero reactions. AllowedRequests was 3.93 million. Since Count is a non-terminating action and the same request can be counted multiple times across multiple rule metrics, the two figures cannot be simply subtracted. However, it is confirmed that a large number of matches were occurring in Count rules such as Bot Control. IP DDoS List hits on this day were also limited to 45. During this spike period, including April 9 (3.8 times the average), the Anti-DDoS managed rule did not fire even once.

Service Impact During Spikes

Here is the TotalErrorRate around the largest spike (April 8–11, 2026).

The CloudFront 5xxErrorRate (the proportion of 5xx responses returned by CloudFront to viewers) during this period was 0.000% for the 48-hour window of April 9–10 (the spike days). No increase in 5xx responses was observed, even on the day traffic reached 3.8 times the average.

Next, here is the data around the December 2025 spike (December 1–5).

The 5xx error rate during this period averaged 0.002556%. Even at its peak, it was 0.1188% at 23:00 on December 4, which was in the late-night hours after the spike had subsided. The spike peak and the 5xx peak did not coincide.

For comparison, let's also look at a normal period without spikes (July 14–17, 2026).

The 5xx error rate during the normal period averaged 0.000019%. While TotalErrorRate was 2.7–3.7%, the extremely low 5xxErrorRate indicates that the majority were 4xx errors.

Comparing the three periods, the TotalErrorRate during spikes (0.5–0.6%) was actually lower than during normal periods (2.7–3.7%). This is likely because during spikes, the proportion of successful responses (2xx/3xx) increased relatively, causing TotalErrorRate to decrease as total request counts rose. At least looking at CloudFront's 5xxErrorRate, no increase in 5xx responses to viewers was observed even during the period when traffic reached 3.8 times the average.

Cost Results

Here is the monthly cost breakdown for the 13-month period. The Anti-DDoS managed rule charges consist of a subscription fee ($20/month, prorated by the hour) combined with request processing fees ($0.15 per 1 million requests). This is an additional charge on top of the basic WAF request fee ($0.60 per 1 million requests). The cumulative total for the 13 billing months from June 2025 through June 2026 was $393.33, with a monthly average of $30.26 (July 2026 is not included as the bill has not been finalized).

In the first month (June 2025), no subscription fee was charged, and only the request fee of $0.85 was recorded. While the subscription fee is officially stated to be prorated by the hour, the reason it was not charged in the first month could not be determined from the billing data. From the following month onward, the $20 subscription fee has been charged every month. Details of the pricing structure are available on the AWS WAF pricing page. For reference, AWS Shield Advanced, which also enhances DDoS protection, costs $3,000/month. However, a direct price comparison is not straightforward since the scope of features differs significantly, including WAF fees and DRT support.

Utilizing the challengeable-request Label

While DDoS event detection was zero, there was a secondary feature that was utilized throughout the operation: the awswaf:managed:aws:anti-ddos:challengeable-request label.

Among the six labels assigned by the Anti-DDoS managed rule, only challengeable-request is assigned at all times, regardless of whether a DDoS event has occurred (for all URIs except those excluded).

On our site, this constantly assigned challengeable-request label was used as a condition in a Rate-based rule. Specifically, it is incorporated into the scope-down statement of the waf-bot-Ratebased-JA4-NonJPUS rule at Priority 203. Even with zero DDoS event detections, there was value in maintaining the Anti-DDoS managed rule solely for the purpose of utilizing this label.

Why Didn't It Fire?

The specific reason it did not fire cannot be determined from publicly available information and the metrics collected this time. The detection condition for the Anti-DDoS managed rule is a "significant deviation" from a traffic baseline. This baseline is automatically constructed by AWS, and there is no way for users to directly adjust the detection threshold.

The peak 1-hour value was 418,867 requests (approximately 116 req/sec on average per hour). What we were able to confirm this time is that this traffic change did not result in any recorded matches to the Anti-DDoS sub-rules. Whether CloudFront was able to handle the traffic and whether the detection conditions for Anti-DDoS were met are separate questions.

Details are available in the official documentation for the Anti-DDoS rule group and the application layer DDoS protection documentation.

Summary

After operating the Anti-DDoS managed rule in Count mode in a CloudFront environment for 13 months, the metrics indicating DDoS event detection were zero. Even including spikes reaching 3.8 times the average, no matches to the Anti-DDoS sub-rules were recorded, and no increase in CloudFront 5xxErrorRate was observed during the spike periods we examined. Within the traffic scale of our site and the 13-month observation window, the operational conclusion is that the spikes we observed were not sufficient to trigger this rule. On the other hand, being able to use the constantly assigned challengeable-request label as a condition in a Rate-based rule was a secondary benefit. Whether approximately $30 per month is worth paying as "peace-of-mind insurance even if it never fires" depends on the scale of the site and its risk tolerance. For smaller sites and other cases where the ratio of the $20/month subscription to the cost of the protected workload is high, it may be worth periodically reviewing the cost-effectiveness. On our site, we have decided to continue operating in Count mode with the goals of detecting DDoS events if they occur and utilizing the challengeable-request label.