Cloud-Based DDoS Mitigation: How It Works and When You Need It

Volumetric DDoS attacks now routinely exceed 1 Tbps. No single server, and no single data center, can absorb that kind of traffic on its own. That is where cloud-based DDoS mitigation comes in. By routing attack traffic through globally distributed scrubbing centers, cloud mitigation can absorb and filter massive floods before they ever reach your infrastructure.

But cloud scrubbing is only half the equation. Without fast, accurate detection at the origin, you are either paying for always-on filtering you might not need, or you are scrambling to activate on-demand protection while your servers are already drowning. This guide covers how cloud-based mitigation works, what the tradeoffs are, and how to build a detection layer that ties it all together.

What Is Cloud-Based DDoS Mitigation?

Cloud-based DDoS mitigation is a service where your network traffic is routed through a third-party provider's infrastructure during an attack. The provider's scrubbing centers analyze and filter the traffic, dropping malicious packets and forwarding only clean traffic back to your origin servers.

The core idea is simple: instead of trying to absorb a multi-hundred-gigabit flood on your own network, you offload the problem to a provider with enough global capacity to handle it. Major scrubbing providers maintain networks ranging from 5 Tbps to over 300 Tbps of total capacity spread across dozens of points of presence worldwide.

Key Components of Cloud Scrubbing

• Scrubbing centers - Geographically distributed data centers equipped with specialized hardware and software that inspect packets at line rate and filter out attack traffic
• Traffic diversion - Mechanisms (usually BGP or DNS) that redirect your inbound traffic through the scrubbing infrastructure
• Clean pipe - The return path that delivers only legitimate traffic back to your origin, typically over GRE tunnels or direct interconnects
• Detection and signaling - The system that identifies an attack is happening and triggers the diversion process

How Traffic Diversion Works

Getting your traffic to flow through a scrubbing center requires some form of network-level redirection. There are three primary methods, each with different tradeoffs in speed, complexity, and control.

BGP Diversion

BGP (Border Gateway Protocol) diversion is the most common method for infrastructure-level cloud mitigation. Your scrubbing provider advertises your IP prefixes from their network, causing upstream routers across the internet to send traffic destined for your IPs to the scrubbing centers instead of directly to your network.

The process works like this:

1. An attack is detected on your network
2. A BGP announcement is made from the scrubbing provider's ASN for your IP prefix
3. Internet routers globally update their routing tables to direct traffic for your IPs through the scrubbing network
4. The scrubbing centers filter the traffic and forward clean packets to your origin via GRE tunnels or private interconnects
5. When the attack subsides, the BGP announcement is withdrawn and traffic flows directly again

BGP diversion typically takes 2-5 minutes to fully propagate globally. During that window, your origin is still receiving the full attack. For always-on configurations, BGP is pre-announced so there is no propagation delay, but all traffic always flows through the scrubbing infrastructure.

GRE Tunnels

Generic Routing Encapsulation (GRE) tunnels are the most common clean-pipe mechanism for returning scrubbed traffic to your origin. After the scrubbing center filters out attack packets, it encapsulates the clean traffic in GRE and sends it through a tunnel to your network edge.

GRE tunnels add a small amount of overhead (24 bytes per packet) and typically add 1-3ms of latency depending on the geographic distance between the scrubbing center and your origin. For most applications this is negligible, but for latency-sensitive workloads like game servers or high-frequency trading, it is worth measuring.

DNS-Based Diversion

For web applications, DNS-based diversion is an alternative approach. Instead of routing IP-level traffic through scrubbing centers, you point your DNS records to the mitigation provider's anycast network. This is how services like Cloudflare and AWS CloudFront operate by default.

DNS diversion is simpler to set up but has limitations. It only protects services reachable via DNS names, and it does not help with attacks targeting your IP addresses directly. It also depends on DNS TTLs for failover speed, which can range from seconds to hours depending on your configuration.

Always-On vs. On-Demand Protection

One of the biggest decisions in cloud-based DDoS mitigation is whether to run always-on or on-demand protection. Each approach has distinct advantages.

Always-On Protection

With always-on (or "always routed") protection, all your traffic flows through the scrubbing infrastructure at all times, whether or not an attack is happening.

• Pros: Zero activation delay. Attacks are mitigated instantly because the scrubbing is already in the path. No detection-to-activation gap.
• Cons: Higher cost since you are paying for scrubbing capacity continuously. Added latency on all traffic. Dependency on the provider's uptime for all connectivity.

Always-on makes sense for organizations that are attacked frequently, that cannot tolerate any downtime during activation, or that serve latency-tolerant workloads where the extra hop through a scrubbing center is acceptable.

On-Demand Protection

On-demand protection keeps traffic flowing directly to your network during normal operation. When an attack is detected, the scrubbing diversion is activated, and traffic begins flowing through the scrubbing centers.

• Pros: Lower cost during peacetime. No added latency when there is no attack. No dependency on the provider for normal operations.
• Cons: Activation delay of 2-10 minutes depending on the diversion method. Your network must survive the attack for the duration of the activation window. Requires a reliable detection and signaling mechanism.

The critical factor for on-demand cloud mitigation is detection speed. The faster you detect an attack and signal your scrubbing provider, the shorter the window your infrastructure is exposed. A detection gap measured in minutes can mean the difference between a brief blip and a full outage.

The Detection Gap Problem

Here is the fundamental challenge with on-demand cloud scrubbing: it only works if something triggers it. And many organizations rely on manual processes or slow detection methods that leave a dangerous gap.

Consider a typical scenario without proper detection:

1. A volumetric attack begins at 14:00:00
2. Servers start dropping connections at 14:00:15
3. Monitoring alerts fire based on failed health checks at 14:02:00
4. An engineer investigates and confirms it is a DDoS attack at 14:08:00
5. The engineer contacts the scrubbing provider or triggers activation at 14:10:00
6. BGP propagation completes at 14:14:00

That is a 14-minute window of downtime. For many businesses, 14 minutes of outage is devastating. And that assumes the engineer is available immediately, which at 3 AM on a Saturday is far from guaranteed.

Automated Detection and Signaling

The solution is an automated detection layer that monitors traffic at the source and triggers cloud scrubbing programmatically the moment an attack is identified.

This is where Flowtriq fits into a cloud-based mitigation architecture. Flowtriq agents run on each node in your infrastructure, monitoring per-second packet rates at the kernel level. When traffic deviates from dynamic baselines, Flowtriq classifies the attack type within one second and can automatically trigger your cloud scrubbing provider via API, BGP FlowSpec, or webhook.

The revised timeline with Flowtriq in place:

1. A volumetric attack begins at 14:00:00
2. Flowtriq detects the anomaly at 14:00:01
3. Auto-mitigation triggers a cloud scrubbing activation via API at 14:00:02
4. BGP propagation completes at 14:03:00

That is a 3-minute window instead of 14 minutes, and no human intervention was required. During those 3 minutes, Flowtriq's local auto-mitigation (iptables/nftables rules) can also absorb smaller attacks or reduce the impact until cloud scrubbing is fully active.

Integration with Cloud Scrubbing Providers

Most major cloud scrubbing providers offer APIs or signaling mechanisms for automated activation. Here is how Flowtriq integrates with the most common approaches.

BGP FlowSpec Signaling

BGP FlowSpec allows Flowtriq to announce granular filtering rules to your upstream provider. Instead of diverting all traffic, FlowSpec rules can target specific source IPs, protocols, or port ranges. This is faster than full BGP diversion and more surgical.

# Example FlowSpec rule triggered by Flowtriq
# Drop UDP fragments from specific source range
match: dst 203.0.113.0/24
       src 192.0.2.0/24
       protocol udp
       fragment is-fragment
action: discard

API-Based Activation

Providers like Akamai Prolexic, Neustar (now TransUnion), and Imperva offer REST APIs for activating scrubbing on demand. Flowtriq's webhook auto-mitigation action can call these APIs the moment an attack is detected, passing along attack details like type, volume, and targeted IPs.

RTBH (Remotely Triggered Black Hole)

For attacks that target a specific IP and threaten to saturate your upstream links, RTBH allows Flowtriq to signal your upstream provider to black hole the targeted IP. This sacrifices the targeted service but protects the rest of your network. It is a last-resort escalation that Flowtriq can trigger automatically based on configurable thresholds.

Choosing a Cloud Scrubbing Provider

When evaluating cloud scrubbing providers, focus on these criteria:

• Scrubbing capacity - Total network capacity in Tbps. Ensure it significantly exceeds the largest attacks you might face.
• Geographic distribution - Scrubbing centers should be close to your users to minimize added latency.
• Activation speed - How quickly can diversion be activated? Look for providers with API-driven activation and fast BGP convergence.
• Clean-pipe options - GRE tunnels, direct cross-connects, or cloud interconnects. More options mean more flexibility.
• API quality - A well-documented API enables automation. Providers without APIs require manual activation, which defeats the purpose of fast detection.
• Attack visibility - Does the provider give you detailed logs and analytics about mitigated attacks? This data is critical for post-incident analysis.
• SLA guarantees - Time-to-mitigate SLAs, uptime guarantees, and financial credits for failures.
• Pricing model - Per-Mbps clean traffic, per-attack, or flat monthly. Understand your cost exposure during a sustained attack.

Layered Defense: Detection + Local Mitigation + Cloud Scrubbing

The most effective DDoS protection architecture uses three layers working together:

Layer 1: Detection

Per-second traffic monitoring at every node. Flowtriq's lightweight agents provide 1-second detection with automatic attack classification across 8 attack types. Dynamic baselines mean you do not need to manually configure thresholds for every server.

Layer 2: Local Mitigation

Automated iptables/nftables rules that can drop known-bad traffic at the kernel level. This handles smaller attacks entirely and buys time during larger attacks while cloud scrubbing activates. Flowtriq can push these rules automatically based on attack classification.

Layer 3: Cloud Scrubbing

For volumetric attacks that exceed your local capacity, cloud scrubbing absorbs the flood. The key is that Layer 1 (detection) triggers Layer 3 (cloud scrubbing) automatically, with Layer 2 (local mitigation) providing coverage during the activation window.

This layered approach gives you the cost benefits of on-demand cloud scrubbing with minimal exposure during the activation window. You are not paying for always-on scrubbing when there is no attack, but you are not relying on human intervention to activate protection either.

Common Mistakes to Avoid

Relying Solely on Cloud Scrubbing Without Origin Detection

If your only detection method is the cloud scrubbing provider's monitoring, you have a blind spot. Most providers monitor aggregated traffic flows and may take minutes to detect anomalies, especially for application-layer attacks that do not produce obvious volume spikes. Origin-level detection with tools like Flowtriq catches attacks at the source within seconds.

Ignoring the Return Path

GRE tunnels have MTU limitations. If you do not account for the GRE overhead (24 bytes), you can end up with fragmentation issues that cause mysterious connectivity problems for clean traffic. Always test your GRE tunnels with full-size packets before you need them in an emergency.

No Testing Under Load

Many organizations set up cloud scrubbing and never test the full activation and diversion process. When a real attack hits, they discover configuration issues, stale BGP sessions, or expired API credentials. Run tabletop exercises and controlled diversion tests quarterly.

Static Thresholds for Activation

Triggering cloud scrubbing based on a fixed PPS or Mbps threshold leads to either premature activation (wasting money) or late activation (suffering downtime). Flowtriq's dynamic baselines learn what normal looks like for each node and detect deviations proportional to actual traffic patterns, making activation decisions smarter and more reliable.

When Do You Need Cloud-Based Mitigation?

Not every organization needs a cloud scrubbing service. Here is a quick framework:

• You probably need it if: You host critical infrastructure on your own IP space, you have been targeted by attacks exceeding 10 Gbps, or you are in a frequently-targeted industry (gaming, finance, SaaS).
• You might not need it if: You are behind a CDN like Cloudflare that already provides DDoS mitigation, or you exclusively run on a major cloud provider with built-in protection (AWS Shield, Azure DDoS Protection).
• You always need detection: Regardless of your scrubbing setup, origin-level detection is essential. CDNs and cloud providers can be bypassed. Direct-to-IP attacks skip DNS-based protections entirely. Flowtriq gives you visibility at the source no matter what else is in your stack.

Back to Blog

Related Articles