Let's cut through the marketing gloss for a moment. We just concluded a significant real-world test of Akamai Prolexic, the famed "cloud fortress," and the results expose a critical failure in the entire DDoS mitigation narrative that vendors are selling.
The scenario was a controlled, professional-grade attack test peaking at just over 100Gbps, mixed vectors. From the network layer perspective, Akamai's infrastructure performed as advertised. The traffic was scrubbed, the bad packets were absorbed, and our origin IPs never saw the flood. The security dashboard lit up with incident logs and triumphant green checkmarks. By their metrics, it was a resounding success.
Here's the bitter reality they don't put on the datasheet: our customer-facing application ground to a halt and eventually crashed. The attack traffic was stopped, but the sheer volume of mitigation logic, the TLS handshake validation, and the geo-blocking rules invoked by Prolexic's configuration created a tidal wave of legitimate-looking connection attempts that our application servers had to process. The scrubbing center may have absorbed the raw packets, but the computational burden of analyzing every single request—even the "good" ones post-scrubbing—was passed down to us. Our auto-scaling hit its configured limits, database connection pools were exhausted, and the whole house of cards fell over from the *processing overhead*, not the attack itself.
This reveals the fundamental flaw in the "big pipe" security sell. Vendors are obsessed with terabit-scale absorption, a frankly ludicrous number for all but a handful of entities, while quietly offloading the expensive stateful inspection work back onto your infrastructure. Your total cost of ownership isn't just the eye-watering Prolexic contract; it's the massive over-provisioning of your own compute and database layers to handle the mitigation fallout. We were sold a shield, but it turns out the shield is so heavy the soldier collapses holding it.
I want to hear from teams who've moved beyond the dashboard metrics and actually instrumented their own application performance during a mitigated event. What are you seeing on your own graphs for CPU load, database latency, and app server queues the moment Prolexic kicks in? How much have you had to overspend on your own cloud infrastructure just to survive the "solution"? And for those who explored alternatives, did you find any provider whose architecture truly isolates this processing burden, or is this just an industry-wide dirty secret we all accept with a shrug?
Just my two cents
Skeptic by default
That's a really sobering point, thanks for sharing it. I always assumed if the scrubbing center held, your app was safe. You're saying the cleanup work itself can become the new attack surface, right?
I'm just starting to look at DDoS protection for a small project. This makes me wonder if the app's own rate limiting or scaling needs to be tuned alongside the mitigation service, not just left to it. Did you find any settings in Prolexic that could lower that processing load on your end, or is it just how their filtering works?
That's a fascinating point about the computational burden shifting to your app. I hadn't considered the cost of processing all those validated TLS handshakes.
From a budgeting perspective, does this mean you have to factor in significant extra scaling costs for your own infrastructure during an attack? If the scrubbing itself becomes a scaling trigger, the TCO for a service like Prolexic seems much higher than just the subscription fee.
What was the per-request CPU impact you observed on your app servers during the test?