AWS WAF rate-based rules protect applications from clients or request patterns that produce unusually high traffic. They are useful for abusive scraping, brute-force behavior, bursty bots, and availability protection at the web layer. They are not designed to enforce an exact per-second or per-minute product quota.
Inside AWS Architecture and Operations, rate-based rules are a protective control in front of the application. Their job is to reduce harmful request pressure before the workload absorbs it, while application-level quotas and authorization still handle exact business limits.
AWS explicitly describes WAF rate limiting as approximate. That design choice should shape how teams configure, test, and explain the rule.
The evaluation window controls how far WAF looks back
A rate-based rule has an evaluation window of 1, 2, 5, or 10 minutes, with five minutes as the default. The rate limit is the maximum number of matching requests AWS WAF tracks for each aggregation instance over that window.
The window does not determine how often AWS checks the rate. AWS evaluates the rate frequently, roughly every ten seconds, using recent traffic in the selected window.
Shorter windows react more strongly to bursts, while longer windows smooth traffic over more time. The correct value depends on what harmful behavior the rule is meant to detect.
Rate limiting is intentionally approximate
AWS WAF estimates current request rate using an algorithm that gives more weight to recent traffic. AWS states that the rule applies rate limiting near the configured limit but does not guarantee an exact threshold match.
Detection and release can also lag by several seconds, and AWS notes that changes usually take less than roughly 30 seconds to be reflected. This is acceptable for application protection, but it makes WAF unsuitable as a precise billing or entitlement counter.
If the product promises exactly 100 API calls per minute, enforce that with an API quota or application control rather than relying only on WAF.
Aggregation keys define which callers share a counter
A rate-based rule can aggregate by source IP, forwarded IP, a constant scope, or custom keys. Custom keys can combine up to five request components, allowing patterns such as tenant + URI, header + IP, or another request-specific grouping.
If a request is missing any component required by the selected custom aggregation keys, AWS WAF omits that request from the rate-based evaluation. This makes custom-key design a security decision: an attacker should not be able to evade counting simply by omitting an optional field the rule expects.
The counter should represent the actor or traffic class the organization actually wants to limit.
Forwarded IP requires trusted proxy behavior
When WAF aggregates on a forwarded IP header, it reads the first IP address in the configured header. If the specified header is missing, the rule does not apply to that request.
This is safe only when the header is set or sanitized by a trusted upstream proxy or CDN. If an untrusted client can control the header directly, the client can rotate arbitrary values and defeat the intended rate grouping.
The network path should make it clear which service owns the source-IP truth before a forwarded-IP rule is deployed.
Scope-down statements keep the counter focused on the risky traffic
A scope-down statement narrows which requests are counted and rate-limited. For example, a rule can count only login requests, only one API path, or only requests with a suspicious property instead of counting the entire site.
This helps protect one expensive or sensitive operation without punishing normal traffic elsewhere. It also makes lower rate limits practical because the counter is not diluted by unrelated requests.
Scope-down logic should be tested with representative requests so valid users are not accidentally grouped into an abusive traffic class.
Changing the rule resets the rate counters
AWS documents that changes to the evaluation window, rate limit, aggregation settings, forwarded-IP configuration, or scope reset the rule’s current rate counts. Rate limiting can pause for up to about a minute while the new configuration takes effect.
This creates a deployment consideration during an attack. A well-intended live change can temporarily remove the rule’s accumulated state.
Changes should be deliberate and, where possible, rehearsed outside an active incident.
Each aggregation instance is tracked independently
If the rule aggregates by IP, every IP address has its own rate counter. If it aggregates by a custom key such as tenant + path, every unique combination has its own counter.
This is why a single rate limit can behave very differently depending on aggregation strategy. One global constant counter can protect total traffic to a path, while per-IP counters are better for abusive clients but may not stop a distributed botnet whose traffic is spread across many IPs.
Layering rules can be appropriate when the workload needs both per-client and global protection.
WAF rate rules should sit beside application and infrastructure limits
WAF is one pressure-control layer. API Gateway throttles, load-balancer capacity, Lambda concurrency, database connections, and application quotas still exist behind it. The architecture should make sure those layers fail predictably together.
Later in this cluster, Lambda Concurrency Controls covers one downstream limit. The goal is to stop abusive traffic early without creating a false sense that the rest of the stack no longer needs capacity controls.
Protective limits should be based on the weakest important downstream dependency, not on the theoretical maximum of the edge service.
Measure blocked traffic and successful business traffic together
A rate rule can lower origin load while also blocking legitimate users. Operations should monitor rule matches, sampled requests, origin errors, authentication outcomes, and business success metrics together.
If a legitimate shared proxy or NAT causes many users to share one IP, a simple IP-based rule may be too coarse. If a custom key lowers false positives, verify that the key cannot be spoofed.
AWS WAF rate-based rules are strongest when they are treated as adaptive protection around known application behavior, not as a universal exact quota system.
Distributed attacks require a different mental model from one noisy client. Per-IP aggregation can stop a single source quickly but may have little effect on a botnet whose requests are spread across thousands of addresses. A second rule using a constant key plus a scope-down statement can cap total traffic to an expensive route, while another rule handles per-client abuse. Layering rules lets the application protect both individual and aggregate pressure points.
Custom aggregation keys can also align the rule with authenticated application context. For example, a tenant identifier or API key in a trusted header can produce a fairer limit than IP address when many users share a corporate NAT. That header must be inserted or verified by trusted infrastructure; otherwise an attacker can rotate arbitrary values and defeat the counter.
Count mode is useful during rollout. Before blocking traffic, the team can deploy the rule in count mode, inspect sampled requests and CloudWatch metrics, and estimate how many legitimate clients would have crossed the threshold. This is especially important for high-traffic APIs where one shared integration can look abusive even though the requests are expected.
Rate rules should be reviewed after application changes. A new mobile release, polling interval, retry policy, or batch job can legitimately increase request volume and push clients into a limit that was safe for the previous behavior. The WAF threshold should remain connected to current workload characteristics rather than becoming a forgotten constant.
Blocking action is not the only response. WAF can also count, challenge, CAPTCHA, or apply labels depending on the rule configuration and wider web ACL design. The chosen action should match the threat and user experience. An automated bot may be appropriate for blocking, while suspicious human traffic may be better handled with challenge-based controls.
Observability should keep the rule explainable. Track which aggregation keys are being rate-limited, which paths are affected, and whether backend latency or error rate improves when the rule activates. That evidence shows whether the control is protecting the application or merely moving the problem to another layer.
Rule priority matters when rate-based rules sit beside managed rule groups, allow lists, and application-specific exceptions. A request accepted or blocked by an earlier terminating rule may never reach the rate rule that operators expected to count it. Web ACL review should therefore consider the complete evaluation order, not only the rate statement in isolation.
Scope-down statements can also include labels produced by earlier rules. This lets the organization rate-limit a classified traffic category without duplicating the classification logic. The pattern can be powerful for bots or suspicious clients, but label ownership and rule order should be documented so later web ACL changes do not silently alter which traffic is counted.
Capacity planning should use rate-rule metrics as one input rather than a substitute for load testing. If legitimate peak traffic routinely approaches the WAF threshold, either the limit is too low or the application needs another control that distinguishes abusive traffic more accurately. The protective rule should not become the normal traffic shaper for expected business demand.
