Loading...

Configure rate limits for different API operations in Azure API Management

Configure rate limits for different API operations in Azure API Management
Azure API Management (APIM) is one of the PaaS products offered by Azure which allows you to publish, manage, secure and monitor APIs. One of the features of APIM is the ability to control the traffic to your APIs using policies such as rate limits and quotas.
 
Rate limits are policies that prevent API usage spikes on a per subscription or per key basis by limiting the call rate to a specified number per a specified time period. Quotas are policies that enforce a hard limit on the number of calls that can be made to an API within a billing period.
 
In this blog post, we will focus on how to configure rate limits for different operations in APIM using the `rate-limit-by-key` policy. This policy allows you to define expressions to identify the keys that are used to track traffic usage. You can use any arbitrary string value as a key, such as IP address, subscription ID, etc.

 

Scenario

Let's say you have two operations in your API: Operation A and Operation B. You want to apply different rate limits for each operation based on your business requirements. For example:
 
- Operation A has a rate limit of 5 calls per minute
- Operation B has a rate limit of 5 calls per 30 seconds
 
You also want to make sure that the rate limits are independent by operation, meaning that calling one operation does not affect the counter for another operation.

 

Solution

As per our official document, operations in APIM (regardless API) use a single counter for all scopes at which the policy is configured. Say, if you make 2 calls to one operation, these calls will be counted towards the single counter used by all of the operations.
 
anjalidivitha_0-1680772143406.png
 
To achieve this scenario, you need to use the `rate-limit-by-key` policy with an expression that produces unique values for different operations. One way to ensure that is to add `context.Operation.Id` to the expression.
 
The `context.Operation.Id` property returns a unique identifier for each operation in your API. By concatenating it with another value such as IP address or subscription ID, you can create a key that is specific for each operation and each caller.
 
Here is an example of how you can apply this policy at the inbound section of your API:

 

<policies> <inbound> <!-- Extracts caller's IP address --> <set-variable name="caller-ip" value="@(context.Request.IpAddress)" /> <!-- Applies rate limit by key using IP address and operation ID --> <rate-limit-by-key calls="5" renewal-period="60" counter-key="@(context.Request.IpAddress + context.Operation.Id)" /> <base /> </inbound> ... </policies> ```

 

To test this solution, you can use any tool that can send HTTP requests such as Postman or curl. You can also use Azure Portal's Test console feature.
 
Note: Due to the distributed nature of throttling architecture, rate limiting is never completely accurate. The difference between the configured and the actual number of allowed requests varies based on request volume and rate, backend latency, and other factors.
 
You can also customize this policy by adding optional attributes such as increment-condition or quota-exceeded-response-code. For more details on how this policy works and what options are available, see: https://learn.microsoft.com/en-us/azure/api-management/rate-limit-by-key-policy

 

In this blog post, we have seen how to configure rate limits for different operations of an API in Azure API Management using the `rate-limit-by-key` policy.
This policy allows us to define expressions to identify the keys that are used to track traffic usage.
We have also seen how to use `context.Operation.Id` as part of the key expression to ensure that the rate limits are independent by operation.
  
We hope this blog helps you! 

Published on:

Learn more
Azure PaaS Blog articles
Azure PaaS Blog articles

Azure PaaS Blog articles

Share post:

Related posts

Azure Storage - TLS 1.0 and 1.1 retirement

Overview TLS 1.0 and 1.1 retirement on Azure Storage was previously announced for Nov 1st, 2024, and it was postponed recently to 1 year later...

1 year ago

Efficient Management of Append and Page Blobs Using Azure Storage Actions

  Overview In Azure Storage, Blob Lifecycle Management (BLM) allows you to automate the management of your data based on rules defined by...

1 year ago

[Azure AI Search] Internal Server Error when creating CMK encrypted objects

Scenario Customers follow the Microsoft doc to create CMK encrypted objects (data source, index etc.), but get the 500 Internal Serv...

1 year ago

Optimizing Azure Table Storage: Automated Data Cleanup using a PowerShell script with Azure Automate

Scenario This blog’s aim is to manage Table Storage data efficiently. Imagine you have a large Azure Table Storage that accumulates logs from ...

1 year ago

Optimizing Azure Table Storage: Automated Data Clean-up using a PowerShell script with Azure Automat

Scenario This blog’s aim is to manage Table Storage data efficiently. Imagine you have a large Azure Table Storage that accumulates logs from ...

1 year ago

Restoring Soft-Deleted Blobs with multithreading in Azure Storage Using C#

Blob soft delete is an essential feature that safeguards your data against accidental deletions or overwrites. By retaining deleted data for a...

1 year ago

Performing simple Azure Table Storage REST API operations using curl command.

The blog provides guidance to perform simple Table Storage REST API operations such as Create table, Delete Table, Insert entity, Delete entit...

1 year ago

Bulk delete all the old jobs from the batch account

Deleting a Job also deletes all Tasks that are part of that Job, and all Job statistics. This also overrides the retention period for Task dat...

1 year ago

Utilizing Azure Storage and Runbooks for scheduled automated backups of Azure SQL Databases

In this article, we are going to provide detailed steps to create a scheduled Azure SQL Database backup to storage account using automation. T...

1 year ago

[Azure Service Bus] JMS messages getting dead-lettered

The article discusses a problem where numerous messages end up in the dead letter queue (DLQ) when the JMS service bus consumer connects to th...

1 year ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy