What Is Cloud Scrubbing?
Cloud scrubbing is a DDoS mitigation technique where inbound traffic is diverted away from your network to a third-party scrubbing center. The scrubbing center inspects every packet, filters out attack traffic using deep packet inspection and behavioral analysis, and forwards only clean traffic back to your origin infrastructure.
The diversion typically happens via BGP: during an attack, you (or your detection system) announce a more-specific route that attracts traffic to the scrubbing provider's network. The provider absorbs the volumetric flood with their massive edge capacity, cleans it, and delivers legitimate traffic back to you through a GRE tunnel, PNI (Private Network Interconnect), or direct cross-connect.
When do you need it?
Cloud scrubbing becomes necessary when attack volume exceeds your local mitigation capacity. If your upstream transit is 10 Gbps and you are taking a 200 Gbps UDP flood, no amount of local filtering, FlowSpec, or RTBH will help - the traffic saturates your links before it ever reaches your routers. Scrubbing providers maintain edge capacity measured in tens of terabits per second, absorbing attacks that would flatten most networks.
- Volumetric attacks beyond link capacity: Amplification floods (DNS, NTP, CLDAP, memcached) routinely exceed 100 Gbps.
- Multi-vector attacks: Sophisticated attackers combine volumetric floods with application-layer attacks. Scrubbers handle both.
- Target IP must stay online: Unlike RTBH (which blackholes the target), scrubbing keeps your services reachable.
- Compliance requirements: Some industries mandate always-on DDoS protection with contractual SLAs.
Major Providers Compared
The cloud scrubbing market ranges from hyperscaler platforms with global anycast networks to specialized providers offering BGP-based on-demand scrubbing. Each has distinct strengths depending on your architecture, budget, and operational requirements.
Provider Capacity Diversion Method Pricing Model Contract ───────────────────────────────────────────────────────────────────────────────────────────── Cloudflare Magic Transit 321+ Tbps Anycast BGP Per-Mbps committed Annual Akamai Prolexic 20+ Tbps BGP / DNS / Proxy Per-Mbps + surge Annual AWS Shield Advanced Multi-Tbps Automatic (AWS infra) $3,000/mo + DT costs Annual Path.net 12+ Tbps BGP (GRE return) Per-Mbps or flat Monthly/Annual OVH VAC 17+ Tbps Automatic (OVH nets) Included with hosting N/A (bundled) Voxility 2+ Tbps BGP (GRE return) Per-Mbps Monthly Hetzner DDoS Protection ~3 Tbps Automatic (Hetzner) Included with hosting N/A (bundled)
Cloudflare Magic Transit
Cloudflare's Magic Transit puts your IP ranges behind their global anycast network (321+ Tbps capacity across 330+ cities). Traffic flows through Cloudflare at all times (always-on mode) or only during attacks (on-demand via BGP). Clean traffic returns via Anycast GRE or IPsec tunnels, or Cloudflare Network Interconnect (CNI) for dedicated connectivity.
Strengths: unmatched global capacity, low-latency anycast scrubbing, integrated WAF/bot management. Weaknesses: pricing favors committed bandwidth, requires /24 or larger prefix for BGP announcement, annual contracts are typical.
Akamai Prolexic
Prolexic is the legacy enterprise scrubbing platform (acquired via Prolexic Technologies in 2014). It operates 36+ scrubbing centers with 20+ Tbps of dedicated scrubbing capacity. Diversion is BGP-based with GRE/IPsec return tunnels. Prolexic includes a 24/7 SOC (SOCC) that actively manages mitigation during attacks.
Strengths: managed service with dedicated SOC support, deep application-layer scrubbing, SLA-backed response times. Weaknesses: premium pricing, complex onboarding, annual commitments with bandwidth overages billed separately.
AWS Shield Advanced
AWS Shield Advanced provides DDoS protection for resources running on AWS (EC2, ELB, CloudFront, Global Accelerator, Route 53). It automatically detects and mitigates attacks using AWS's global edge network. The $3,000/month base fee includes a DDoS cost protection guarantee - AWS credits you for scaling charges caused by DDoS attacks.
Strengths: zero-config for AWS workloads, automatic detection and mitigation, DDoS cost protection, access to AWS DDoS Response Team. Weaknesses: only protects AWS-hosted resources, $3,000/month base cost plus data transfer, no help for on-premises or hybrid infrastructure.
Path.net
Path.net offers BGP-based scrubbing with 12+ Tbps capacity across multiple global PoPs. They specialize in gaming, hosting, and infrastructure providers who need flexible BGP integration. Traffic diversion is via standard BGP announcements with clean traffic returned over GRE tunnels.
Strengths: flexible BGP integration, competitive per-Mbps pricing, monthly contracts available, responsive support for smaller operators. Weaknesses: smaller global footprint compared to hyperscalers, capacity may not match the largest providers.
OVH VAC
OVH's VAC (anti-DDoS infrastructure) is bundled with all OVH dedicated servers and VPS. The system uses 17+ Tbps of edge filtering capacity to automatically detect and mitigate attacks with no manual intervention required. The VAC pipeline applies progressive filtering: network firewall, then hardware mitigation (Tilera/Arista), then Shield (application-layer scrubbing).
Strengths: included at no extra cost for OVH customers, fully automatic, large capacity for a bundled solution. Weaknesses: only protects OVH-hosted IPs, limited customization of filtering rules, no option for non-OVH infrastructure.
Voxility
Voxility provides BGP-based DDoS scrubbing with infrastructure in European and US data centers. They offer on-demand scrubbing with GRE tunnel return, positioned as a cost-effective option for hosting providers and networks that need supplemental scrubbing capacity.
Strengths: straightforward BGP integration, monthly billing, no long-term contracts required, European coverage. Weaknesses: smaller total capacity compared to hyperscalers, fewer global PoPs.
Hetzner DDoS Protection
Hetzner includes automatic DDoS protection for all servers hosted on their network. The system detects volumetric attacks and routes traffic through scrubbing appliances within Hetzner's data centers. The protection handles common amplification vectors and SYN floods automatically.
Strengths: free with Hetzner hosting, automatic with zero configuration, effective against common volumetric attacks. Weaknesses: only protects Hetzner-hosted IPs, limited capacity compared to dedicated scrubbing providers, no external BGP integration.
Key Evaluation Criteria
Choosing a scrubbing provider is not just about picking the biggest name. The right choice depends on your network architecture, traffic profile, budget, and operational requirements. Here are the criteria that matter most.
1. Scrubbing capacity (Tbps)
The provider's total scrubbing capacity determines the largest attack they can absorb without degradation. Look for providers whose capacity significantly exceeds the largest attacks in your threat model. For most networks, 10+ Tbps is a reasonable floor. Remember that provider-stated capacity is shared across all their customers - during a large-scale attack campaign, multiple customers may be under attack simultaneously.
2. Latency impact
Scrubbing adds latency because traffic must travel to the scrubbing center, be processed, and then forwarded to your origin. Providers with anycast networks (Cloudflare) minimize this by scrubbing at the nearest edge PoP. Providers with centralized scrubbing centers (Prolexic, Path.net) add the round-trip penalty to the scrubbing center. For latency-sensitive applications (gaming, real-time communication, trading), measure the expected added latency with each provider before committing.
3. BGP requirements
Most scrubbing providers require you to announce IP space via BGP. This means you need your own ASN and a /24 or larger prefix (the minimum routable prefix on the public internet). If you are using provider-assigned IPs (e.g., IPs assigned by your hosting provider), BGP-based scrubbing may not be an option unless the hosting provider cooperates with the scrubber to accept the more-specific announcement.
4. Pricing model
Pricing varies significantly across providers:
- Committed bandwidth: You pay for a committed clean traffic rate (e.g., 500 Mbps). Overages are billed per Mbps. Common with Cloudflare, Akamai, Path.net.
- Flat monthly: Fixed price regardless of attack volume or clean traffic. Less common but available from some providers for smaller deployments.
- Bundled: Included with hosting (OVH, Hetzner). No separate cost, but no protection for external infrastructure.
- Platform fee + data transfer: AWS Shield Advanced's model ($3,000/month + standard data transfer costs).
5. Contract terms
Enterprise scrubbing providers (Cloudflare, Akamai) typically require annual contracts with committed minimums. Smaller providers (Voxility, Path.net) often offer monthly billing. Bundled solutions (OVH, Hetzner) have no separate contract. If you are unsure about long-term needs, start with a monthly provider to validate the integration before signing an annual commitment.
6. Return path options
After scrubbing, clean traffic must reach your origin. Common return methods:
- GRE tunnel: Most common. The scrubber encapsulates clean traffic in GRE and sends it to your origin IP. Adds overhead (24 bytes per packet) but works universally.
- IPsec tunnel: Encrypted return path. Higher overhead than GRE but required for compliance in some environments.
- Direct cross-connect / PNI: Physical or virtual interconnect at a colocation facility. Lowest latency and no encapsulation overhead, but requires geographic proximity.
- Anycast return: Used by Cloudflare - clean traffic exits from the nearest Cloudflare PoP via a tunnel to your origin.
GRE Tunnels vs BGP-Based Diversion
These are two different parts of the scrubbing pipeline, and they often get conflated. BGP diversion is how traffic gets to the scrubber. GRE tunnels are how clean traffic gets back to you. Understanding both is critical for proper integration.
BGP-based diversion (inbound)
During an attack, you announce your protected prefix (e.g., 198.51.100.0/24) via BGP to the scrubbing provider. The scrubber re-advertises the prefix from their network, attracting traffic to their scrubbing infrastructure. Because the scrubber's announcement is more specific or has a shorter AS path, global traffic routes to the scrubber instead of directly to you.
Normal traffic flow: Internet → Your upstream → Your network → Your servers During scrubbing (BGP diversion): Internet → Scrubber's edge → Scrubbing pipeline → GRE tunnel → Your servers
GRE tunnel (return path)
Once traffic is scrubbed, the clean packets are encapsulated in GRE (Generic Routing Encapsulation) and sent to your origin IP over the public internet or a private interconnect. Your router decapsulates the GRE packets and delivers them to the target server.
# Example: GRE tunnel configuration on your router (Linux) ip tunnel add scrub0 mode gre remote 203.0.113.1 local 198.51.100.1 ttl 255 ip addr add 10.255.255.2/30 dev scrub0 ip link set scrub0 up # Route clean traffic from scrubber through the GRE interface ip route add 10.255.255.0/30 dev scrub0
GRE adds 24 bytes of overhead per packet, which reduces your effective MTU. Set the tunnel MTU to 1476 (1500 minus 24) to avoid fragmentation issues. If your scrubbing provider uses IPsec over GRE, the overhead increases further and the MTU should be adjusted accordingly.
How Detection and Scrubbing Work Together
A scrubbing provider without detection is a fire extinguisher locked in a cabinet. Someone has to notice the fire, find the key, and unlock the cabinet before it can help. The detection layer is what turns cloud scrubbing from a manual, reactive process into an automated defense.
The detection-to-scrubbing workflow follows a clear sequence:
- Detect: Your local monitoring system (Flowtriq, NetFlow collector, sFlow analyzer) identifies anomalous traffic patterns that indicate a DDoS attack.
- Classify: The detection system determines the attack type, volume, and whether local mitigation can handle it.
- Decide: If attack volume exceeds local capacity, the system decides to escalate to cloud scrubbing.
- Divert: The detection system triggers a BGP announcement that routes traffic to the scrubbing provider.
- Scrub: The provider filters attack traffic and returns clean traffic via GRE/IPsec tunnel.
- Monitor: The detection system continues monitoring. When attack traffic subsides, it withdraws the BGP announcement and traffic returns to the normal path.
Without automated detection, steps 1-4 depend on a human noticing the attack, assessing it, and manually triggering the BGP announcement. This delay, often 10-30 minutes for well-staffed NOCs and hours for teams without 24/7 coverage, is the window during which your services are down.
Flowtriq's Auto-Escalation to Cloud Scrubbing
Flowtriq implements cloud scrubbing as Tier 4 in its automatic escalation chain. When lower-tier mitigations (host-level filtering, FlowSpec, RTBH) are insufficient or inappropriate, Flowtriq escalates to cloud scrubbing without human intervention.
The escalation sequence:
- Tier 1 - Host-level filtering: iptables/nftables rules on the target node. Handles small attacks within server capacity.
- Tier 2 - BGP FlowSpec: Surgical filtering rules injected to upstream routers. Stops identifiable attack patterns at the network edge.
- Tier 3 - BGP blackhole (RTBH): Full blackhole of the target IP when FlowSpec cannot contain the attack.
- Tier 4 - Cloud scrubbing: BGP announcement diverts traffic to scrubbing provider. Clean traffic returned via GRE tunnel.
How the Tier 4 trigger works
Flowtriq triggers Tier 4 cloud scrubbing when any of these conditions are met:
- Attack volume exceeds the configured threshold (e.g., > 50 Mpps or > 10 Gbps).
- The attack is multi-vector and lower tiers cannot fully mitigate it.
- RTBH is active but the target service is business-critical and cannot remain offline.
- The escalation policy is configured to prefer scrubbing over blackhole for specific prefixes.
When triggered, Flowtriq executes the following sequence automatically:
1. Flowtriq detects attack (1-2 seconds) 2. Attack classified, Tier 4 threshold exceeded (0.5 seconds) 3. BGP adapter announces protected prefix to (2-5 seconds) scrubbing provider with configured communities 4. Global routing converges to scrubber (30-90 seconds) 5. Scrubber filters attack traffic (immediate) 6. Clean traffic returned via GRE tunnel (immediate) 7. Flowtriq monitors, auto-withdraws when (configurable attack subsides cooldown)
Total time from attack detection to scrubbing active: under 2 minutes. Compare this to the 10-30 minute manual response time at a well-staffed NOC.
Custom BGP Adapter Configuration
Flowtriq communicates with your scrubbing provider via a BGP adapter - a local BGP speaker (ExaBGP or GoBGP) that Flowtriq controls to announce or withdraw prefixes on demand. The adapter configuration tells Flowtriq how to reach the scrubbing provider's BGP session and what communities to attach.
ExaBGP adapter example
# /etc/flowtriq/bgp-adapter.yml
adapter: exabgp
exabgp_binary: /usr/local/bin/exabgp
exabgp_api: /var/run/exabgp.sock
neighbors:
- name: cloudflare-magic-transit
remote_ip: 203.0.113.1
remote_as: 13335
local_ip: 198.51.100.1
local_as: 65001
multihop: 2
password: "bgp-session-password"
communities:
- "13335:20000" # Cloudflare scrubbing community
prefixes:
- 198.51.100.0/24
- name: pathnet-scrubbing
remote_ip: 203.0.113.5
remote_as: 396998
local_ip: 198.51.100.1
local_as: 65001
communities:
- "396998:100" # Path.net scrubbing community
prefixes:
- 198.51.100.0/24
GoBGP adapter example
# /etc/flowtriq/bgp-adapter.yml
adapter: gobgp
gobgp_api: "127.0.0.1:50051"
neighbors:
- name: akamai-prolexic
remote_ip: 203.0.113.10
remote_as: 32787
local_ip: 198.51.100.1
local_as: 65001
communities:
- "32787:5000" # Prolexic scrubbing community
prefixes:
- 198.51.100.0/24
The adapter configuration is managed in the Flowtriq dashboard under Mitigation > BGP Adapters. You can configure multiple adapters to support failover between scrubbing providers or to use different providers for different prefixes.
Provider-specific BGP communities
Each scrubbing provider uses different BGP community values to control scrubbing behavior. These communities tell the provider how to handle your traffic. Flowtriq's adapter attaches the correct communities automatically based on your configuration:
Provider Community Example Meaning ───────────────────────────────────────────────────────────── Cloudflare Magic Transit 13335:20000 Enable scrubbing Akamai Prolexic 32787:5000 Divert to scrubbing Path.net 396998:100 On-demand scrubbing Voxility 3223:666 Activate DDoS filter
Always verify community values with your provider. The examples above are illustrative. Providers update their community schemas periodically, and using incorrect communities can result in traffic being dropped instead of scrubbed. Request the current community reference from your provider during onboarding.
Avoiding Vendor Lock-In
One of the biggest risks with cloud scrubbing is vendor lock-in. If your detection system is tightly coupled to a single scrubbing provider, switching providers requires re-engineering your mitigation pipeline. This gives the incumbent provider pricing leverage and leaves you vulnerable if their service degrades.
Flowtriq solves this by design. The BGP adapter layer abstracts the scrubbing provider entirely. Flowtriq does not care whether traffic is being diverted to Cloudflare, Akamai, Path.net, Voxility, or a custom in-house scrubbing center. It speaks standard BGP and attaches the communities you configure.
This means you can:
- Switch providers by updating the adapter configuration - no code changes, no re-integration.
- Use multiple providers simultaneously for different prefixes or as primary/failover pairs.
- Test new providers by adding them as a secondary adapter and routing a test prefix through them during a maintenance window.
- Negotiate better pricing because you have credible alternatives that require zero engineering effort to activate.
- Self-scrub by pointing the adapter at your own scrubbing infrastructure if you outgrow external providers.
Your detection layer should never be owned by your scrubbing provider. If your scrubber also runs your detection, they control when (and whether) scrubbing activates - and you cannot leave without losing both detection and mitigation. Flowtriq keeps detection independent so you always have the option to switch scrubbing providers without disruption.
Cost Analysis: 10-Node vs 100-Node Deployment
Understanding total cost requires accounting for both the detection layer (Flowtriq) and the scrubbing layer (your chosen provider). Here is a realistic breakdown for two common deployment sizes.
10-node deployment
Component Monthly Annual ────────────────────────────────────────────────────────────── Flowtriq detection (10 nodes) Monthly billing: 10 x $9.99 $99.90 — Annual billing: 10 x $7.99 — $959.00 Scrubbing provider (examples): Bundled (OVH/Hetzner) $0.00 $0.00 Voxility (100 Mbps committed) ~$500 ~$6,000 Path.net (200 Mbps committed) ~$800 ~$9,600 Cloudflare Magic Transit Custom quote Custom quote Total range (annual billing): With bundled scrubbing $79.92/mo $959/yr With Voxility $579.92/mo ~$6,959/yr With Path.net $879.92/mo ~$10,559/yr
100-node deployment
Component Monthly Annual ────────────────────────────────────────────────────────────── Flowtriq detection (100 nodes) Monthly billing: 100 x $9.99 $999.00 — Annual billing: 100 x $7.99 — $9,588.00 Scrubbing provider (examples): Bundled (OVH/Hetzner) $0.00 $0.00 Voxility (1 Gbps committed) ~$2,500 ~$30,000 Path.net (2 Gbps committed) ~$4,000 ~$48,000 Akamai Prolexic (2 Gbps) ~$8,000 ~$96,000 AWS Shield Advanced $3,000+DT $36,000+DT Total range (annual billing): With bundled scrubbing $799.00/mo $9,588/yr With Voxility $3,299/mo ~$39,588/yr With Path.net $4,799/mo ~$57,588/yr With Akamai Prolexic $8,799/mo ~$105,588/yr
Flowtriq's detection cost scales linearly at $7.99/node/year (annual) or $9.99/node/month. This is independent of your scrubbing provider choice. The scrubbing cost depends on your committed bandwidth, provider, and contract terms. Many teams start with bundled scrubbing (OVH VAC, Hetzner) and upgrade to a dedicated provider as they scale.
Making the Decision
There is no single best scrubbing provider. The right choice depends on where your infrastructure lives, how much latency you can tolerate, and what you are willing to spend. Here is a decision framework:
- All infrastructure on OVH or Hetzner? Use their bundled protection. It is free and automatic. Add Flowtriq for detection, alerting, and forensics - the bundled scrubbing handles mitigation.
- Own ASN with BGP capability? Path.net or Voxility for cost-effective on-demand scrubbing with monthly billing. Cloudflare Magic Transit or Akamai Prolexic for enterprise-grade always-on protection.
- AWS-only workloads? AWS Shield Advanced is the path of least resistance. No BGP required, automatic detection and mitigation, and DDoS cost protection.
- Multi-cloud or hybrid? Cloudflare Magic Transit offers the broadest coverage with anycast scrubbing. Pair it with Flowtriq for independent detection and automated BGP diversion.
- Budget-constrained? Start with Flowtriq detection ($9.99/node/month) and bundled hosting protection. Upgrade to a dedicated scrubber when your threat model demands it.
Regardless of which provider you choose, keeping your detection layer independent is critical. Flowtriq monitors your traffic, detects attacks within seconds, and triggers the BGP diversion to your scrubber of choice - no vendor lock-in, no manual intervention, no 3 AM pages to the on-call engineer.
Get started with a free 7-day trial and connect Flowtriq to your existing scrubbing provider in minutes.
Back to Blog