Rate Limiting

Rate limiting establishes a traffic budget and defines what happens when that budget is exceeded. A policy might permit each authenticated customer to make 100 requests per second, or restrict repeated requests to a login endpoint from the same source. The essential decisions are what traffic to count, how to group it, which time interval or algorithm to use, and whether excess traffic should be rejected, delayed, or challenged. It is different from a concurrency limit, which restricts the number of operations executing simultaneously rather than the number arriving over time.

Common implementations use fixed windows, sliding windows, or token buckets. Fixed windows are straightforward but can permit concentrated bursts across adjacent window boundaries. Sliding windows account for recent traffic more continuously. A token bucket replenishes permission to send requests at a configured rate while allowing accumulated tokens to support short bursts. These approaches are not interchangeable: a sustained rate of 100 requests per second does not necessarily mean that the 101st request in every calendar second will be rejected.

In cloud architectures, enforcement can occur at a content delivery network, web application firewall, API gateway, reverse proxy, or application. Edge enforcement rejects unwanted traffic before it consumes origin capacity, while application enforcement can use authenticated customer identities and business-specific costs. For example, a search endpoint might need a lower allowance than a cached product page because each search performs expensive database work. Layered limits can combine an overall capacity ceiling with narrower limits for customers or sensitive routes.

The aggregation key determines who shares a limit. Per-IP limits are useful for basic abuse control, but users behind corporate proxies or carrier-grade NAT can share one address and inadvertently share one budget. Conversely, attackers can rotate addresses to evade per-IP enforcement. API keys, authenticated identities, session attributes, or supported combinations of request characteristics can improve grouping. Client-supplied headers are not automatically trustworthy. When using a forwarded client-IP header, ensure that trusted proxies establish its value and that untrusted clients cannot bypass those proxies or forge the identity used for enforcement.

AWS WAF implements this idea through rate-based rules. A rule can aggregate matching requests by IP address or supported custom keys and apply an action when an aggregation instance exceeds its configured threshold over the evaluation window. A scope-down statement can restrict counting to a login path, selected countries, or another request subset. Geographic matching and supported TLS fingerprint matching can refine a policy, but neither proves a client's identity or malicious intent. Geography alone is not rate limiting: a geographic block denies matching traffic regardless of its frequency.

Rate-based security controls should not be treated as exact accounting systems. AWS WAF estimates request rates and can take time to detect a threshold crossing or stop applying an action after traffic subsides. Similarly, gateway throttling can be best effort rather than a strict contractual ceiling. Use transactional application-side accounting when a business requirement demands an exact purchase, spending, or usage limit. Rate limiting also does not replace authentication, authorization, bot defenses, or volumetric DDoS protection.

Roll out policies using observed traffic and nonblocking evaluation where supported. For example, measure legitimate login bursts before enforcing a per-IP threshold, and inspect whether shared networks dominate matches. Review rule priority because an earlier terminating allow rule can prevent a later rate-based rule from evaluating traffic. Monitor matched requests, enforcement actions, origin load, and customer failures. For API rejection, HTTP 429 and appropriate retry guidance help clients respond; exponential backoff with jitter reduces synchronized retries. Finally, prevent direct origin access from bypassing edge controls, and tune limits as application capacity and traffic patterns change.