About rate limiting
- English
- 日本語
Rate limiting is a way to control the rate at which traffic flows through Fastly's network to your origins. You might need rate limiting if you need to do things like prevent abusive bots, mitigate DDoS attacks, measure types of activity so you can meter them, and create queueing solutions like waiting rooms to prevent traffic surges.
IMPORTANT: This page discusses basic information about using the main dashboard for our Edge Rate Limiting product. Edge Rate Limiting is designed for use cases where a faster response to large volumes of traffic is required (e.g., mitigating DDoS attacks). For details about Advanced Rate Limiting and its use in the Fastly Next-Gen WAF, refer to the advanced rate limiting rules documentation.
Before you begin
Be sure to review the limitations, considerations, and billing details for the Edge Rate Limiting product.
How Edge Rate Limiting works
When using Edge Rate Limiting, you create rate limiting policies that consist of a rate counter and penalty box. The rate counter keeps track of the number of requests per individual client. When setting up the rate counter, you specify a window size: either 1s, 10s or 60s. The window size helps determine the effective time to detection (TTD). A shorter window results in a quicker detection time for attacks, but can come at the expense of accuracy. A longer window has a slower detection time, but higher accuracy.
Accumulated counts are converted to an estimated rate measured in requests per second (RPS). If a client exceeds the RPS you specify, then the penalty box takes effect, logging the event and blocking future requests.
Limitations and considerations
Keep in mind the following limitations and considerations when working with Edge Rate Limiting:
- Rate counters are not intended to compute rates with high precision and may under-count by up to 10%. For example, if you have a rate limit of 100 requests per second over a 10 second window, when the real request rate reaches 100rps, it may register as low as 90rps, and therefore may not trigger the limit until the real request rate reaches 110rps.
- Both rate counters and penalty boxes have a fixed capacity for client entries. Once a rate counter is full, each new entry evicts the entry that was least recently incremented. Once a penalty box is full, each new entry will evict the entry with the smallest remaining TTL. Penalty box TTLs are enforced "on the minute" rounding up, so the effective minimum TTL of an entry in a penalty box is 2 minutes.
- If you have shielding enabled, rate limits may be counted twice, once at the edge POP and once at the shield POP. Avoid this by only incrementing the rate counter when
fastly.ff.visits_this_serviceis zero, which means the current POP is the end user's first point of contact with your service.- On POPs acting as an edge, the client IP address, representing the source of the traffic, is identified by the
client.ipvariable. A rate limiter deployed here is protecting the shield POP in addition to the origin. - On POPs acting as a shield,
client.ipmay be the edge POP. The actual end user is identified by theFastly-Client-IPrequest header. A rate limiter deployed here is effectively a global counter and is protecting the origin directly.
- On POPs acting as an edge, the client IP address, representing the source of the traffic, is identified by the
- Edge rate limiting can be used with the Fastly Next-Gen WAF by adding headers to requests to pass rate information to Fastly Next-Gen WAF, and processing received headers or HTTP response codes from the Fastly Next-Gen WAF or your origin server to influence rate limiting counts and actions at the edge.
- A POP is made up of one or more sites. When a POP made up of more than one site it's called a Metro POP. Ratecounter data is shared within the hosts that comprise a POP or Metro POP but not between POPs.
- Edge Rate Limiting is currently only supported in VCL, Rust, and Go.
Security products note
No security product, such as a WAF or DDoS mitigation product, including those security services offered by Fastly, will detect or prevent all possible attacks or threats. As a subscriber, you should maintain appropriate security controls on all web applications and origins. The use of Fastly's security products does not relieve you of this obligation. As a subscriber, you should test and validate the effectiveness of Fastly's security services to the extent possible prior to deploying these services in production, continuously monitor their performance, and adjust these services as appropriate to address changes in your web applications, origin services, and configurations of the other aspects of your Fastly services.
What's next
Once you understand how rate limiting works and the considerations and limits of the Edge Rate Limiting product, you can create your first rate limiting policy.