What is cloud scrubbing? How DDoS scrubbing centers work

What is cloud scrubbing?

Cloud scrubbing (also called cloud-based DDoS scrubbing or traffic scrubbing) is a DDoS mitigation technique where attack traffic is redirected from your servers through geographically distributed third-party scrubbing centers. The scrubbing center filters out malicious packets, then forwards only legitimate traffic to your origin server.

The fundamental problem cloud scrubbing solves: a large-scale DDoS attack can generate hundreds of gigabits or terabits per second of traffic — far more than any single data center's upstream bandwidth. Your link saturates and your services go offline before you can do anything about it locally. Scrubbing centers have massive upstream capacity (20+ Tbps at major providers) and can absorb attacks that would overwhelm any individual infrastructure.

Unlike firewall rules or rate limiting applied at your server, cloud scrubbing works upstream — the attack traffic never reaches your data center. Your servers only receive the clean traffic that survived scrubbing.

How cloud scrubbing works: the traffic path

Here is the full sequence of events during an attack mitigated by cloud scrubbing:

1. Attack traffic targets your IP prefix

   A DDoS botnet begins flooding your servers. Traffic volume spikes well beyond your normal baseline — potentially hundreds of Gbps for volumetric attacks.

2. Detection triggers the diversion

   Either your detection system (like Flowtriq) or the scrubbing provider's own monitoring detects the attack. An alert is generated and the diversion mechanism is activated. For on-demand scrubbing, this means initiating a BGP route change. For always-on scrubbing, traffic already flows through the scrubbing center — no diversion needed.

3. BGP route change redirects your traffic

   The scrubbing provider announces your IP prefix from their ASN with a more specific route (e.g., your /24 instead of your ISP's /22). BGP routing globally converges toward the more specific route, so internet traffic destined for your IPs now flows to the scrubbing provider's network instead of your data center. BGP convergence typically takes 2–5 minutes to propagate globally.

4. Scrubbing center filters the traffic

   The scrubbing center applies a multi-layer filtering pipeline: volumetric rate limits drop obvious flood traffic; signature-based filters match known attack patterns (NTP amplification, SYN floods, UDP floods); behavioral analysis compares real-time traffic against your historical baseline; connection tracking drops packets from sources failing SYN cookies or TCP handshake validation. What remains is clean traffic.

5. Clean traffic is tunneled to your origin

   Filtered traffic is encapsulated in a GRE tunnel (or delivered over MPLS) and forwarded to your actual server. Your server receives only the clean traffic and is unaware of the attack occurring upstream.

6. Attack ends — normal routing restored

   When traffic normalizes, the scrubbing provider withdraws the more-specific BGP route announcement. BGP reconverges to your original route within minutes. Traffic flows directly to your data center again without the scrubbing overhead.

BGP diversion explained

BGP (Border Gateway Protocol) is the routing protocol that makes the internet work — it's how networks tell each other which IP addresses they can reach and how. BGP diversion exploits a fundamental BGP rule: more specific routes win.

If your ISP announces 203.0.113.0/22 (which includes your /24 203.0.113.64/24), all traffic to your /24 follows the /22 route to your ISP. Now if a scrubbing provider announces 203.0.113.64/24 from their network, every BGP router on the internet will prefer the more-specific /24 route. Traffic to your servers flows to the scrubbing center instead.

After scrubbing, clean traffic reaches your actual server via:

• GRE tunnel: The scrubbing provider encapsulates clean packets in a GRE header with your server as the destination. Your server decapsulates the GRE envelope and processes normal packets.
• MPLS circuit: Enterprise customers may use dedicated MPLS circuits for guaranteed bandwidth back to their data center.
• IP-in-IP tunnel: A lighter-weight alternative to GRE used by some providers.

For BGP diversion to work, you typically need to own your IP space (have your own ASN and your own /24 or larger prefix). If you use IP addresses assigned by your hosting provider, you can't redirect just your addresses without affecting their entire block. This is why BGP-based scrubbing is primarily used by enterprises, ISPs, and data center operators — not individual VPS users.

Anycast routing in CDN-based scrubbing

Services like Cloudflare use a different approach — anycast routing — rather than BGP diversion. With anycast:

• The same IP address (your protected IP) is announced from hundreds of data centers worldwide simultaneously
• BGP routing automatically sends each user to the geographically nearest Cloudflare node
• Attack traffic gets naturally distributed across all 310+ Cloudflare nodes globally rather than concentrating at one location
• Each node independently scrubs its share of the attack traffic

Anycast doesn't require you to own IP space. Cloudflare handles everything through DNS — your domain resolves to Cloudflare's anycast IP instead of your origin IP. This is why Cloudflare setup is as simple as a DNS change while Akamai Prolexic requires weeks of BGP configuration.

The tradeoff: anycast via CDN proxy only works for HTTP/HTTPS (TCP port 80/443). Game servers, VoIP (UDP), custom TCP applications, and raw IP traffic can't be protected by DNS-based proxying — those require BGP-level protection (Magic Transit, Prolexic, Path.net) or local detection tools.

On-demand vs always-on scrubbing

The two deployment modes for cloud scrubbing have different cost, latency, and protection profiles:

The on-demand model is the most common choice because it eliminates the always-on cost and latency penalty. The mitigation gap can be reduced by using an automated detection system that triggers the BGP diversion the moment traffic anomalies are detected — rather than waiting for human intervention or the scrubbing provider's own (often slower) monitoring to notice the attack.

Flowtriq detects attacks in under 1 second and automatically calls your scrubbing provider's API to initiate diversion. This eliminates the "detection delay" component of the mitigation gap, reducing unprotected exposure to the BGP convergence time only. See supported scrubbing providers.

How scrubbing centers filter attack traffic

Modern scrubbing centers run a multi-stage filtering pipeline. Traffic passes through each stage in order, with the most computationally expensive filters applied last (after cheap volumetric filters have already discarded the bulk of attack traffic):

Stage 1: Volumetric rate limiting

The first filter drops traffic that exceeds rate limits for individual source IPs or protocol types. A legitimate user sending 1 Gbps of UDP packets to your server is an attack, not normal behavior. Rate limiters cut this to acceptable levels immediately. This stage handles the majority of volumetric flood traffic.

Stage 2: Attack signature matching

Known attack patterns are matched against real-time traffic. NTP amplification attacks have characteristic source ports (UDP/123) with monlist response patterns. SSDP amplification uses UDP/1900. Memcached amplification uses UDP/11211 with unusually large response packets. Signature-based filters drop packets matching known amplification vectors regardless of rate.

Stage 3: Protocol validation

Packets that don't conform to protocol specifications are dropped. SYN packets with invalid TCP flags, IP fragments with inconsistent offset fields, and UDP packets with malformed headers are discarded. This catches a wide range of malformed-packet flood attacks and protocol exploitation attempts.

Stage 4: SYN cookies and TCP handshake validation

For TCP traffic, scrubbing centers use SYN cookies to validate that a connecting client can complete the TCP three-way handshake before forwarding the connection to your origin. Spoofed-source SYN flood attacks use forged source IPs that can't receive the SYN-ACK — they fail validation and never reach your server. Only verified handshakes pass through.

Stage 5: Behavioral analysis and anomaly detection

Traffic that passed earlier stages is compared against your historical traffic baseline. Sudden spikes in new connection rates, unusual geographic source distributions, or abnormal request patterns trigger behavioral filters. Advanced providers use ML models trained on your specific traffic profile to identify attack patterns that look legitimate in isolation.

Stage 6: Challenge mechanisms (HTTP layer)

For HTTP/HTTPS traffic, the scrubbing center can issue JavaScript challenges or CAPTCHA challenges to sources exhibiting suspicious behavior. Bots typically can't execute JavaScript or solve CAPTCHAs — they fail the challenge and are blocked. Real browsers pass automatically. This is effective against application-layer floods that use legitimate HTTP request patterns.

Major cloud scrubbing providers compared

What cloud scrubbing doesn't protect against

Cloud scrubbing is highly effective at absorbing volumetric attacks but has important blind spots:

• Low-and-slow application attacks. Slowloris, slow POST, and other attacks that use legitimate connection rates but exhaust server resources are hard for scrubbing centers to distinguish from real traffic. They require application-layer analysis close to the origin.
• Your own blind spots. Scrubbing only protects the prefixes you enroll. Services on IPs outside your scrubbing plan are completely unprotected. Multi-homed deployments, dedicated game server IPs, and development infrastructure are common gaps.
• On-demand convergence gap. For on-demand scrubbing, the 2–10 minutes while BGP converges is fully exposed. A short burst attack can cause all its damage and end before scrubbing even activates. Using sub-second local detection (like Flowtriq) to trigger the API call minimizes this gap.
• Insider visibility. Cloud scrubbing is completely opaque to your team — you see that traffic was mitigated, not what the attack looked like in detail. Attack forensics, per-second packet captures, and protocol-level evidence require server-side detection tools.
• Legitimate traffic collateral. Aggressive scrubbing filters can incorrectly block legitimate traffic, especially during novel attack patterns that resemble real traffic. Always-on providers tune thresholds for your specific traffic, but false positives are more common with generic scrubbing profiles.

Cloud scrubbing + local detection: the complete stack

The most resilient DDoS protection combines cloud scrubbing with server-side detection:

• Cloud scrubbing handles volumetric attacks — the floods that saturate links. It acts as your upstream capacity multiplier.
• Server-side detection (like Flowtriq) provides per-second visibility into attack traffic at the kernel level, detects attacks before they saturate your upstream, automatically triggers cloud scrubbing via API, captures PCAP evidence for forensics, and monitors services that aren't covered by your scrubbing plan.

Used together, the detection layer solves the on-demand convergence gap, and the scrubbing layer handles attacks that exceed your local mitigation capacity. Neither is redundant — they protect different things.

Frequently asked questions

Related articles