Rate limiting
Avoid being overwhelmed. Fastly's network can handle hundreds of terabits of traffic per second, so whether it's managing a queue for a product or ticket release, preventing abusive traffic from bots, or billing API customers based on their usage, rate limiting at the edge is a great use of Fastly.
Fastly features
Our dedicated Edge Rate Limiting product provides ratecounter and penaltybox primitives to VCL and Compute services. Real time logging allows data from the edge to be streamed to a destination of your choice, which is often useful for counting specific types of request.
Granular counters are also included with Advanced Rate Limiting rules in our Next-Gen WAF.
HINT: Compute customers can find equivalent functions in Compute SDKs.
Ideas and typical uses
Typically, rate limiting requests at the edge broadly falls into one of three use cases:
- Abuse prevention: stopping abusive bots that may be badly configured, malfunctioning or intentionally attempting to bring down your site in a denial-of-service attack. This is a great use of Edge Rate Limiting.
- Metering: Accurately measuring activity for billing or subscription purposes, with a cutoff when a prescribed volume is reached. Consider using Real time logging in combination with an aggregation or business intelligence tool outside of Fastly to receive and process the data.
- Queueing: Flattening the curve of traffic surges caused by product releases or sudden major publicity. The Compute platform, combined with a state store capable of atomic incrementing counters is a good way to create queueing solutions at the edge, or alternatively consider a stateless waiting room solution if strict queue order is not important.
Solutions
The following demos, tutorials, starter kits, and code examples are relevant to this use case. Try them out!
Tutorials
Step by step instructions. Build and learn.
| Rate limiting | Use ratecounters and penalty boxes to stop high-volume automated attacks against your website. |
| Stateful waiting room | You have regular large volumes of traffic and need to limit the rate at which users can start new sessions. Once a user has been allowed in, they should retain access. |
Starter kits
Template Compute applications you can use to bootstrap your project.
| Queuing / Waiting room (JS) | Park your users in a virtual queue to reduce the demand on your origins during peak times. |
Code examples
Snippets of code ready to copy and paste.
| Bot detection using ratecounter | Rate counters are normally used for detecting high volume DoS-style attacks, but you can also use them to measure lower rates, to ensure that navigation between pages is happening at human speed. |
| Cache '429' rate-limiter responses per IP | If a backend returns a 429, cache it for the requesting IP but continue to allow other clients to use origin. |
| Flatten the curve of major traffic spikes with a waiting room | A totally stateless solution to hold back new users for a minimum waiting period to smooth out spikes in traffic. |
| Rate limit requests | Use ratecounters and penalty boxes to stop high-volume automated attacks against your website. |
| Slowing down responses (tarpit) | Force a response to be delivered very slowly to reduce the rate at which an attacker can send requests. |
| Throttling per country over configurable time periods | Adjust the maximum TCP socket pacing for connections at peak times of day in busy regions. |
