On-Prem DDoS Mitigation vs Cloud Scrubbing: How to Choose

On-prem DDoS mitigation vs cloud scrubbing comes down to one question: can your own upstream links carry the attack traffic to your filter? If yes, an on-prem filter is cheap, fast and keeps latency unchanged. If no, you need to clean traffic upstream of your links, which means cloud scrubbing delivered over a BGP/GRE tunnel. Most networks end up with a hybrid of both.

This article compares the two models on capacity, cost, latency and operations, then shows how to build a hybrid design with flow-based detection, RTBH, FlowSpec and a DDoS tunnel.

The core difference: where the attack is dropped

On-prem mitigation filters traffic inside your network: a firewall or filtering appliance, ACLs on edge routers, or FlowSpec rules pushed to your own routers. Attack traffic has already crossed your transit and peering links by the time it is dropped.

Cloud scrubbing moves the drop point outside your network. Your prefixes are announced from the scrubbing provider, attack traffic lands on their edge, and only clean traffic is delivered back to you, typically over a GRE tunnel.

Everything else (capacity, cost, latency) follows from that single difference.

Capacity: your smallest pipe is the limit

An on-prem filter can only process what reaches it. The real ceiling is therefore the smaller of:

• the filter's forwarding/inspection capability, and
• the capacity of your transit and IX links (per link, not in aggregate, because attacks often arrive over one upstream).

A common mistake is sizing the appliance and ignoring link saturation. If an upstream port is full, legitimate packets are dropped before your filter sees them, and the filter cannot help.

Cloud scrubbing shifts that ceiling to the provider's edge. The question to ask is not just "how big is it?" but "where does it ingest, and how is attack traffic spread across its links?"

Practical rule: on-prem is good for attacks that are well below your smallest upstream's headroom, plus application-aware filtering. Cloud is for attacks that could fill a link.

Cost model

Without quoting prices, the cost structures differ in shape:

If you are attacked rarely and by small floods, on-prem is usually cheaper over time. If you face occasional large volumetric attacks, paying for an on-demand cloud service is often cheaper than overbuilding links and hardware you rarely use.

Latency and path changes

On-prem filtering does not change the path of legitimate traffic. This matters for game servers, VoIP and trading workloads.

Cloud scrubbing adds a detour: client → scrubbing edge → GRE tunnel → your edge. The added latency depends on how far the scrubbing location is from you and from your users. Evaluate:

• Always-on: all traffic takes the detour all the time. Predictable, but latency is always affected.
• On-demand: normal traffic goes direct; during an attack you announce prefixes via the scrubbing provider. Better everyday latency, but you depend on detection speed and BGP propagation. Test the switch time before you need it.

Also account for GRE overhead: the tunnel reduces effective MTU. Handle it with MSS clamping or by lowering tunnel MTU, otherwise you will see mysterious stalls on large transfers.

Hybrid design with BGP tunnels

A layered design plays to each model's strength:

1. Flow-based detection (NetFlow v5/v9, IPFIX or sFlow) from your edge routers to a collector, with per-IP and per-prefix bps/pps thresholds.
2. On-prem filtering for small and medium attacks and for traffic you can classify locally.
3. FlowSpec to push precise match rules (protocol, port, packet length) to your routers or upstreams for known amplification vectors.
4. RTBH as the last resort for a single victim IP, so the attack doesn't harm the other customers.
5. Cloud scrubbing over a BGP tunnel when volume threatens your links.

Step 5 is where the DDoS tunnel comes in. NixGuard Edge works this way for networks with their own ASN and at least one /24: your prefixes are announced from the scrubbing edge, and clean traffic returns over a GRE tunnel with a BGP session inside. You can use your AS-SET for prefix filtering, and run it always-on or on-demand.

Example: GRE tunnel endpoint on Linux

Addresses use documentation ranges. Your provider will give you the real endpoints.

ip tunnel add gre-scrub mode gre local 192.0.2.10 remote 203.0.113.1 ttl 255
ip addr add 198.51.100.2/30 dev gre-scrub
ip link set gre-scrub mtu 1400 up

# Avoid MTU blackholes for TCP through the tunnel
iptables -t mangle -A FORWARD -o gre-scrub -p tcp \
  --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Example: BGP session inside the tunnel (BIRD 2)

protocol bgp scrub_edge {
  local 198.51.100.2 as 64500;
  neighbor 198.51.100.1 as 64501;
  ipv4 {
    import all;
    export where net ~ [192.0.2.0/24];
  };
}

Treat this as a skeleton. Exact session parameters, filters and what you export or import depend on the provider's design, so confirm them before going live.

Example: RTBH trigger on a Cisco IOS edge

ip route 192.0.2.55 255.255.255.255 Null0 tag 666

route-map STATIC-TO-BGP permit 10
 match tag 666
 set community 64496:666
 set origin igp

router bgp 64500
 redistribute static route-map STATIC-TO-BGP

Check your upstream's documented blackhole community; 64496:666 here is a placeholder. Also make sure outbound filters let /32 routes reach only the upstreams that accept them.

Decision guide

Choose mostly on-prem if: - Your upstream links have large headroom over typical attacks. - Latency is critical and you want no path changes. - You have staff to tune and maintain filtering.

Choose mostly cloud if: - Attacks can saturate your uplinks. - You can't staff 24/7 DDoS operations. - You have a /24 or larger and your own ASN, so you can announce from a scrubbing edge.

Choose hybrid if: - You run a hosting or ISP network with mixed customers, frequent small attacks, and occasional large ones. This is the most common case.

Common mistakes

• Sizing for the average attack, not your smallest link. Check each upstream individually.
• No detection tied to mitigation. A scrubbing service on standby is of little use if no one notices the attack for ten minutes. Flow-based detection with alerting shortens this.
• Untested failover. Rehearse the on-demand announcement and the withdrawal in a maintenance window.
• Ignoring return path. Clean traffic arrives over the tunnel, but your outbound traffic may leave via transit. Check uRPF and asymmetric routing with stateful devices, and consider SYN handling.
• Over-aggressive RTBH. Blackholing a victim completes the attack from the attacker's point of view. Use FlowSpec or scrubbing first when you can.
• Forgetting MTU. GRE overhead causes silent breakage if not handled.

Putting it together with NixMon

NixMon covers the detection and control layers: it analyzes NetFlow, IPFIX and sFlow with sub-second analytics, applies per-IP and per-prefix thresholds, and can act with BGP blackhole, BGP FlowSpec, the on-prem NixGuard firewall, or NixGuard Edge for cloud scrubbing. Alerts reach you through the iOS and Android apps. If you're a hosting provider, there's a multi-tenant panel, WHMCS integration and a white-label reseller mode.

The simplest way to decide is with your own data: point flow exports at a collector, see your real attack sizes and per-link utilization, and then pick the model. You can start a 15-day free trial without a credit card.