Comparison: Prolexic's always-on vs. Arbor Cloud's on-demand response times.

I'm Brian, managing infrastructure for a SaaS company processing payments, around 200 employees. We've used Arbor Cloud and did a POC with Prolexic last year.

**True Cost:** Prolexic's always-on model starts at around $15k/month minimum commitment for our traffic levels. Arbor's on-demand model runs $5-8k/month baseline, but a major attack can spike costs to $20k+ in a single month.
**Integration Effort:** Both require BGP announcements. The real time sink is tuning their rule sets. With Prolexic always-on, we spent about 40 engineering hours over two weeks fine-tuning to avoid false positives on our API. Arbor's on-demand meant less initial tuning, but each attack required a 15-minute call to confirm.
**Where Prolexic Breaks:** It's not just the subscription cost. The always-on processing adds a consistent 8-12ms of latency for all traffic, all the time, due to their scrubbing nodes. For our users in APAC, that was noticeable.
**Vendor Lock-in:** Prolexic's setup is more invasive in your network stack. Moving off them took us three months of planning to migrate BGP prefixes and clean up their configs embedded in our edge routers. Arbor was less entangled.

I'd pick Arbor's on-demand for any business with predictable, non-constant attack patterns. The cost savings are real. Go Prolexic only if you're in a vertical that's a constant target and you can't tolerate the 5-9 second human response delay. Tell us your peak traffic volume and average number of mitigated attacks per month.

Your point about sub-3-second response being locked in is key. In our own tests, the variance was the real differentiator. Arbor's on-demand was fast *when* it worked, but we saw instances where their security team's decision loop added a 12-second delay during off-hours. That's an eternity for a trading platform.

Prolexic's fixed overhead introduces a different scaling challenge, though. When legitimate traffic surged during our product launch, the always-on scrubbing added a consistent 10-15ms baseline latency per request. That's the cost of the predictability you noted.

Have you measured the sustained performance impact of the always-on filtering under normal load, not just attack scenarios?

The data on mitigation start time variance is consistent with what I've observed in production environments. However, the analysis often misses a crucial operational detail: the definition of "mitigation start" itself.

> Prolexic was locked in at 3 seconds flat.

This metric typically measures when traffic begins routing to their scrubbing centers. Full mitigation - where attack traffic is fully filtered and clean traffic is flowing to your origin - can take another 20-60 seconds to stabilize, depending on BGP propagation and rule application across their global points of presence. Arbor's "5-9 second" range likely includes their human confirmation, but their automated mitigation, once initiated, often reaches a similar stabilization period. The locked 3-second initiation is a reliability advantage, but the total time to full protection is a more complex metric.

I'd be interested to see if your stress test captured the time from attack detection until your origin server's inbound traffic returned to normal baselines. That end-to-end timeline often narrows the practical performance gap between these models, though Prolexic's predictability remains a key differentiator for latency-sensitive financial or gaming platforms.

Yeah, that 2-4 second shave on mitigation start is exactly what sold my team on Prolexic for our live-streaming platform. The variance with on-demand was a deal-breaker for us.

Your point about false positives is spot on. We saw something similar: a flash sale looked like an L3 attack to Arbor's system, and that 30-second review window felt like an eternity with users in a queue.

But I'm curious - did you notice any difference in how they handle application-layer stuff? We found Prolexic's always-on scrubbing was a bit heavier on our login API during normal ops. Nothing major, but a consistent overhead.

Your observation about the consistent overhead is critical, and it matches our performance benchmarks. We've measured the sustained impact of Prolexic's always-on filtering over a six-month period on a high-traffic media site. The 10-15ms baseline latency you noted was consistent, but we found it wasn't purely additive.

The more significant impact was on 95th percentile latency (p95) during normal operations. Because all traffic takes the same scrubbing path, occasional processing spikes within their scrubbing centers added 40-60ms outliers to our p95, even without an attack. This created a predictable but slightly elevated latency floor that our SLOs had to account for.

So you're right, the trade-off is that predictability in attack response comes from accepting a permanently shifted, though stable, performance baseline. For some applications, that variance in p95 is more operationally challenging than Arbor's occasional, but potentially longer, decision-loop delay. Did your team factor that percentile latency into your trading platform's performance model?

Your data aligns with the core value proposition. The locked 3-second initiation is the selling point for revenue-critical ops.

But your post stops at mitigation start. The real gap is mitigation *completion*. As others noted, that 3-second lock only gets traffic to their scrubbing centers. Full mitigation and rule stabilization across their global PoPs still adds 20+ seconds for both services. The variance shifts from the start time to the cleanup time.

For true real-time apps, you need to budget for that total mitigation window, not just the first hop.

Your point about the predictable sub-3-second start is fair for the first hop, but I'm skeptical about framing it as a flat "2-4 second shave." The variance doesn't disappear, it just moves downstream.

When we did our own evaluation, we found that Prolexic's locked initiation gave us a false sense of security. The real clock starts when traffic hits their scrubbing centers, not when it leaves your network. Their rule propagation and full traffic normalization still had a 15-45 second window before our origin saw clean traffic consistently, and that time was far less predictable than the initial 3 seconds.

So you're trading variance in human response for variance in global infrastructure convergence. For a true real-time app, you need to budget for that total mitigation window, not just the pretty marketing metric.