Rate Limiting Frequently Asked Questions

Rate Limiting activation requires the following configuration:

1. Determine whether a rate limiting policy will be applied to aggregate traffic, each unique client, or each unique client's user agentRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link). (e.g., web browser).
2. Define the rate at which requests will be limited.
3. Define the scope of the rate limit by specifying a hostname and/or URL path that must be satisfied before a request qualifies for rate limiting.
4. Define additional conditions, if any, that must be met before a request qualifies for rate limiting.
5. Define the type of action that will be applied to eligible requests when a rate limiting policy is exceeded.

After which, your CDN traffic will be monitored for requests that satisfy the criteria defined in steps 3 and 4. If the number of eligible requests exceeds the rate limit (step 2), then a predefined action (step 5) will be applied randomly to the excess requests.

The How do you want to identify clients? option determines how requests will be counted against a rate limit and therefore should be taken into strong consideration when defining a rate limit.

Example

A rate limit of 20 requests per minute may make sense for unique clients or user agents. However, it is too restrictive when rate limiting all traffic as a single source (i.e., Any Request).

A request counts towards a rate limit when it satisfies a rate limiting rule's:

• Hostname scope.
• URL path scope.

• All of the conditions defined within at least one condition group.

  If a rule does not contain conditions, then only scope criteria determines whether a request qualifies for rate limiting.

All CDN traffic, regardless of delivery platform, is eligible for rate limiting.

A rate limiting policy evaluates traffic from each delivery platformIdentifies the environment through which your content will be efficiently delivered to your users. (i.e., HTTP Large, HTTP Small, or ADN) separately. As a result, requests to each delivery platform are counted separately.

Sample Scenario

This scenario assumes the following rate limiting policy:

• Identify unique clients by IP address.
• A rate limit of 8 requests per second.
• A scope that matches all hostnames and URL paths.
• No condition groups.

It also assumes the following traffic levels for a single client:

• ADN: 5 requests per second
• HTTP Large: 10 requests per second

The above client will be rate limited as follows:

• The client's ADN traffic will not be rate limited.
• The client's HTTP Large traffic will be rate limited to 8 requests per second.

A rate limiting policy defines the type of requests whose flow should be restricted. No further instruction is provided on how rate limiting should be applied to these requests. As a result, Rate Limiting must assume that all identified requests should be treated equally. In order to apply a rate limiting policy equally to all eligible requests, it calculates the percentage of requests that exceed the rate limiting policy and then applies a user-defined action to that percentage of eligible traffic. This policy enforcement action is applied randomly without regard to the order in which requests are received.

For example, if the rate limiting policy is exceeded by 10%, then a rate limiting action will be applied to 10% of eligible requests.

No. It may take up to a couple of minutes before the enforcement of a rate limiting policy takes place.

Rate Limiting will process rules in the order in which they are listed. Once a rule is satisfied, it will be applied to the request and no additional rules will be processed.

It is recommended to order rules according to how they identify requests. Stricter rules that identify requests using multiple conditions should be placed closer to the top of the list, while catch-all rules should be placed closer to the bottom. This ensures that rules are applied to requests as intended.

Yes, Rate Limiting only limits traffic that is routed via our CDN. It is considered a security best practice to obfuscate your web servers to prevent malicious actors from directly attacking your web servers and thereby bypassing the various security measures provided by our CDN.

Set up your firewall to only allow requests from our network.

View our IP blocks (Customer Origin Group / Legacy).

All configuration changes take effect in 2 minutes or less.

Event log data is available for 30 days.

Event log data for the last 30 days is available either through the Rate Limiting Dashboard or our REST API service.

Learn more about our REST API service.

• Content Delivery

  • ADN
  • IPv6
  • Cache Management
  • Rules Engine

• Security

  • CDN Security
  • MCC Security
  • Origin Shield
  • Rate Limiting
  • Token-Based Authentication
  • WAF

• Streaming

  • Dynamic Cloud Packaging
  • Smooth Streaming
• Raw Logs
• Route (DNS)
• Storage