Apply custom policy-based rate limiting to Azure APIs using Azure API Management
While the Azure docs lead me think that if you are a Cloud Solution Provider (CSP) partner there is a way to limit API calls by CustomerId that is not available where you issue subscriptions to users.
In our case each customer can have as many users as they wish. Each user has a subscription to an Azure Product (eg the Unlimited product).
Just because we give access to the Unlimited product doesn't mean we want an unlimited flood of requests.
What I needed to do was limit all the users for a company as a job lot to a given number of requests per minute.
Limiting by subscription (ie, API key) is documented but we need a higher level grouping to rate-limit on. This does not seem to be available so I have done it this way:
- Created three users. All users by default (and this can't be changed) are put into Developers. I also created two groups, Customer1 and Customer2 and put two users into the first and one into the second.
Go API> All APIs >Inbound Processing > rate-limit-by-key
This will let you edit the default policy on the APIs
Edit the policy
It's C# 7 syntax but there can be only one policy per product or API. So I've applied a limit on 12 requests in a 60 second period, with the count being incremented by the name of group where the group name starts with 'Customer'. This is to distinguish it from say the Developers group which treats all customers' users the same
Doing this will keep track of the count of requests by customer no matter how many users they have, as long as each customer's users are correctly assigned to their group.
To see the policy in action (and how it processed) you'll need to use the API inspector.
Go API> All APIs > Echo API > Test > GET
This will let you test the default API
Click Send and then in the Http Response click on Trace to see how the request was processed.
Aside from the headers and requests parms as you would expect you will also see the rate-limit-by-key processing result
The one thing that is not ideal is that I cannot see how to test this as one of the test users as you cannot override the subscription being used for the test request. In this case I added my own user to the Customer1 group to see how it is processed.
It does work as I can send requests from user 1 (who is in the Customer1 group) until the API returns a 429. At this point requests from user 2 (who is also in the Customer1 group) elicits a 429 but user 3 (who is in the Customer2 group) gets a 200.
It's got some documentation but not too much covering this particularly niche application.