

Setting Limits for Rate Limiting¶

Rate Limiting allows you to limit the number of successful hits to an API during a given period, typically in cases such as the following:

To protect your APIs from common types of security attacks such as certain types of denial of service (DoS) attacks.
To regulate traffic according to infrastructure availability.
To make an API, application, or a resource available to a consumer at different levels of the service, usually for monetization purposes.

You can define Rate Limiting at the API, application, resource and subscription levels. The final throttle limit granted to a given user on a given API is ultimately defined by the consolidated output of all Rate Limiting tiers together.

Example : Lets say two users are subscribed to an API using the Gold subscription, which allows 20 requests per minute. They both use the application App1 for this subscription, which again has a Rate Limiting tier set to 20 requests per minute. All resource level Rate Limiting tiers are unlimited. In this scenario, although both users are eligible for 20 requests per minute access to the API, each ideally has a limit of only 10 requests per minute. This is due to the application-level limitation of 20 requests per minute.

Different levels of Rate Limiting¶

It is possible to throttle requests for each tier based on the request count per unit time or the amount of data (bandwidth) transferred through the Gateway per unit time. You can configure this via the Admin Portal. For more information, see Adding New Rate Limiting Policies.

Let's take a look at the different levels of Rate Limiting:

Subscription-level Rate Limiting (API publisher))
- Burst Control
Subscription-level Rate Limiting (API subscriber)
Advanced Rate Limiting (API publisher)
Application-level Rate Limiting (application developer)
- Application-level Rate Limiting tiers

Subscription-level Rate Limiting (API publisher)¶

Subscription-level Rate Limiting tiers can be applied for an API by navigating to the Subscriptions tab under Portal Configurations using the API Publisher portal.

Subscription-level Rate Limiting tiers¶

The default Rate Limiting tiers are as follows:

Bronze : 1000 requests per minute
Silver : 2000 requests per minute
Gold : 5000 requests per minute
Unlimited: Allows unlimited access (you can disable the Unlimited tier by editing the enable_unlimited_tier element under [apim.throttling] in the <API-M_HOME>/repository/conf/deployment.toml file.)

It is also possible to specify a bandwidth per unit time instead of a number of requests. This can be done by an API Manager administrator. For information on editing the values of the existing tiers, defining new tiers, and specifying a bandwidth per unit time, see Adding a new subscription-level Rate Limiting tier.

Note

Note that when you edit an API with active subscribers, certain things like tier changes do not get automatically reflected to the subscribers. For such changes to take effect, the subscribers should resubscribe to the API and regenerate the access token.

Burst control¶

With burst control, you can define tiers with a combination of criteria, for example, a 1000 requests per day and 10 requests per second. Users are then throttled at two layers. Enforcing a rate limit protects the backend from sudden request bursts and controls the usage at a subscription and API level.

For instance, if there's a subscription level policy enforced over a long period, you may not want users to consume the entire quota within a short time span. Sudden spikes in usage or attacks from users can also be handled via Rate Limiting. You can define a spike arrest policy when the subscription level tier is created. For more information on using Rate Limiting in subscription tiers, refer Adding a new subscription-level Rate Limiting tier.

Note

Spike Arrest Policy(burst control) is used to protect the API backend against large number of traffic spikes and DoS attacks. Unlike setting one definite Rate Limiting tier (Quota), it helps to limit the sudden increase of number of requests at any point in time.

As an example, if we specify a quota policy as 20 requests per minute, it is possible to send all 20 requests in first few seconds in one minute so that we cannot limit it. By defining a spike arrest policy as 10 requests per second, it equally scatters the number of requests over the given one minute. Therefore, by doing Rate Limiting we can protect the backend from sudden spikes and DoS attacks through spike arrest policy.

For each subscription level throttle key, a WS policy is created on demand. The request count is calculated and rate limiting occurs at the node level.

Note

Configure Rate Limiting for the API Gateway Cluster so that the request counters will be replicated across the API Gateway cluster when working with multiple API Gateway nodes.
Configuring Rate Limiting for the API Gateway cluster is not applicable if you have a clustered setup.

Subscription-level Rate Limiting (API subscriber)¶

After subscription-level Rate Limiting tiers are set and the API is published, at subscription time, the consumers of the API can sign in to the Developer Portal and select which tier (out of those enabled for subscribers) they are interested in, as shown below:

According to the selected tiers, the subscribers are granted a maximum number of requests to the API.

Advanced Rate Limiting (API publisher)¶

Advanced Rate Limiting policies are applied when you are Publishing an API. It can be further divided into the following two levels base on the applicability.

API level Rate Limiting
Resource level (operational level) Rate Limiting

API level Rate Limiting¶

API level policies can be engaged via the resources section of an API in the Publisher portal by selecting API Level under Rate Limiting level as shown below.

Resource level (Operation level) Rate Limiting¶

An API is made up of one or more resources. Each resource handles a particular type of request and is similar to a method (function) in a larger API. You can use this method when handling a large number of request at resource level such as Financial transactions. For example, Imagine API have two resources and one resource take more request than other you do not need to throttle it in API level in that case you can use this. Resource-level Rate Limiting tiers are set to HTTP verbs of an API's resources. You can apply resource-level Rate Limiting through the Resources section of an API as shown below.

Advanced Rate Limiting tiers¶

The default Rate Limiting tiers are as follows:

10KPerMin : 10,000 requests per minute
20KPerMin : 20,000 requests per minute
50KPerMin : 50,000 requests per minute
Unlimited: Allows unlimited access (you can disable the Unlimited tier by editing the enable_unlimited_tier element under [apim.throttling] in the <API-M_HOME>/repository/conf/deployment.toml file.)

It is also possible to specify a bandwidth per unit time instead of a number of requests. This can be defined via the API Manager Admin Portal. For information on editing the values of the existing tiers, defining new tiers, and specifying a bandwidth per unit time, see Adding a new advanced Rate Limiting policy.

Application-level Rate Limiting (application developer)¶

Application-level Rate Limiting tiers are defined at the time an application is created in the Developer Portal as shown below. The limits are restricted per token for a specific application.

An application is a logical collection of one or more APIs and is required to subscribe to an API. Applications allow you to use a single access token to invoke a collection of APIs and to subscribe to one API multiple times with different SLA levels.

An application is available to a consumer at different levels of service. For example, if you have infrastructure limitations in facilitating more than a certain number of requests to an application at a time, the Rate Limiting tiers can be set accordingly so that the application can have a maximum number of requests within a defined time.

Application-level Rate Limiting tiers¶

The default Rate Limiting levels are as follows:

10PerMin : 10 requests per minute
20PerMin : 20 requests per minute
50PerMin : 50 requests per minute
Unlimited: Unlimited access. The Default Application, which is provided out of the box has the tier set to Unlimited.

It is also possible to specify a bandwidth per unit time instead of a number of requests. This can be done through the Admin Portal of API Manager. For information on editing the values of the existing tiers, defining new tiers and specifying a bandwidth per unit time, see Adding a new application-level rate limiting tier.

Note

When creating an API by importing a Swagger or Open API definition, the user can define the throttle policies for both API level and resource level using the “x-wso2-throttling-tier" extension.

x-wso2-basePath: /petstore/v1
x-wso2-throttling-tier: 10kPerMin
x-wso2-production-endpoints:
urls:
- https://petstore.swagger.io/v2

Resource level throttle policies also can be defined as well.

paths:
    "/pet/findByStatus":
        get:
        tags:
        - pet
        summary: Finds Pets by status
        description: Multiple status values can be provided with comma separated strings
        operationId: findPetsByStatus
        x-wso2-throttling-tier: 20kPerMin

Top