Reply to post:

I agree that it is an entirely obvious attack.

I do NOT agree that it is easy to defend against--especially given the difficulty of monitoring spending on these platforms.

I have read an article on this subject. The authors of that paper were arguing for some sophisticated analytics, combined with aggressive IP-level rate limiting. Yeah, sure. I'm going to bet the company on that.

There are several layers to work this.

First, use a no-asset LLC to contract the web services. If an outrageous bill arrives, the option of walking away is real. This protects against any number of boo-boos, not just malicious actions by outsiders.

The next this to do is to closely monitor your costs. Even if the platform is denying you the actual numbers, you should be able to get almost minute-by-minute data by cost-modelling based on monitoring. A circuit breaker can then be applied.

Note that this attack is actually less disruptive than a Black Swan Event. If your company gets mentioned in a prominent way, you might see a tremendous amount of legitimate traffic. You really are hoisted by your own petard, because you can be ruined by reputation if the site is not available, and ruined by costs if it is. (Very, very little of the traffic will generate profits in the first month.)

If you can handle a BSE, a EDOS (or DOW) attack doesn't look nearly so bad. The solution is that you never go with pure serverless. I don't even know if the platforms support this, however. Unbounded cost is still a concern, but autoscaling was designed in part to handle a BSE. Again, with proper monitoring, the costs should not be a surprise.

So, if your mixed deployment uses "serverless" functionality until your system detects that it would be cheaper to switch over to autoscaling, then I suspect that EDOS loses much of its threat. Not all, but the hyper-expensive by API call costs of "serverless" deployments at least are contained.

But defending against (or even detecting) an EDOS attack where the individual nodes are tagging you at less than one qpm is going to be HARD. The statistical analysis that says "real transactions follow X distribution pattern" just means that the attackers will conform their attacks to the X distribution pattern. It's almost as easy to write attack code as it is to write the monitoring code. Sometimes, it will be easier--and since the analysis is statistical, there WILL be false positives.

If (and it is a HUGE if) the attacker is actually bearing the costs of the attack, one effective defense would be to force the attacker to spend more than you do. This can be done by requiring requests effectively mine a block. The mining is expensive compared to verifying it. But doing that means that your site is likely to trigger malware warnings on the botnet, and might get you classified as a malware site. Therefore, such a response must be limited to cases where you are fairly certain that you are facing an EDOS attack....

Defending against this is hard. Beware the inherent risks of "serverless".