What cloud scrubbing actually does
Cloud scrubbing services like Path.net, OVH VAC, Cloudflare Magic Transit, and Hetzner's built-in DDoS protection share a common architecture: they absorb attack traffic at large-capacity scrubbing centers and forward only clean traffic to your infrastructure. This is powerful technology. A scrubbing center with 10+ Tbps of absorption capacity can handle attacks that would instantly saturate any dedicated server's uplink.
The limitation is not the scrubbing center's capacity. The limitation is the activation model. Cloud scrubbing services are absorbing an attack only when traffic is being routed through them. And traffic is typically routed through them in one of two ways: always-on (all your traffic goes through the scrubbing center at all times, adding latency), or on-demand (traffic is diverted to the scrubbing center when an attack is detected or manually activated).
For most infrastructure operators using on-demand scrubbing, the activation sequence under attack looks like this:
- Attack starts. Traffic arrives directly at your server, bypassing the scrubbing center.
- Your uplink begins filling. Service degrades. Users experience errors.
- Someone notices (monitoring, customer complaints, or the server becomes unreachable).
- You or your provider activate scrubbing. BGP routes are updated to divert traffic through the scrubbing center.
- 5 to 15 minutes after the attack started, scrubbing is active. Damage was done in the gap.
The scrubbing center is not the problem. The detection and activation lag is the problem. The scrubbing infrastructure can absorb 10 Tbps, but it was not absorbing anything during the first 5 to 15 minutes of the attack because nobody told it to start.
The reactive vs proactive sequence
Without a detection layer (reactive):
With a detection layer (proactive):
How GRE tunneling and BGP diversion work
To understand why detection enables faster scrubbing activation, it helps to understand the mechanics of traffic diversion.
When you use an on-demand scrubbing service, your traffic normally reaches your server via your transit provider's routing. Your server's IP prefix is announced via BGP from your own ASN (or your provider's ASN). Under attack, you want to divert traffic to the scrubbing center instead.
BGP diversion works by having the scrubbing center announce your IP prefix with a more-specific route (or by updating your BGP announcement to point traffic toward the scrubbing center's network). Once the more-specific BGP route propagates across the internet, traffic destined for your IP addresses flows to the scrubbing center instead of directly to your server. The scrubbing center filters out attack traffic and forwards clean traffic back to your server via a GRE tunnel (Generic Routing Encapsulation) or IPIP tunnel that bypasses the BGP diversion.
The GRE tunnel is the "clean traffic return path": the scrubbing center knows your server's real IP address and sends filtered traffic directly to it through the tunnel, while the BGP routing continues to steer all external traffic through the scrubbing center for filtering.
This entire mechanism works correctly and at scale. The limitation is not the mechanism but the time it takes to activate it without automated detection. BGP route propagation takes 30 to 90 seconds after the diversion is configured. Before you can configure the diversion, someone has to recognize the attack and initiate the process. That human-in-the-loop step is where the 5 to 15 minute lag comes from.
Pre-configured vs on-demand scrubbing: Some scrubbing providers offer API-based activation that can be triggered programmatically when integrated with a detection system. This is the model Flowtriq uses with cloud scrubbing integrations. When Flowtriq detects an attack, it can call the scrubbing provider's API to initiate diversion automatically, rather than waiting for a human to open a ticket or click a button. The scrubbing provider's infrastructure is always ready; the question is how quickly the API call arrives to start the diversion. With sub-second detection, that API call arrives within seconds of the attack starting.
What Path.net, OVH VAC, Cloudflare Magic Transit, and Hetzner protection actually provide
Each of these providers has significant scrubbing capacity and well-engineered filtering infrastructure. Understanding the activation model for each clarifies where a detection layer adds value:
Path.net: High-capacity game server and bare-metal protection with BGP integration. Traffic can be pre-routed through Path.net's network for always-on protection, or diverted on-demand via BGP. With always-on routing, Path.net's filtering is active immediately but adds latency; with on-demand routing, the activation lag applies. Path.net supports custom BGP adapters, which is how Flowtriq's integration works: Flowtriq detects the attack and triggers the BGP diversion programmatically.
OVH VAC (Vacuum Anti-DDoS): OVH's built-in scrubbing activates automatically when OVH's own detection systems identify an attack on OVH-hosted infrastructure. The detection is done by OVH, not by the customer. This means the activation timing depends entirely on OVH's detection, not yours. If OVH's detection is slower than Flowtriq's, the scrubbing center activates later. OVH's detection is flow-based and takes longer than per-second kernel detection.
Cloudflare Magic Transit: Always-on BGP-based protection for IP prefixes. Traffic flows through Cloudflare's network continuously when Magic Transit is configured. This eliminates the activation lag (scrubbing is always on) but at the cost of routing all traffic through Cloudflare, with associated latency and pricing implications. For latency-sensitive applications like game servers or real-time training platforms, always-on proxy routing adds measurable delay that may be unacceptable.
Hetzner built-in DDoS protection: Hetzner provides automatic DDoS protection for hosted servers. Like OVH VAC, the detection and activation are done by Hetzner's systems, not the customer's. The customer does not control the detection threshold or the mitigation rule selection. For small-to-medium attacks within Hetzner's absorption capacity, this works transparently. For larger or more sophisticated attacks, customer-side detection and escalation control provide better outcomes.
The visibility problem with provider-managed detection: When your scrubbing provider handles detection and you have no independent detection layer, you have no visibility into attack events. You don't know when attacks occur, how large they were, which vectors were used, or whether they were successfully mitigated or whether your server experienced degradation before the scrubbing activated. You have no PCAP data, no incident timeline, no forensic evidence. For SLA-sensitive environments, the inability to demonstrate what happened and when is itself a significant business risk.
The layered model that closes the gap
The most effective architecture combines detection at the node level with scrubbing capacity at the cloud level. Each layer contributes something the other cannot:
- On-node detection (Flowtriq ftagent): Sub-second detection before the attack reaches peak volume. Automated on-node iptables rules that protect application processes. Attack classification and PCAP capture for forensics. Slack/PagerDuty alerts with full incident context.
- BGP FlowSpec at transit edge: Upstream rule that drops matching attack traffic before it reaches your network at all. Addresses the bandwidth saturation problem at the network level. Requires pre-configured BGP session with your transit provider.
- Cloud scrubbing: Absorbs high-volume attack traffic that FlowSpec alone might not fully address. Adds a second upstream filtering layer. Provides the capacity buffer for very large attacks.
In the Lorikeet Security incident, all three layers were active within 11 seconds of the attack starting. The on-node iptables rules fired at T+8s protecting application processes. BGP FlowSpec and cloud scrubbing were both activated by the engineer's single click at T+11s. The result: 48.3 Gbps of attack traffic was absorbed across all three layers before the Lorikeet uplink could saturate. Not one participant was affected.
The cloud scrubbing layer alone, activated manually 5 to 15 minutes into the attack, would have eventually stopped the traffic. But those 5 to 15 minutes of uplink saturation would have ended the live training session, triggered the SLA breach clause, and caused customer impact that could not be recovered after the fact. Detection in front of scrubbing turned a reactive capability into a proactive one.
What to look for in a detection-to-scrubbing integration
If you already use or are evaluating a scrubbing provider and want to add a detection layer in front of it, look for these integration capabilities:
- API-based activation: The detection system should be able to call your scrubbing provider's API to initiate diversion without human intervention. Manual activation eliminates the speed advantage of fast detection.
- Pre-configured BGP sessions: For FlowSpec integration, the BGP session to your transit provider (or to the scrubbing center) should be established before an attack occurs. Establishing BGP sessions under attack adds latency.
- Independent detection (not relying on the scrubbing provider's detection): Your detection system should fire independently, giving you your own timeline and forensic data regardless of what the scrubbing provider's systems report.
- Attack classification before activation: Knowing the attack vector before activating scrubbing allows you to configure the right scrubbing rules rather than absorbing all traffic indiscriminately. This matters for always-on scrubbing configurations where you want to filter attack patterns without re-routing legitimate traffic.
- Automated rule withdrawal: After the attack ends, the diversion should be automatically withdrawn to return to normal routing. Leaving scrubbing active after an attack adds unnecessary latency.
Add sub-second detection in front of your scrubbing provider
Flowtriq integrates with Path.net, OVH, Cloudflare Magic Transit, and custom BGP adapters. Detection to scrubbing activation in seconds, not minutes. Starting at $9.99/node/month.
Start Free Trial →No credit card required · 7-day free trial