Working with rate limiting policies

The Fastly rate limiting web interface is designed to help you control the rate of requests sent to your origin servers. The feature allows you to count client requests and optionally penalize clients for exceeding rate limits you set.

When you create a rate limiting policy, you define the criteria to track requests counts and their rates over time. Accumulated counts are converted to an estimated rate computed over the time window you specify: either 1s, 10s or 60s. Rates are always measured in requests per second (RPS). If the rate limit is exceeded, Fastly logs the event and can also block additional requests for a time period you specify.

You can also access rate limiting functionality in VCL.

Prerequisites

To use this feature you must purchase a Premier Platform subscription for either Signal Sciences Cloud WAF or Signal Sciences Next-Gen WAF and have a paid account with a contract for full-site delivery.

About the rate limiting dashboard

To access the Rate Limiting dashboard, log in to the Fastly web interface and click the Secure link. The Rate Limiting dashboard displays a summary of all rate limiting policies currently in effect across your services. Each summary includes the following details:

the Rate Limiting dashboard on the Secure page

  • Service: the name of the service
  • Policy name: the name of the rate limiting policy
  • Requests per second: the maximum number of requests per second within the detection window counted before enacting the rate limiting policy
  • Detection window: the duration of the rate limiting window
  • Action: the action taken once the rate limit is exceeded, either Block or Log only

Creating a rate limiting policy

Create a rate limiting policy by following these steps:

  1. Log in to the Fastly web interface and click the Secure link. The Rate Limiting dashboard appears.
  2. Click Add Rate Limiting to a service. The Rate limiting page appears.

    the Rate limiting page

  3. In the Policy name field, enter a human-readable name for your policy. This name is displayed on the rate limiting dashboard.
  4. From the Service menu, select the service and version you want to apply the policy to. Use the search box to search by ID or name.
  5. In the Detect section, fill out the fields to define the detection criteria for the rate limiting policy:
    • In the Destination to protect field, select whether to protect all traffic to origin or specific requests via an edge dictionary. If the service you selected doesn't have an edge dictionary, this option is disabled.
    • In the HTTP methods field, select the check box next to the types of request to detect.
    • In the Requests per second field, enter the maximum number of requests per second to count within the detection window before enacting the rate limiting policy. The lowest rate limit supported by this feature to demonstrate effective behavior is 100 RPS. Using a limit below 100 RPS may result in unpredictable accuracy and detection time.
    • In the Detection window field, select the duration of the rate limiting window. The window size helps determine the effective time to detection (TTD) for excessive traffic to your origin. You can use a shorter window to improve the detection time for attacks at some expense of accuracy. For more information, see Limitations and caveats.
    • From the Client keys menu, select either IP, User-Agent, or IP and User-Agent.
  6. In the Respond section, select how Fastly should respond to your rate limiting policy being exceeded, then fill out the additional fields that appear.
    • Block with custom response: block requests once the rate limit is exceeded and display a custom response in the browser. See Block with custom response.
    • Block with response object: block requests once the rate limit is exceeded and display a response object in the browser. Note that you must have a response object created to use this option. See Block with response object.
    • Log only: log when the rate limit is exceeded but still allow requests. See Log only.
  7. Click Save policy.

Using edge dictionaries for more specific protection

Edge Rate Limiting allows you to specify paths to protect using edge dictionaries. You must specify a path to protect as a key in the key-value pair within a dictionary. For example, to protect a specific API, such as /checkout, you would create a key-value pair where the key is /checkout and the value is Checkout.

Note the following:

  • Keys must be specified using relative paths and without using a trailing /.
  • Query strings are excluded.
  • Keys using regex are not supported.

Block with custom response

Select the Block with custom response option to block requests once the rate limit is exceeded and display a custom response. If you select this option, the following fields become available:

Block with custom response fields

  • In the Status field, enter an HTTP status code to display in the browser.
  • In the MIME type field, enter a media type identifier. Any MIME type can be specified as long as it's compatible with the text entered in the Response field.
  • In the Response field, enter the custom response that appears in the browser when the rate limit is exceeded.
  • In the Response duration field, enter how long, in minutes, to display the custom response before the rate limiter resets and unblocks requests.

Block with response object

Select the Block with response object option to block requests once the rate limit is exceeded and display a response object. Note that you must have a response object created to use this option. If you select this option, the following fields become available:

Block with response object fields

  • From the Response object menu, select the response object that will appear in the browser when the rate limit is exceeded.
  • In the Response duration field, enter the number of minutes you want the custom response to appear before the rate limiter resets and unblocks requests.

Log only

Select the Log only option to log when the rate limit is exceeded but still allow requests. By default, the following fields are logged: timestamp, policy_name, url, limit, window, entry, and rate.

If you select this option, the Logging provider menu becomes available. Select the logging endpoint where you want to send logs. Once you click Save policy, an abbreviated form appears to create a logging endpoint for the provider you specified. Complete the fields and then click Save.

Log only fields

Log formats

The following JSON log formats are used when you choose the Log only option. These schemas can be useful to understand how data is written to different logging providers.

Unless otherwise specified, the default format is used to log information about particular policies that exceed the rate limit.

Default

{
  "timestamp": “%{strftime({"%Y-%m-%dT%H:%M:%S"}, time.start)}V”,
  "policy_name": "%{json.escape(“<rate limiter name>”)}V”,
  "url": “%{json.escape(req.url)}V”,
  "limit": <limit>,
  "window": <window>,
  "entry": "<entry>",
  "rate":  “<rate>"
}

Datadog

{
  "time_start": “%{strftime({"%Y-%m-%dT%H:%M:%S%Z"}, time.start)}V”,
  "ddsource": "fastly",
  "service": “%{req.service_id}V",
  "policy_name": "%{json.escape(“<rate limiter name>”)}V”,
  "url": “%{json.escape(req.url)}V”,
  "limit": <limit>,
  "window": <window>,
  "entry": "<entry>",
  "rate":  “<rate>"
}

Honeycomb

{
  "time": “%{strftime({"%Y-%m-%dT%H:%M:%SZ"}, time.start)}V”,
  "data":{
    "service_id": “%{req.service_id}V",
    "policy_name": "%{json.escape(“<rate limiter name>”)}V”,
    "url": “%{json.escape(req.url)}V”,
    "limit": <limit>,
    "window": <window>,
    "entry": "<entry>",
    "rate":  “<rate>"
  }
}

Limitations and caveats

Rate limits set by a rate limiting policy happen per Fastly POP and counts are not shared across Fastly POP locations.

The Edge Rate Limiting feature is compatible with Fastly’s origin shield feature and both can be used together. If you have shielding enabled, rate limits will be counted twice, once at the edge and once at the origin shield. This has different implications for where protection is occurring and how the client is identified.

The Edge Rate Limiting feature is not intended to compute rates with high precision. The accuracy you can expect depends on the selected time window over which rates are calculated. Estimated percentage error boundaries under nominal conditions are as follows:

  • (+/-) ~50% for the 1 second time window
  • (+/-) ~25% for the 10 second time window
  • (+/-) ~10% for the 60 second time window

For example, if you are using a 10 second time window and a rate limit of 100 RPS, you may see up to 25% more RPS (125 requests per second) to your origin before the attack is detected by rate limiting. Similarly, rate limiting may report that a rate limit has tripped when the actual rate is 75% of the intended rate (75 requests per second).

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 do 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.

Back to Top