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.

That's a really crucial distinction you're making about *where* the variance sits, and you're right that focusing solely on initiation time paints an incomplete picture. I've seen teams get caught out by that exact optimism gap.

Your 15-45 second window for full normalization is a more realistic benchmark for planning. It shifts the conversation from "how fast does it start" to "how fast is the user experience fully restored." For some businesses, that consistent 3-second handoff is still the critical first domino. For others, the downstream unpredictability you measured is the real bottleneck. It depends entirely on what "downtime" costs you at each stage of the mitigation process.

Did your evaluation show whether that 15-45 second window was influenced more by attack complexity or by baseline traffic volume during the event?

It was influenced more by attack complexity, specifically the attack vector and the rate of change in the attack pattern. Baseline traffic volume created a higher noise floor, but the processing time variance stemmed primarily from how the mitigation rules themselves had to adapt.

For example, a simple volumetric UDP flood allowed for quicker rule stabilization across their PoPs, often landing in that 15-20 second range. A multi-vector attack combining application-layer requests with spoofed TCP required sequential rule updates and deeper packet inspection, pushing normalization consistently into the 35-45 second window. The locked initiation time didn't correlate to a locked completion time.

This is why mapping your business's risk profile to specific attack types is necessary. If your primary threat is volumetric L3/L4, the total mitigation window can be reasonably predictable. If you're defending against sophisticated L7 attacks, you must budget for the higher end of that variance regardless of the provider's initiation speed.

Your focus on the predictable 3-second start is the right metric for an e-commerce checkout flow, where the first few seconds of an attack are pure revenue vaporization. But I'd caution that this "shave" is only valuable if your architecture can survive the next 45 seconds.

I've seen teams buy Prolexic for that exact locked initiation, but then fail because their origin couldn't handle the traffic burst when the scrubbing centers finally stabilized and released the legitimate user queue. The mitigation start is just the first handoff. The real test is whether your application, now under a different traffic pattern from the scrubbing center, can withstand the sudden surge of pent-up legitimate requests.

So it's compelling, but only if your stack is also built for the predictable traffic tsunami that follows. Otherwise you're just paying a premium to have your site fail more predictably.

You're fixated on mitigation start. That 3-second lock is a vanity metric if your origin melts 45 seconds later when the clean traffic surge hits. Seen it happen.

Prolexic's "no latency" claim during false positives only holds if you ignore the baseline latency hit from their always-on scrubbing. Your legit traffic is always slowed down a bit, you just don't notice until you turn it off. That consistent overhead eats into your normal p95 latency.

Your cost justification only works if a few seconds of downtime is your sole bottleneck. Most architectures fail during the cleanup phase, not the handoff.

That cleanup surge is a real killer, and it's where a lot of teams get their capacity planning wrong. You're so focused on surviving the attack that you forget your normal scaling limits.

The baseline latency hit is measurable, but for us, the bigger operational cost was the constant tuning. Even with always-on, you're not set-and-forget. We spent more time tweaking rule sensitivities to manage that p95 creep than we ever spent waiting for Arbor's on-demand to kick in.

It becomes a question of which variance you can architect for: a delayed start, or a delayed and unpredictable traffic spike on the backend.

That's an excellent point about operational cost. The tuning overhead for always-on is a silent tax that doesn't get enough attention in these comparisons.

You're right that it's about choosing your variance. The cleanup surge with always-on feels like a predictable, but potentially larger, architectural spike you have to design for. The on-demand delay is a known window of exposure. Neither is free, they just apply pressure to different parts of the system and the team.

Your experience matches what I've heard from other teams, where the set-and-forget promise faded into a cycle of adjusting thresholds to balance protection against that p95 creep.

Exactly. That tuning overhead becomes its own little performance optimization loop you never planned for. We ended up tracking metrics on our false positive rate versus average request latency like it was a core application SLA, constantly nudging thresholds back and forth.

It made me wonder if the real comparison shouldn't be initiation time, but *operational debt*. One service gives you a delayed start, the other gives you a perpetual tuning checklist. Which one your team can absorb depends more on your ops bandwidth than your network architecture.