APIM dynamic block ip address after multiple 429 responses

Question

We are using API management to throttle requests. When there are to many requests from a specific IP address within a specific time frame the APIM responds with http 429 status code. That is working as is should.

I want to extend this functionality to block an IP address for a week if we have send 10 times a http 429 response within 15 minutes for that specific IP address.

Can someone guide me how i can configure (or build) this in API Management?

Answer 1

The trickiest thing here is that you want the measurement to be over a different period than the 'ban'. There are a couple of ways I can think of doing this, but none of them are particularly elegant. It also depends upon what an 'ip address' means to your app in this context. And neither of them may work or be possible - but hopefully they will give you some ideas for some further investigation:

If an ip address is a proxy for a specific single client (eg. you are trying to rate-limit requests from individual clients, rather than a set of clients that may be (for instance) behind a NAT gateway and therefore all will show the same source IP address) then you could potentially use a custom policy to return a 'set-cookie' HTTP response header when your criteria is met. I don't know if you can have multiple rate-limit policies (and I'm not in a position to test at the moment), but if you can then adding a second rate-limit policy with a 15 mins period and 10x the value for your other policy and then, when that policy is triggered set a cookie (Via a set HTTP header response) with an expiration of +1 week. You then add an inbound policy that checks for the presence of that cookie and returns a http 429 if it exists in the client call. However, the 'limit' can be reset by the client clearing their cookies.

Another way is to create your own 'helper' API service which you can call from the APIM service which is able to record when an IP hits a limit in some sort of persistent storage (perhaps an Azure table storage for simplicity) and is queried by APIM on each call to your service, with the source IP address, which then is able to 'calculate if they have hit the limit too many times in the last 15 mins, or have been subject to a block due to that, and return a value to your APIM policy indicating the call should be rejected. This has the potential to treat an IP address an IP address, but has the down side that each call to your 'back-end' API will also require a call to this helper API service to determine if the call should be allowed. Which (depending upon volume) could increase costs and also slow down the response of your service.

Apart from these two approaches - and I don't know of your use case - but might combining a rate-limit policy with a quota based policy achieve close to what you want? Quotas are usually used to control client calls to an API over a longer period, as opposed to the rate-limit which is designed to protect your services against transient spikes.

Good luck!