It would really help to understand why attack one endpoint with "the largest DDoS attack ever observed in the cloud". If it was important, it would be redundant in its CDN. Who paid for this attack and what did they gain?
It would really help to understand why attack one endpoint with "the largest DDoS attack ever observed in the cloud". If it was important, it would be redundant in its CDN. Who paid for this attack and what did they gain?
The idea of DDoS for hire is to bury your own tracks in as much network requests as possible, so that the other side is overwhelmed processing (or even storing) that dataset and won't find out what the real target was.
That's literally the strategy of APT28/29.
Thankfully, it was almost always targetted at our www servers, which were not important for our service. Very occasionally, we'd get hit on the machines that we actually ran our service on, but between the consistent DDoS on www, and our own self-inflicted DDoS from defects in the client code we wrote for our users, our service was well prepared... if the DDoS went over line rate for the server, our hosting provider would null route it [1], but otherwise, we could manage line rate of udp reflection or tcp syn floods and what have you. From what I could tell, most attackers didn't retarget to our other servers when one got null routed.
[1] They did try a DDoS scrubbing service, but having our servers behind the scrubber was way worse than just null routing. Maybe the scrubbing could have been tuned, but as it was, it was better for us to just have the attacked servers lose connectivity to the public network.
is what I'll call bugs from now