Working with rate limiting policies

You can use the Fastly edge rate limiting feature to create rate limiting policies. 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.

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 Secure page appears displaying an overview of Fastly's security offerings.
  2. Click Manage rate limiting policies.
  3. Click Add Rate Limiting to a service. The Rate limiting page appears.

    the Rate limiting page

  4. In the Policy name field, enter a human-readable name for your policy. This name is displayed on the rate limiting dashboard.
  5. 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.
  6. 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 a dictionary. If the service you selected doesn't have a 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, review the limitations and caveats.
    • From the Client keys menu, select either IP, User-Agent, or IP and User-Agent.
  7. 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.
  8. Click Save policy.

Using dictionaries for more specific protection

Edge Rate Limiting allows you to specify paths to protect using 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>"
  }
}

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