Rate limiting and traffic control

Goal

Apply rate limits that stop abusive clients without hurting real users, and understand how limits interact with WAF actions.

The building blocks

• Rate limit — N requests per window (for example 100 requests / minute) per key.
• Key — what identifies a client: IP address, API key, user ID, or a header value.
• Burst — short spikes above the rate that are tolerated before limiting kicks in.
• Action on exceed — reject with 429, challenge, or throttle.

Choosing keys

Key by client IP for anonymous traffic, and by API key or user for authenticated APIs — otherwise one NAT'd office building can consume another tenant's budget, or a single attacker with many IPs slips under per-IP limits.

Steps

1. Open Traffic in the console and create a limit: key, rate, window, burst, action.
2. Scope it to the routes that need protection (login endpoints and search are the usual first targets).
3. Publish and watch the counters.

Verify

• Hammering the protected endpoint from one client returns 429 after the limit.
• The traffic dashboard shows limited requests counted separately from blocked ones.

Pitfalls

• Limits that are too tight on login endpoints lock out shared-office users; start generous, tighten with data.
• Rate limiting is not a substitute for WAF rules — a slow attacker stays under any limit.