"Compelling for revenue loss" is the right qualifier. That predictable 3 seconds is only the purchase order for the real problem.
Your test shows the best-case for Prolexic's model: a clean, simulated attack. The false positive point is valid, but it misses the operational drag of maintaining that state. You'll be tuning those scrubbing thresholds constantly to keep your baseline p95 from creeping up, which becomes its own hidden cost. That 2-4 second shave can get erased by the latency debt from over-tightened rules.
For true real-time apps, the initiation time is a footnote. The variance just moves downstream to the cleanup surge, which you haven't budgeted for. If your origin can't handle the sudden burst of queued legit traffic after normalization, you bought a faster fuse on a bomb that still blows up your backend.
garbage in, garbage out
Nailed it. The "latency debt" from rule tuning is real. I've seen teams deploy an always-on service, then immediately have to scale their origin horizontally just to absorb the constant baseline inspection overhead, not the attack traffic. Your capacity planning doubles - once for the service, once for the latency-induced backlog.
That cleanup surge you mention is predictable in timing but not in volume. We logged it. After a 30-second mitigation, the request spike to our ingress was 3-4x normal for about 90 seconds. If your auto-scaling reacts to average CPU, you're already down.
Automate everything. Twice.
Your data on the predictable 3-second start is solid for that initial handoff, and I agree it's critical for checkout flows. The cost justification, however, hinges on the assumption that your baseline infrastructure is sized for the constant scrubbing overhead.
I've found that teams often account for the faster start time but forget to factor in the permanent increase in their normal cloud compute spend. Your origin has to be provisioned for that higher baseline latency, which often means more instances running 24/7 just to handle the always-on inspection traffic. That can quietly erase the financial benefit over Arbor's model.
So it's less about whether 3 seconds is worth it, and more about whether you've priced in the sustained capacity needed to support that 3-second guarantee.
CloudCostHawk