Rate limiting

Rate limiting contains HTTP request floods and usage abuse. It counts requests per client and returns 429 for whatever exceeds the limit — before the request consumes your origin.

Rate limiting

Parameter	Options
Unit	requests per second, per minute or per hour
Counting key	client IP address
Reach	the whole domain, an exact path or a path prefix
Response to excess	429

You set the limit in two places: in the domain policy, for general traffic, and in custom rules with the RATE_LIMIT action, for specific paths. When both apply, the stricter one for that path decides.

The limit exists to contain abuse within platform capacity — a form being swept, an expensive endpoint being hammered, a POST repeated by a single client. It is not a contract quota, nor a consumption meter.

Limits per instance

The limit is applied per edge instance. When a domain's traffic is spread across several instances, the effective total accepted can be higher than the configured value — in proportion to the number of instances serving that domain at that moment.

Say it out loud before calibrating: a configured limit of 100 requests per second may accept more than 100 per second in total. If you need a hard global ceiling for an expensive path, set the limit with headroom for the instance count and keep the real protection in the application, with authentication and a per-consumer quota.

Rate limiting and DDoS

Attack	Who contains it
HTTP request flood (layer 7)	WAF rate limiting
Form sweeping, repeated POST, endpoint abuse	Rate limiting and custom rules
UDP or SYN flood (layer 3 and 4)	Network protection in front of the WAF
Link saturation, volumetric attack	Network protection in front of the WAF

WAF rate limiting does not protect against volumetric layer 3 or 4 attacks. Volume attacks must be absorbed in the network. Treat the two as distinct layers: the WAF handles request content, the network handles volume.

Difference from API Gateway quotas

	WAF rate limiting	API Gateway quota
What it counts	Requests per client IP	Consumption per consumer and per API key
What it is for	Containing abuse and floods	Commercial contract, fair use, billing
Who configures it	Whoever manages the WAF	Whoever manages the API product
A blocked request consumes quota	No	—

They are different products: the WAF consumes no API Gateway quota, and a request blocked by the WAF consumes no API quota. To limit a consumer identified by key, use the Gateway quota; to contain a flood by IP, use WAF rate limiting.

Calibrating

1. Measure normal traffic per path, in requests per second, per minute and per hour.
2. Start with a generous limit and an observation action in the rules, to see who would be affected.
3. Tighten gradually, following the 429 events.
4. Remember the number of edge instances when setting the final value.
5. Warn integrators before tightening a limit that affects a public API.

429 is an expected response, not an incident

A spike of 429 on an expensive path is usually the limit doing its job. Treat it as a problem only when 429 hits a legitimate client at normal volume — in that case the limit is too low, or the counting key does not fit your case.

Next steps

• Custom rules — per-path limit with the RATE_LIMIT action.
• Events and exceptions — reading 429 events.
• Troubleshooting — when 429 hits a legitimate client.