Everyone’s quick to praise Prolexic’s set-and-forget DDoS protection, but that’s exactly how you end up with a bill that makes your CFO wince. The default thresholds are a blunt instrument, and paying for “insurance” against traffic your app would never legitimately generate is just lazy.
We run a B2B SaaS with very predictable, low-bandwidth API calls. Yet for months, we were getting charged for mitigation on volumetric thresholds that assumed we were a media streaming service. Tuning the detection and mitigation rules to our actual traffic patterns cut our quarterly Prolexic costs by about 40%. It’s not magic, just acknowledging that our threat profile isn’t the same as an e-commerce site getting slammed on Black Friday.
The real trick is balancing security theater with actual risk. Do you really need to trigger on a 5 Gbps SYN flood when your entire daily ingress is 500 Mbps? Probably not. Start with your own traffic baselines—packet rate, connection rate, bandwidth—and then work backwards from Prolexic’s defaults. Adjust the anomaly multipliers, tweak the activation thresholds for your specific vectors (hello, UDP reflection), and for the love of all that’s holy, don’t just leave the managed rules in their most aggressive profiles.
It requires some monitoring and a few nerve-wracking tests, but the savings are real. Or you could just keep paying Akamai to protect you from ghosts. 👻
Just stirring the pot
But what about the edge case?
Agreed, but you're only focusing on volumetric thresholds. The bigger waste is often in the application layer rules. Prolexic's default HTTP anomaly detection is tuned for common web attack patterns, which might include things like aggressive crawler blocking or SQLi heuristics. If you're a headless API service, half those rules are irrelevant noise. You can strip them out entirely and just focus on the vectors that could actually disrupt your service, like malformed JSON payloads or connection exhaustion on your specific endpoints. It's a more surgical, and cheaper, approach.
—davidr
Spot on about the baseline analysis. That's the step most teams skip because it's tedious. We built a simple dashboard pulling packet rate and connection metrics from our edge routers into Prometheus, then compared it to Prolexic's trigger logs over a month. The mismatch was laughable.
We found their default SYN flood threshold would trip at 10k packets/second, but our normal peak was around 300. Bumping that threshold up saved us from a dozen false mitigations a week, which added up fast.
>Do you really need to trigger on a 5 Gbps SYN flood when your entire daily ingress is 500 Mbps?
Exactly. Our CFO approved the dashboard project once we showed him the cost per false positive.
The Prometheus dashboard is a smart move. I've seen teams try to do this by hand with CSV dumps and it always falls apart after a week.
One caveat: don't just look at the average. You need to graph the 99th percentile over a full business cycle to catch those weird, legitimate spikes. If your quarterly reporting tool runs on the first of the month and triples your normal packet rate for two hours, that's your real baseline.
Your CFO point is key. These conversations always go smoother with a graph showing money wasted per month.
Build once, deploy everywhere
Totally agree on the need to watch for those periodic spikes, that's the kind of thing that gets missed. Building that 99th percentile view over a full cycle is crucial.
But it gets even more specific: you have to separate spikes by customer or even internal service. Our main app's baseline is steady, but we have one big client whose batch jobs cause a 4x traffic spike every Sunday night. If we'd tuned based on the overall app's 99th percentile, we'd still be paying to mitigate "anomalies" that are just Bob from Accounting's weekly upload. We ended up creating separate traffic profiles for our top five clients to set intelligent thresholds.
Graphing the money wasted is the ultimate persuasion tool, though. We called ours the "Lazy Tax Dashboard" and it's the first thing on our infra review deck now.
Try everything, keep what works.
Your point about volumetric thresholds being a blunt instrument is exactly right. We ran a similar analysis on our internal APIs, but we also benchmarked the latency penalty of the mitigation itself when it triggered.
Even a false positive where Prolexic kicks in for 90 seconds can add 200ms of jitter to our 99th percentile response times, which violates our SLOs. So the cost isn't just the bill from Akamai, it's the hidden performance tax on our users during those unnecessary mitigations. Tuning the thresholds helped our CFO and our performance dashboard.
-- bb42