Configure API Rate Limiting
Objective
This guide provides instructions on how to enable API rate limiting feature in the HTTP load balancer. The API rate limiting controls rate of requests made to your API endpoints and uses user identification to identify the clients sending requests to your application APIs. For conceptual information on rate limiting, see Rate Limiting.
Using the instructions provided in this guide, you can apply granular rate limiting to API requests to base path or specific API endpoints.
Prerequisites
The following prerequisites apply:
-
A Distributed Cloud Services Account. If you do not have an account, see Create an Account.
-
An HTTP Load Balancer.
Note: See HTTP Load Balancer and vK8s Deployment for more information on load balancer and app deployment.
Configuration
Do the following to enable API rate limiting for your application:
Step 1: Log into Console, go to HTTP Load Balancer Settings.
- From the Console homepage, select
Multi-Cloud App Connect
service.
Figure: Console Homepage
-
Select your namespace.
-
Navigate to
Manage
>Load Balancers
>HTTP Load Balancers
. -
Select
...
for your load balancer and selectManage Configuration
to open load balancer configuration form. -
Select
Edit Configuration
option located in the top right corner of the form.
Figure: Edit Load Balancer Configuration
Step 2: Start configuring API rate limits.
-
Scroll down to the
Common Security Controls
section. -
In the
Rate Limiting
field, select theAPI Rate Limit
option.
Figure: Rate Limiting Options
-
Optionally in the
IP(s) Allowed without Rate Limiting
field, select one of the following to exclude IP addresses from rate limiting:-
IP Allowed List
- Enter IP addresses in theIPv4 Prefix List
field. You can add more than one using theAdd item
option. At least one IP address must be entered for this option. -
IP Allowed List using IP Prefix Set(s)
- Select IP prefix sets using theList of IP Prefix Sets
drop-down menu. You can add more than one using theAdd item
option. At least one pre-configured IP prefix set is required for this option.
-
Note: No IP addresses are allowed by default for the
IP(s) Allowed without Rate Limiting
field.
Step 3: Set server URL rules.
The server URL rules apply rate limiting for an entire domain or base path that contains multiple API endpoints.
-
Select
Configure
followed byAdd Item
in theServer URLs
section and do the following in theServerUrlRule
form: -
Select the
Domain
field and select eitherAny Domain
orSpecific Domain
. In case of specific domain, enter the domain in theSpecific Domain
field. Default option isAny Domain
. -
Select on the
Base Path
field and enter a base path.
Note: Select the
Base Path
field and clickSee Suggestions
to display suggested list of paths. This shows suggestions only if you have configured an API definition. To know how to create and configure API definition, see Import Swagger and Define APIs.
-
Select one of the following options in the
Rate Limiter Values
:-
Specific Values
:-
Enter a number for both of the
Threshold
andDuration
fields. The threshold represents the number of allowed requests for the time period set in the duration field. -
The
Count By
field sets the HTTP load balancer user identifier for the client identification. You can change this to use a custom user identification. SelectUser Identification Policy
for theCount By
field and then select an existing user identification policy or use theAdd Item
option to create and apply a new user identification policy.
-
-
External Rate Limiter
:- In the
External Rate Limiter
field, select an existing rate limiter. Alternatively, you can also use theCreate new Rate Limiter
option to create a new rate limiter and apply it here.
- In the
-
Figure: Server URL Rule
Note: See Configure Rate Limiting guide for instructions on how to create rate limiter and user identifiers.
- Select
Apply
to add the server URL rule. - Use the
Add Item
in theServer URLs
section to add more rules.
Note: The rules are processed in the order in which you configure the server rules. The first rule matching the request triggers rate limiting and rest of the rules after that are not executed. Therefore, ensure you set the order of rules as per your requirements.
- Select
Apply
to save your server rules list.
Step 4: Set API endpoint rules.
The API endpoint rules apply rate limiting for specific endpoints.
-
Select
Configure
followed byAdd Item
in theAPI Endpoints
section and do the following in theNew Item
form: -
In the
Domain
field, select eitherAny Domain
orSpecific Domain
. In the case of specific domain, enter the domain in theSpecific Domain
field. The default option isAny Domain
. -
In the
API Endpoint
field and enter a specific API endpoint path.
Note: You can use the
API Endpoint
field's drop-down capability and selectSee Suggestions
to display suggested list of endpoints. The suggestions are shown only if you have configured an API definition. To know how to create and configure API definition, see Import Swagger and Define APIs.
-
Select the
Method List
field underHTTP Methods
and select the methods for which the rate limiting is to be applied. You can select more than one method. Alternatively, you can select the methods you for which you don't want to apply rate limiting and then check theInvert Method Matcher
, which effectively select all the other methods for rate limiting. -
Select one of the following options for the
Rate Limiter Values
field:-
Specific Values
:-
Enter a number for both the
Threshold
andDuration
fields. The threshold represents the number of allowed requests for the time period set in the duration field. -
The
Count By
field sets the HTTP load balancer user identifier for the client identification. You can change this to use a custom user identification. SelectUser Identification Policy
for theCount By
field, click on theUser Identification Policy
field, and select an existing user identification policy or use theCreate new User Identification
option to create and apply a new user identification policy.
-
-
External Rate Limiter
:- In the
External Rate Limiter
field, select an existing rate limiter. Alternatively, you can also use theCreate new Rate Limiter
option to create a new rate limiter and apply it here.
- In the
-
Figure: API Endpoint Rule
Note: See Configure Rate Limiting guide for instructions on how to create rate limiter and user identifiers.
- Select
Apply
to add the API endpoint rule. - Use the
Add Item
in theAPI Endpoints
section to add more rules.
Note: The rules are processed in the order in which you configure the API endpoint rules. The first rule matching the request triggers rate limiting and rest of the rules after that are not executed. Therefore, ensure you set the order of rules per your requirements.
- Select
Apply
to save your to save your API endpoints list.
Step 5: Complete configuration and save the new settings.
Figure: API Rate Limit Rules
After you finish, select Save and Exit
.
Rate Limiting & Rules Behavior
It is important that you plan the order of the rules based on the behavior of rate limiting. Go through the following scenarios to understand the behavior:
Server URL Rules vs API Endpoint Rules
In the case of a server URL rule for a generic path and another API endpoint rule for a specific endpoint extending out of the same generic path, then the limit for the specific endpoint is separately counted. The following is an example scenario:
-
A Server URL rule sets 100 requests per second as the limit for path
/api/v1
-
An API endpoint rule sets 10 requests per second as limit for the specific endpoint
/api/v1/checkout
and methodPOST
.
In this case, a user accessing /api/v1
is limited to 100 requests per second, whereas a user accessing POST /api/v1/checkout
is limited to 10 requests per second. Meaning, if a user sends 10 requests for POST /api/v1/checkout
, then that user reached the limit for that path but can still send 90 requests for path /api/v1
.
Overlapping Rules within Same Category
If there are different rules within same category and they overlap, ensure that you add the more specific rule before a general rule. This causes the specific rule gets matched first and will not be skipped by matching the general rule first.
The following is an example for server URL rules:
-
A specific rule sets 10 requests per second as the limit for path
/api/v1
and is added first. -
A general rule sets 20 requests per second as the limit for general path
/api
and added after the specific rule.
In this case, a user accessing /api/v1
is limited to 10 requests per second. Once a request matches /api/v1
, rate limiting starts for it for that user. The general rule for /api
will not count the request for path /api/v1
. This essentially means any path starting with /api
except /api/v1
is limited to 20 requests per second, and /api/v1
has 10 requests per second as the limit.
The following is an example for API endpoint rules:
-
A specific rule setting 10 requests per second as the limit for endpoint
/product/{productId}
and methodGET
is added first. -
A general rule setting 20 requests per second as limit for endpoint
/product/{productId}
and methodALL
is added after the specific rule.
In this case, a user accessing GET /product/{productId}
is limited to 10 requests per second. Once a request matches GET /product/{productId}
, rate limiting starts for it for that user. The general rule for that endpoint with any method will not count the GET
requests. This essentially means any method for the endpoint except GET
is limited to 20 requests per second, and GET
has 10 requests per second as the limit for the same endpoint for the same user.