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:

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 Load Balancers service.

Figure: Console Homepage
Figure: Console Homepage

  • Select your namespace.

  • Navigate to Manage > Load Balancers > HTTP Load Balancers.

  • Select ... for your load balancer and select Manage Configuration to open load balancer configuration form.

  • Select Edit Configuration option located in the top right corner of the form.

LoadBalancerEdit
Figure: Edit Load Balancer Configuration

Step 2: Start configuring API rate limits.
  • Scroll down to the Security Configuration section.

  • In the Rate Limiting field, select the API Rate Limit option.

APIRateLimitView
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 the IPv4 Prefix List field. You can add more than one using the Add 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 the List of IP Prefix Sets drop-down menu. You can add more than one using the Add 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 Add Item in the Server URLs section and do the following in the ServerUrlRule form:

  • Select the Domain field and select either Any Domain or Specific Domain. In case of specific domain, enter the domain in the Specific Domain field. Default option is Any Domain.

  • Select on the Base Path field and enter a base path.

Note: Select the Base Path field and click See 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 and Duration 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. Select User Identification Policy for the Count By field and then select an existing user identification policy or use the Add 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 the Create new Rate Limiter option to create a new rate limiter and apply it here.

ServerUrlRule
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 the Server 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.

Step 4: Set API endpoint rules.

The API endpoint rules apply rate limiting for specific endpoints.

  • Select Add Item in the API Endpoints section and do the following in the New Item form:

  • In the Domain field, select either Any Domain or Specific Domain. In the case of specific domain, enter the domain in the Specific Domain field. The default option is Any 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 select See 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 under HTTP 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 the Invert 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 and Duration 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. Select User Identification Policy for the Count By field, click on the User Identification Policy field, and select an existing user identification policy or use the Create 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 the Create new Rate Limiter option to create a new rate limiter and apply it here.

APIEPRule
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 server URL rule. Use the Add Item in the API 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.

Step 5: Complete configuration and save the new settings.
  • Check the order of the rules you added.

APIRateLimitRules
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 method POST.

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 method GET is added first.

  • A general rule setting 20 requests per second as limit for endpoint /product/{productId} and method ALL 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.


Concepts