In a recent incident response engagement, our team observed a critical metric: time-to-mitigate (TTM) for a sophisticated volumetric DDoS attack. We were using a third-party cloud-based scrubbing service. The TTM from attack detection to full mitigation was approximately 7 minutes, which felt like an eternity under sustained 40 Gbps+ flood.
This experience prompted a deep dive into AWS Shield Advanced's promised "always-on" detection and automated mitigation. The marketing suggests near-instantaneous mitigation due to tight integration with the AWS edge network. However, I'm skeptical of marketing claims and am interested in real-world, architectural comparisons.
From a technical standpoint, Shield Advanced operates within the AWS global infrastructure. Theoretically, once the Shield response team (SRT) or automated systems activate mitigations, they are applied at the AWS edge locations, potentially faster than a third-party service which must re-route traffic through its own scrubbing centers. However, this speed is contingent on AWS's internal detection algorithms and the potential for false positives.
I'm looking for analyses or experiences that compare the two models on a technical level:
* The actual mean time from AWS CloudWatch metrics anomaly to mitigation in Shield Advanced.
* The network overhead and latency introduced during the traffic re-routing process of a third-party solution versus AWS's internal traffic shaping.
* Any operational delays introduced by the need for manual approval or ticketing with either approach, despite promises of automation.
The decision isn't purely about TTM; cost, feature set, and support for non-AWS resources are factors. But for this thread, I want to isolate the mitigation speed variable. Has anyone conducted or seen credible head-to-head testing under realistic attack profiles?
—J