The specifics of our casino require us to have a pretty quality low-latency connection, so AWS was a first choice. I was recommended to use ELB which could mitigate the level3 attacks (primariy SYN floods we were seeing) and automatically scale.
I setup a test instances, and tried orchestrate my own SYN flood which it handled without issue (while a normal ec2 instance would just collapse). So I put production behind ELBs, and a few hours later the attacks started.
The first thing was that under stress ELB stops being able to make connections, and starts failing your origins for status check (even when they were getting no load), but was able to successfully scale to mitigate the attack within 5-7 minutes. The attacker tried again a few hours later, but it seems things were nice and pre-warmed and the attack didn't get far.
For about a day there was a nice calm, and ELBs was performing absolutely fantastic (in terms of latency/jitter), and then I got the email that he's about to throw everything at me. And within a few minutes, he took out all the ELBs and it wasn't able to scale to handle the traffic for over an hour this time.
During this time I was in contact with CF's excellent support, and they offered me protection for websockets. It has slightly more latency than ELBs, but is actually an anti-ddos service, and works wonderfully. Since being fully behind CF we've only had one DDoS related outage, and it was specific to Seoul for about ~3 or 4 hours.
Can't recommend them enough, quite literally my business might not be around if it wasn't for them.
It'd be much more cost effective to pay CloudFlare a fixed monthly fee and stop the DDOS attack before it even gets to your AWS resources.
Edit: found it.
https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June20...
Well, DDoS operators usually don't do their job for fun (okay, I'm discarding Lulzsec and other vandalism-motivated folks here).
It's much more profitable to hunt for not-CDN-backed sites and extort them for money. Or to look for processor-heavy API endpoints (e.g. login with huge work factors) to improve the DDoS effectivity, but then again a lot of DDoS ops are script-kiddies looking for a quick bunch of monies, all too often not skilled enough for this.
Netflix likely implements their own DDOS protection layer somewhere in their routing library. For example, since most resource-intensive Netflix endpoints are protected (you have to login to watch a movie), they could use rate-limiting based on User Account ID.