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

Source: https://ai.techclick.in/blog_radware_cloud_ddos_service
Markdown: https://ai.techclick.in/blog_radware_cloud_ddos_service.md
Publisher: Techclick Infosec Pvt Ltd

A clear, interactive guide to Radware Cloud DDoS Protection (2026): why on-prem gear can't survive a volumetric flood, the 65-center, 30 Tbps full-mesh Anycast scrubbing network, the Always-On vs On-Demand vs Hybrid deployment trade-offs, and exactly how BGP and DNS diversion plus GRE-tunnel clean-traffic return meet time-to-mitigation SLAs.

Radware Cloud DDoS Protection — Always-On, On-Demand &amp;amp; Scrubbing Centers student learning map
                     A visual study map for Radware Cloud DDoS Protection — Always-On, On-Demand &amp;amp; Scrubbing Centers showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Radware Cloud DDoS Protection — Always-On, On-Demand...
                     Radware · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   🎯 By the end you will be able to

   2. Understand
   Pick where you want to start

   3. Prove
   ① Why on-prem can&#39;t stop a...

   4. Practice
   ② The scrubbing network —...

                     How to use this page
                     First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself.
                     Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456

             Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail.

             Most engineers think…

             Most people assume a beefy on-prem firewall or 'DDoS box' will handle any flood. That mental model fails the moment the attack is larger than your internet pipe.

 Radware Cloud DDoS Protection is a  distributed, cloud-delivered service : a global network of  scrubbing centers  (65 sites, 30 Tbps, full-mesh Anycast) that absorb and clean attack traffic  upstream , before it ever reaches your links. It comes in three modes —  Always-On ,  On-Demand  and  Hybrid  — and routes traffic in via  BGP  or  DNS  diversion, returning clean traffic over a  GRE tunnel . Understanding that 'move mitigation upstream' shift is what lets you pick the right mode, the right diversion method, and meet the time-to-mitigation SLA.

## ① 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.

  Legend    diagram title    stage name    what the stage does    flow arrows &amp; borders    diagram canvas

          Figure 1 — The cloud DDoS loop — detect, divert, scrub, return, report
   Radware moves mitigation upstream: attack traffic is diverted into the cloud, scrubbed, and only clean traffic is returned.
- The cloud DDoS loop — detect, divert, scrub, return, report Detect behavioral + ML Divert BGP or DNS Scrub DefensePro X Return GRE tunnel Report portal dashboard Radware moves mitigation upstream: attack traffic is diverted into the cloud, scrubbed, and only clean traffic is returned. Figure 2 — Why the pipe drowns first When attack volume exceeds the uplink, the link saturates and drops everything before any on-prem box can act. Why the pipe drowns first Attack volume ~40 Gbps UDP reflection flood arriving Uplink capacity Only 10 Gbps — saturated and dropping packets On-prem box Starved behind a full pipe, cannot help When attack volume exceeds the uplink, the link saturates and drops everything before any on-prem box can act. Quick check · Q1 of 10 · Understand Why can't an on-prem firewall stop a flood bigger than your internet link? a) Firewalls don't inspect UDP b) The internet link saturates and drops traffic before it ever reaches the firewall c) On-prem boxes are always too cheap d) DNS resolution is too slow Correct: b. A volumetric flood fills the pipe itself. Once the link is saturated, packets are dropped upstream of the box, so a faster firewall changes nothing — mitigation must move into the cloud where capacity is in terabits. 👉 So far: On-prem gear can't stop a volumetric flood bigger than the uplink — the link saturates and drops everything first, so mitigation must move upstream into the cloud. ## ② 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. Figure 3 — One Anycast network, scrubbed near the source Floods are drawn to the nearest of 65 full-mesh scrubbing centers, distributing load and cutting latency. One Anycast network, scrubbed near the source Anycast net 65 sites · 30 Tbps Mumbai center Singapore center Tel Aviv center Bogotá center Lima center DefensePro X Floods are drawn to the nearest of 65 full-mesh scrubbing centers, distributing load and cutting latency. 🧽 Scrubbing center tap to flip A cloud facility that receives your traffic, strips the malicious packets and forwards only clean traffic — 65 of them, 30 Tbps total, running DefensePro X. 🌐 Full-mesh Anycast tap to flip The same address advertised from every site, so a flood is scrubbed at the center nearest its source — load is distributed and latency drops. 📡 BGP diversion tap to flip Re-advertise the protected /24 (or larger) prefix so all traffic for that subnet routes into scrubbing. Network-layer, whole-prefix, protocol-agnostic. 🛡️ DefensePro X tap to flip Radware's mitigation engine in each center — behavioral + ML detection builds real-time signatures for zero-day and AI web DDoS floods. Lead with 'upstream', not 'bigger box' In an interview, the winning framing is that volumetric mitigation has to happen upstream of the saturated link, in the cloud. Name the network — 65 centers, 30 Tbps, full-mesh Anycast scrubbing near the source — rather than promising a faster on-prem appliance. Quick check · Q2 of 10 · Remember How are Radware's scrubbing centers connected, and why? a) In full-mesh Anycast so floods are scrubbed nearest their source b) In a single hub so all traffic funnels to one site c) In a ring for redundancy only d) Star mode anchored on Mumbai Correct: a. Full-mesh Anycast advertises the same address from all 65 sites, drawing a flood to the nearest center. That distributes load across the network and cuts latency for clean traffic. 👉 So far: Radware's scrubbing network = 65 centers, 30 Tbps, full-mesh Anycast running DefensePro X, scrubbing floods nearest their source with behavioral + ML detection. ## ③ 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. Figure 4 — Always-On vs On-Demand The same scrubbing network runs both — the difference is whether your traffic is always in the cloud or only diverted on attack. Always-On vs On-Demand Always-On Traffic in cloud 24/7 No diversion lag — mitigate in Best for high-risk assets Adds steady-state path On-Demand Direct traffic in peacetime Divert only when attack detected Lowest steady-state latency Small time-to-divert window The same scrubbing network runs both — the difference is whether your traffic is always in the cloud or only diverted on attack. 'Always-On is just better' over-simplification Always-On is not automatically the right answer. It puts your traffic through the cloud 24/7, which adds a steady-state path. For assets that are rarely targeted and latency-sensitive, On-Demand keeps peacetime fast and only diverts during an attack. Match the mode to the asset's risk profile. ### ▶ Watch a 40 Gbps flood get diverted, scrubbed and returned clean How an On-Demand customer survives a volumetric attack end-to-end. Press Play for the healthy path, then Break it to see the classic failure. ① Detect Radware's monitoring flags a volumetric anomaly on the protected /24 — far above the customer's 10 Gbps uplink. ▼ ② Divert BGP diversion engages: the /24 is advertised so all traffic for that subnet now routes into the nearest scrubbing center. ▼ ③ Scrub DefensePro X applies behavioral signatures, drops the attack packets and keeps only legitimate traffic. ▼ ④ Return clean Scrubbed traffic is carried back to the customer CPE over the out-of-band GRE tunnel; the uplink recovers. Press Play to step through the healthy diversion path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A bank wants the fastest possible mitigation for a frequently targeted payment portal and accepts always routing through the cloud. Which mode fits? a) No protection needed b) On-Demand c) Always-On d) DNS-only with high TTL Correct: c. Always-On keeps the data path in the cloud 24/7, so there is no diversion lag and mitigation begins in seconds — exactly right for a high-risk, frequently targeted asset that can accept the steady-state path. 👉 So far: Always-On = traffic in cloud 24/7, mitigate in seconds; On-Demand = divert only on attack, lowest peacetime latency; Hybrid = on-prem DefensePro plus cloud for volume. ## ④ 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. Figure 5 — How a diversion plays out end-to-end From detection to clean return — BGP advertises the prefix, DefensePro X scrubs, and a GRE tunnel carries clean traffic home. How a diversion plays out end-to-end Detect anomaly flagged Advertise /24 via BGP Scrub remove attack pkts GRE return clean to CPE Revert when attack ends From detection to clean return — BGP advertises the prefix, DefensePro X scrubs, and a GRE tunnel carries clean traffic home. Vikram Rao, network lead at Sahyadri Cloud (Pune), faces this Customer sites go unreachable; the 10 Gbps upstream is 100% saturated and the on-prem firewall is unresponsive. Likely cause A ~40 Gbps UDP reflection flood — far above the uplink — so the pipe itself is full and no on-site device can help. Diagnosis In the Radware Cloud DDoS portal, Dashboard ▸ Attacks confirms a volumetric event on the protected /24; Configuration ▸ Diversion shows the prefix is in On-Demand mode but BGP diversion has not engaged. Radware Cloud DDoS portal ▸ Dashboard ▸ Attacks + Configuration ▸ Diversion / Tunnels Fix Trigger (or auto-enable) BGP diversion to advertise the /24 into the scrubbing centers, verify the GRE return tunnel is up under Configuration ▸ Tunnels, and let DefensePro X scrub. Verify Watch Dashboard ▸ Traffic: post-scrub clean throughput returns to normal, the attack graph drops, and uplink utilisation falls back below capacity. Prove the clean path, don't assume it Never declare a diversion healthy on the attack graph alone. Confirm in the portal that the GRE return tunnel is up and that post-scrub throughput is actually arriving at the origin. Scrubbing with no return path means clean traffic never reaches your servers. Quick check · Q4 of 10 · Analyze Traffic is being scrubbed in the cloud but the origin still isn't receiving clean traffic. What should you check first? a) Whether the GRE return tunnel is up b) Whether the firewall licence expired c) Whether DNS TTL is above 300s d) Whether the endpoint agent is installed Correct: a. Scrubbed traffic needs a clean path home, normally an out-of-band GRE tunnel to the CPE. If the tunnel is down, traffic is cleaned but has nowhere to return — verify the tunnel before anything else. 👉 So far: BGP diversion advertises a /24+ prefix (whole-subnet); DNS diversion points a hostname to a Radware VIP with low TTL (per-service); clean traffic returns over a GRE tunnel. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why can't my on-prem firewall stop a huge DDoS? Always-On vs On-Demand — what's the difference? What exactly is a scrubbing center? How does BGP diversion work? When would I use DNS diversion instead of BGP? How fast does mitigation actually kick in? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember How much aggregate mitigation capacity does Radware's cloud network have as of 2026? a) 5 Tbps b) 30 Tbps c) 15 Tbps d) 100 Tbps Correct: b. The network was doubled from 15 Tbps to 30 Tbps across 65 cloud security centers, each upgraded with the DefensePro X mitigation engine. Q6 · Understand On-Demand deployment diverts customer traffic to scrubbing… a) All the time b) Never — it just alerts c) Only when an attack is detected d) Once per scheduled window Correct: c. On-Demand keeps peacetime traffic flowing directly to the customer for low latency, and only diverts to the scrubbing centers when monitoring detects an attack, reverting afterwards. Q7 · Apply You must protect an entire /24 subnet regardless of protocol. Which diversion method fits? a) DNS diversion to a VIP b) Lowering the DNS TTL only c) Installing an endpoint agent d) BGP diversion of the prefix Correct: d. BGP diversion re-advertises the whole /24 (or larger) prefix so all traffic for the subnet enters scrubbing — it is network-layer and protocol-agnostic. DNS diversion is per-service, not whole-subnet. Q8 · Analyze Why does Anycast routing scrub a flood nearer to its source? a) It encrypts the attack traffic b) Because DNS TTL is set to zero c) It funnels all traffic to Mumbai first d) Because the same address is advertised from many sites, so traffic reaches the closest center Correct: d. Anycast advertises one address from all 65 sites; routing naturally delivers a flood to the nearest center. That distributes load across the mesh and cuts latency, instead of funnelling everything to one site. Q9 · Evaluate An interviewer asks the best way to survive a flood far larger than your uplink. Strongest answer? a) Buy a bigger on-prem firewall b) Lower the firewall logging level c) Move mitigation upstream into the cloud scrubbing network so the flood never reaches your saturated link d) Block all UDP at the endpoint Correct: c. The link is the bottleneck, so a bigger box cannot help once the pipe is full. Cloud scrubbing absorbs the flood upstream, in terabit-scale capacity, before it reaches your link — that is the whole point of the service. Q10 · Evaluate What is the strongest reason to verify the GRE return tunnel during a live diversion? a) It speeds up DNS propagation b) Because scrubbed clean traffic has no path back to the origin if the tunnel is down — so sites stay unreachable despite scrubbing c) It lowers the time-to-mitigation SLA d) Because BGP cannot work without it Correct: b. Diversion plus scrubbing is only half the loop — clean traffic must return. If the out-of-band GRE tunnel is down, the attack is filtered but legitimate traffic never reaches the origin, so always confirm the return path. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: why is Radware Cloud DDoS Protection described as 'mitigation upstream in the cloud' rather than 'a box on your network'? Then compare with the expert version. Compare with expert answer Expert version: Because a volumetric flood that is bigger than your internet uplink saturates the link itself — packets are dropped before they ever reach any on-prem box, so a faster appliance is useless. Radware instead routes traffic into a global scrubbing network (65 centers, 30 Tbps, full-mesh Anycast) that absorbs and cleans the flood upstream, near its source, and returns only clean traffic over a GRE tunnel. You pick Always-On for instant in-cloud mitigation, On-Demand to divert only during an attack, or Hybrid to pair an on-prem DefensePro with the cloud — and you route traffic in via BGP (whole /24 prefix) or DNS (per-service VIP). There is no single inline 'DDoS box'; there is a terabit-scale cloud network sitting above your link. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Radware DDoS at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Scrubbing center A cloud facility that receives your traffic, strips out the malicious packets, and forwards only clean, legitimate traffic to your servers. Volumetric attack A flood that fills the victim's bandwidth (e.g. UDP reflection or amplification), drowning the internet link rather than exhausting an application. Always-On Deployment mode where traffic flows through Radware's cloud continuously, so detection and mitigation run with no diversion lag — measured in seconds. On-Demand Mode that lets traffic flow directly in peacetime and diverts it to the cloud only when an attack is detected, then reverts. Hybrid DDoS An on-prem DefensePro appliance for instant local mitigation paired with the cloud service that absorbs volumetric floods too big for the link. Anycast Routing that advertises one shared address from many sites, sending traffic to the nearest center so floods are scrubbed near their source. BGP diversion Re-advertising a /24 or larger prefix so all subnet traffic routes into the scrubbing centers — network-layer and protocol-agnostic. DNS diversion Pointing a service's hostname to a Radware VIP with a low TTL so the cutover to scrubbing propagates quickly — granular and per-application. GRE tunnel The out-of-band encapsulated path (MTU 1500) that returns scrubbed clean traffic to the customer CPE. Time-to-mitigation The SLA metric for how fast attack traffic is brought under control — seconds for Always-On, minutes for diversion-based modes. #### 📚 Sources Radware — Cloud DDoS Protection Service (product page) . radware.com
- Radware — Radware Doubles Global Cloud Security Capacity to 30 Tbps (Jan 2026 release) . globenewswire.com
- Radware Support — Choosing the Best Diversion For Your Needs (BGP vs DNS, GRE return) . support.radware.com
- Radware — Cloud DDoS Protection Service Data Sheet . radware.com
- The Fast Mode — Radware Expands Cloud Security Network with 30 Tbps Capacity . thefastmode.com
- Tempest Networks — Radware Cloud DDoS Protection Service overview . tempestns.com

### What's next?

             Got the cloud service? Next, go deep on the on-prem DefensePro appliance itself — behavioral detection, real-time signatures, SSL attack protection and how it feeds the hybrid signal to the cloud.

                 Next · All interview lessons →
                 Practice on exam.techclick.in →

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt
