Why isn't my AWS WAF custom aggregation key rate-based rule blocking or enforcing the rate limit?

Short description

The following issues can cause the AWS WAF rate-based rule with custom aggregation keys not to block traffic or enforce the expected rate limit:

• You set the rule action to Count instead of Block.
• The scope-down statement doesn't match your traffic.
• The aggregation key options are unique for each request, so no aggregation instance reaches the limit.
• Requests are missing a key component, so AWS WAF removes them from evaluation.
• The source IP address doesn't match your architecture.
• The limit applies for each aggregation instance, not across the entire rule.
• A higher-priority rule terminates the request before the rate-based rule evaluates.

Resolution

Change the rule action to Block

When you set the action of a rate-based rule to Count, the rule doesn't block or terminate requests. The Count action only watches and labels traffic.

To enforce rate limiting, complete the following steps:

1. Open the AWS WAF console.
2. In the navigation pane, choose Web ACLs.
3. Select your web ACL, and then choose the Rules tab.
4. Select the rate-based rule, and then choose Edit.
5. For Action, choose Block.
6. Choose Save rule.

Change the scope-down statement so that it matches your traffic

For rules that have a scope-down statement, AWS WAF counts and rate-limits only requests that match the scope-down statement and ignores all other requests. If the scope-down statement doesn't match your test traffic, then the rule doesn't aggregate or block requests.

The scope-down statement doesn't match your traffic when the URI path, text transformation, or positional constraint in the statement doesn't match the values in the requests that you want to rate-limit.

To resolve this issue, modify the scope-down statement so that it matches the requests that you're rate limiting.

Check your aggregation key options

AWS WAF maintains a separate counter for every unique combination of aggregation key options. If you aggregate on an option that's unique to each request, then each request contributes to its own aggregation instance. Because each instance gets only one request, no instance reaches the limit and the rule doesn't block traffic.

To resolve this issue, aggregate on a key that produces repeated values across the traffic that you want to throttle. For example, aggregate on HTTP method, a custom header that contains a customer ID, a cookie that contains a session ID, or a TLS fingerprint.

Add the required key components in the request

If a request doesn't contain every component that you named in the aggregation key, then AWS WAF removes the request from the rate-based rule. AWS WAF then doesn't count or rate-limit the request.

For example, if you configure the rule to aggregate on the X-Tenant-ID header, then AWS WAF ignores requests that don't include that header. The rule doesn't throttle the requester that omits the header.

To resolve this issue, verify that your application sends the required header, cookie, or query parameter in every request. If you can't control the request content, then change the aggregation key in your rate-based rule to use a component that exists in all requests.

If the configured header is missing for forwarded IP address keys, then AWS WAF doesn't apply the rule. The header is typically X-Forwarded-For. The FallbackBehavior setting of MATCH or NO_MATCH takes effect only when the header exists but contains an incorrect IP address value. For more information about how AWS WAF handles missing or malformed forwarded IP address headers, see Using forwarded IP addresses in AWS WAF.

Use a forwarded IP address for your architecture

If clients reach your application through a content delivery network or proxy, then the connection source IP address is the proxy address, not the client address. A rule that aggregates on the source IP address groups all clients behind a proxy into the same aggregation instance. As a result, excessive requests from one client count toward the same aggregation instance as all other clients behind that proxy. This can block legitimate users, or the combined request count might not reach the rate limit for any single client.

To resolve this issue, use FORWARDED_IP or ForwardedIP inside CUSTOM_KEYS behind a trusted proxy, and specify the header that your CDN sets. The header is typically X-Forwarded-For. Don't use FORWARDED_IP when there's no proxy in front of your application because the header is absent and AWS WAF exempts the requests from the rule. For more information, see Using forwarded IP addresses in AWS WAF.

For TLS fingerprint keys, such as JA3Fingerprint and JA4Fingerprint, the fingerprint requires a TLS/HTTPS connection. When AWS WAF can't compute the fingerprint, it applies FallbackBehavior. With MATCH, AWS WAF counts requests without a fingerprint as one aggregation value. With NO_MATCH, AWS WAF excludes the requests from the rule.

Size the limit for each aggregation instance volume

The rate limit applies for each aggregation instance, not across the entire rule. For example, you aggregate on each client and set the limit to 10,000. If one client sends no more than a few hundred requests for each evaluation window, then no aggregation instance crosses the threshold.

To resolve this issue, lower the rate limit to match the volume that you expect from each aggregation instance.

To change the rate limit, complete the following steps:

1. Open the AWS WAF console.
2. In the navigation pane, choose Web ACLs.
3. Select your web ACL, and then choose the Rules tab.
4. Select the rate-based rule, and then choose Edit.
5. For Rule, select Rate-based rule.
6. For Rate limit, enter a value between 10–2,000,000,000.
7. For Evaluation window, choose 60, 120, 300, or 600 seconds.
8. Choose Save rule.

Note: Rate limits are approximate. AWS WAF reevaluates request rates about every 10 seconds. A rule or configuration change can take approximately 30 seconds to take effect.

Set the rule priority correctly

AWS WAF evaluates rules in priority order and stops at the first terminating match. If a terminating rule or a higher-priority Allow rule matches the request first, then the rate-based rule doesn't evaluate the request.

Set the priority so that the rate-based rule evaluates before another rule terminates the same traffic.

Related information

Using rate-based rule statements in AWS WAF

Rate-based rule caveats in AWS WAF

Logging AWS WAF protection pack (web ACL) traffic