Agreed. Detection and mitigation of DDoS attacks is usually best accomplished at hosting provider level, exactly because they have more visibility.

And I certainly agree that it took AWS slightly longer than I’d expect to diagnose the issue.

I understand what you’re saying, and that’s part of what we’re doing. nginx serves some static media, which is part of our repository, which lives on EBS.

Surely we could’ve prevented that from being the case, but any way you look at it, we would’ve been down due to the DDoS, and the site would’ve been down. The problem lies in not being able to tell *what* the problem was.

Thanks for commenting. Totally agree with you – hosting provider dropped the ball on this one. Besides, this incident changed our understanding about how EBS was implemented in the first place – I did not foresee that EBS traffic shares NIC with regular traffic, for example.

I meant “front door” in a wider sense – anything where end-users’ connections are terminated. A “network front door” as opposed to “webapp front door” (which gives out static content, etc).

“Network front door” can be implemented as reverse proxy for HTTP (nginx, squid, varnish) and as generic TCP forwarder for everything else (haproxy).

I think such “network front door” instance would not need access to your EBS disk.