DDOS protection mechanism

Hi,

I'm representing customer moving from another Api management system (without naming it 😉 ). I want to protect my back-end services from very heavy load that could kill them. I have many customers with different limits (quotas) per second now. Small customer is limited for example to 100 calls / second. Bigger to 1000 calls / second. Huge to 5000 calls / second. Typical use case: My customer uses my API in burst - they do 32 calls at once (in few milliseconds) and then do nothing for next 1 second. After that another burst. My question is - is there a mechanism in Apigee that could replace my current DDOS protection method? It cannot be too strict - it cannot block bursts of calls done in few milliseconds.

On the other hand customer doing rapidly extra 50.000 calls / second could kill my back-end service and I want to prevent it. I think one of the solutions is using your quotas per minute (then I will multiply limits by 60). Still it is not perfect as my big customer with limit 5.000 calls / second will be able to do (60x5) 300.000 calls in one second theoretically (and kill my back-end). Spike Arrest is not applicable imho. As if I'm reading documentation correctly it makes locks. In case of small customer with limit of 100 calls / second it will be making 10 ms locks. And then my customer doing 32 calls at once (in few ms) will get just one correct answer and rest of calls will be blocked - right? (of course this is not acceptable for customer). Additionally how spike arrest would work for my big customers - doing 5000 calls / second. Would Apigee calculate lock to nanoseconds and put lock and unlock user key in nanoseconds? Any hints how to solve it? How you would migrate my DDOS protection mechanism to Apigee?

6 6 926
6 REPLIES 6

I even made a graph presenting how 'spike arrest' would work for my example small customer. Please correct me if I'm wrong. My understanding so far is that spike arrest is not the way to go if we have customers doing rapid bursts of API calls. (I guess spike arrest would work fine if my customers would use API in consistent manner - with more or less constant speed (tps))

spike-arrest.png

2724-spike-arrest.png

I have read also this article: http://docs.apigee.com/api-services/content/comparing-quota-spike-arrest-and-concurrent-rate-limit-p...

I found there is also something called 'Concurrent Rate Limit' - but this limits calls from all customers to the backend. This would for sure protect my back-end but in case of one single 'misbehaving' customer all customers would be affected - right?

I'm not sure I'm completely clear on what specifically you need to do, but I think you _might_ be able to get towards this by applying multiple quota or rate limit policies. You aren't limited to one. So define the one to deal with spikes in small range, then define others to deal with overall usage at the larger time interval.

Do you think that would accomplish what you're trying to do?

@Carlos Eberhardt Thank you for your answer. I think we would go this way you mentioned multiple quotas (short term and long term) and maybe some rate limit police. Obviosuly like I mentioned it has some drawbacks.

It's an interesting challenge. Spike arrest may still be useful for simply protecting your back end systems from unexpected load. They must scale pretty well already though.

I'd like to know how it goes as you flesh out the solution more. If you're willing, please update the thread here..

sjm2000
Participant V

very challenging but scenarios we find more these days-

1. you need some AI based system which apigee or any api management system in market currently does not have - (maybe a WAF would have but its out of our scope).

2. since you migrating from another system, if its b2b , i would recommend to identify the source of real customers - identify by a product+api key- then its easier to put a logic to back end protection

3. Use a WAF anyways - its good in limiting these issues.

4. Use api input field validation in apigee before sending to backend - dont need to send junk to backend .