Radware Cloud DDoS Protection — Always-On, On-Demand & Scrubbing Centers

① Why on-prem can't stop a volumetric flood

The single most important idea: when an attack is bigger than your internet uplink, no on-prem device can save you. A volumetric flood fills the pipe itself; packets are dropped on the saturated link before they ever reach your firewall or DDoS appliance. Buying a faster box does nothing — the bottleneck is the link, not the box.

Picture a hosting ISP on a 10 Gbps uplink hit by a 40 Gbps UDP reflection flood. The link is four times oversubscribed, so legitimate customer traffic is starved out and the firewall sits unresponsive behind a drowned pipe. The only fix is to move mitigation upstream — into the cloud, where capacity is measured in terabits — so the flood is absorbed before it ever reaches your link.

② The scrubbing network — distributed capacity near the source

Radware's defence lives in a global scrubbing network. A scrubbing center receives your traffic, removes the attack packets, and forwards only clean traffic onward. As of 2026 the network spans 65 cloud security centers with 30 Tbps of aggregate mitigation capacity (doubled from 15 Tbps), each upgraded with the DefensePro X mitigation engine. New 2025 sites include Mumbai, Singapore, Bogotá, Lima and a second Tel Aviv.

Why full-mesh Anycast matters

The centers are connected in full-mesh, Anycast mode. Anycast advertises the same address from many sites, so a flood is drawn to — and scrubbed at — the center nearest its source. That distributes load across the network instead of funnelling everything to one site, and it cuts latency for clean traffic. Detection uses patented behavioral algorithms plus machine learning to build real-time signatures for zero-day floods, with AI web DDoS protection that handles HTTPS floods beyond 50 million requests per second.

③ Always-On vs On-Demand vs Hybrid — picking the mode

The service ships in three flavours that differ in when your traffic flows through the cloud. Always-On routes traffic through Radware's POPs 24/7 (typically via BGP); because the data path is already in the cloud, there is no diversion lag and mitigation begins in seconds — best for high-risk or frequently targeted assets. On-Demand lets traffic flow directly to you in peacetime; Radware monitors for anomalies and diverts traffic to scrubbing only when an attack is detected, then reverts — lower steady-state latency, but a small time-to-divert.

Hybrid pairs an on-prem DefensePro appliance (instant local mitigation for attacks within link capacity) with the cloud, which auto-engages on a pipe-saturation signal to absorb floods too big for the uplink. The interview line: the trade-off is always latency vs time-to-mitigate. Always-On trades a little steady-state path for instant defence; On-Demand keeps peacetime fast but accepts a short divert window; Hybrid gives you edge speed plus cloud capacity.

④ Diversion and clean-traffic return — how the cutover works

Getting traffic into scrubbing uses one of two methods. BGP diversion is network-layer and whole-prefix: the customer (or Radware) re-advertises the protected /24 or larger prefix so all traffic for that subnet enters the scrubbing centers — protocol-agnostic, protects entire subnets. DNS diversion is per-service: the hostname's DNS record is pointed to a Radware VIP, with TTL pre-lowered (≤300s) so the cutover propagates fast — granular and ideal for a single web app.

Returning the clean traffic

Scrubbed traffic must get back to you without re-entering the attack path. The most common return is an out-of-band GRE tunnel (MTU 1500) to the customer CPE; a direct cross-connect is the alternative. Only legitimate packets traverse it. Time-to-mitigation SLAs reflect the mode: Always-On mitigates in seconds because traffic is already in the cloud, while diversion-based modes meet attack-type-dependent SLAs measured in minutes. The classic failure is forgetting to verify the GRE return tunnel — traffic gets scrubbed but has no clean path home.