A rate-based rule is a Layer 7 (application) defensive control, one of the enforcement mechanisms a thorough DDoS test is built to validate under load. It is the concrete WAF construct that counts requests from an aggregation key, usually a source IP, over a sliding time window and takes an action when that key crosses a threshold. AWS WAF, Cloudflare, Azure Front Door, and Google Cloud Armor all ship a version of it: a counter, a window, a limit, and an action. When a single source exceeds the configured count within the window, the rule blocks, challenges, or counts that source until its rate falls back under the limit.
The mechanism: counter, window, threshold, action
A rate-based rule is more specific than the general idea of rate limiting. Rate limiting is the concept of capping requests per unit time; a rate-based rule is a named object in a WAF console with parameters you set and can get wrong. Three of those parameters decide everything.
The aggregation key decides what gets counted together. Per source IP is the default, but a spoof-resistant deployment can key on a header, a cookie, or a forwarded client address, which changes what an attacker has to rotate to evade it. The window decides the memory of the counter: many implementations evaluate a rolling multi-minute window and re-check it on a shorter cadence, which means there is a lag between a source crossing the line and the action taking hold. The threshold decides where the line sits, and it is the hardest number to get right, because it must sit above legitimate peak behavior and below the rate an attacker needs to cause harm.
The action is the last parameter, and it interacts with a separate toggle worth understanding on its own: whether the rule is in block or count mode. A rate-based rule sitting in count mode produces a tidy dashboard of threshold crossings and blocks nothing.
Why it matters under attack
The value of a rate-based rule is that it caps the load any one source can put on the origin, and its limitation is the mirror image of that value: it caps per source, so an attacker who spreads the same aggregate load across enough sources keeps every individual key under the threshold. This is exactly the shape of a carpet-bombing or distributed L7 flood, where thousands of IPs each send a handful of requests per second, none of them individually loud enough to trip the counter, all of them together saturating the backend.
That is why a rate-based rule is one layer of a stack, not a standalone answer. It handles the concentrated single-source flood cleanly and cheaply, and it buys headroom against a moderately distributed one. Against a widely distributed attack it needs help from signals that do not depend on any single source being loud: IP reputation, a WAF managed rule group, or an interactive challenge that costs the client something to answer.
What a DDoS test measures
The threshold is a claim, and a test's job is to check it in both directions. It measures the false-negative axis by ramping a source toward and across the limit and confirming the action actually fires, in enforce mode, within the window's real lag rather than in theory. It measures the false-positive axis by driving legitimate-looking traffic, a shared NAT egress, a busy API client, a flash crowd, up toward the same line, and confirming real users do not get swept into the block.
Then it measures the evasion axis, which is the one that decides whether the rule matters against a real adversary. A test distributes the same total load across a growing set of sources and finds the point where the per-key counter stops tripping, mapping how much source spread it takes to slide underneath the threshold. The output is the operating envelope of the rule: the rate at which it engages, the collateral cost of engaging there, and the degree of distribution that defeats it. For how these controls differ across major platforms, see the AWS Shield versus Cloudflare comparison.