A cloud DDoS scrubbing service is usually described in a single sentence on vendor websites: traffic is diverted to a filtering network, malicious packets are dropped, clean traffic is handed back to your origin. That sentence is accurate and almost useless to anyone who has to sign the contract. It skips the eligibility gate that decides whether you can use route diversion at all, it skips the return path that causes most post-onboarding incidents, and it quietly skips the gaps scrubbing never covers.
What follows is the mechanical version: what happens to a packet, where the design breaks, and the handful of questions that separate a working service from a login page.
What happens to a packet once scrubbing is switched on
Detection, diversion, and the clean return path
Every scrubbing deployment has three stages, and buyers reliably diagram only the first two. Detection spots an anomaly, either from flow records exported by your edge routers or from inline inspection at the provider’s point of presence. Diversion pulls traffic away from its normal path and into a scrubbing centre. The third stage, returning cleaned traffic to your origin, is the one that gets drawn as an arrow with no label.
That arrow is where the engineering lives.
How traffic reaches the scrubbing centre
Three mechanisms dominate. Border Gateway Protocol (BGP) announcement, where the provider advertises your prefix from their network so the internet sends your traffic to them instead of to you. Domain Name System (DNS) or proxy redirection, where your hostname resolves to the provider’s addresses and they front the connection. Or a cross-connect at your hosting facility, where filtering happens on the path your transit already takes.
Each one carries different coverage. Proxy redirection protects hostnames. BGP diversion protects an entire prefix, including the protocols nobody remembers to mention in the scoping call: SSH, SMTP, RDP, database replication, SIP trunks, game or API ports.
What filtering actually runs inside the centre
Scrubbing is not one filter, it is a stack applied in order. Malformed and spoofed packets are dropped on protocol validation grounds first, because reflection and amplification traffic rarely survives a strict read of the specification. Rate limiting caps per-source and per-destination volumes. Signature filters match known botnet and tool patterns, including the current families of internet-of-things cannons. Behavioural filters compare live traffic against a baseline built during onboarding, which is why a provider that never baselined your estate will either over-block or under-block during the first real incident. At the application layer, challenge mechanisms sit last: JavaScript or cryptographic challenges, cookie validation, and human-interaction tests for requests that look like a browser but behave like a script.
Why the return path breaks things days after a successful onboarding
Clean traffic has to get home. That usually means a Generic Routing Encapsulation (GRE) tunnel from the scrubbing centre to your edge, a direct cross-connect, or proxy forwarding to an origin address that only the provider is supposed to know.
GRE encapsulation adds header bytes, which reduces the usable maximum transmission unit below the standard 1500 (the IETF specification for GRE, RFC 2784, sets out the encapsulation). Shrink the path MTU and block the Internet Control Message Protocol messages that would have told the sender to fragment, and you get a very specific failure mode: small requests work, logins work, and then large file uploads stall and some TLS handshakes hang. The service desk opens an application bug ticket. The change that caused it happened three days earlier on the network team’s side.
Asymmetric routing is the second reliable offender, where return traffic leaves the origin directly instead of back through the provider, and stateful inspection on either side drops the flow. The third is an origin access list that was never tightened, leaving your real address reachable to anyone who finds it. Agree MTU clamping, path verification and origin filtering in writing during onboarding, then test with a large multipart POST rather than a homepage load.
Three ways to deploy scrubbing, and which one your setup can actually use
Reverse proxy
Fast to onboard, often within a working day, and strong at HTTP and HTTPS filtering because the provider terminates the connection and can see requests rather than packets. It protects what resolves through it. Non-web services on the same server stay exposed, and if your origin address leaks, the proxy is bypassed entirely.
BGP diversion
This covers every protocol across a whole prefix, which is why it suits colocated estates, hosters and anyone running services beyond a website. Sales decks skip the eligibility gate. You need address space you can announce, a letter of authority, and a prefix the global routing table will accept. A /24 is the smallest IPv4 prefix generally accepted by network operators’ route filters, which is the practical floor. An organisation running six virtual machines inside a hoster’s shared range cannot route-divert at all, and no amount of procurement pressure changes that.
Hosting-level or carrier-level filtering
No onboarding work, often bundled, and genuinely useful against crude volumetric floods. Thresholds are usually shared across tenants and tuning is limited, so a noisy neighbour’s profile can shape your protection. Our guide to what ISP-level DDoS protection in the UK actually covers goes into where that model stops.
What each kind of estate realistically qualifies for
- Single cloud instance or shared hosting: reverse proxy, plus whatever the platform’s own filtering provides. BGP is off the table.
- Colocated rack with provider-assigned addresses: proxy for web, carrier filtering for the rest, unless the facility can offer scrubbing on your transit.
- Colocated or on-premises with your own autonomous system number and a /24 or larger: BGP diversion, always-on or on-demand, with proxy as an optional second layer for the web estate.
- Multi-site estate across regions: BGP for core prefixes, proxy for public web, and a deliberate decision about which scrubbing centres serve which users.
Always-on or on-demand: the time-to-mitigate trade-off
Time to mitigate is a sum, not a number. Add the flow export interval, the sampling ratio that determines how quickly an anomaly becomes statistically visible, threshold confirmation to avoid flapping, human sign-off if your contract requires a declaration, and route convergence once the announcement is made. Flow sampled at a low ratio with a 60-second export interval, followed by confirmation and approval, can easily miss a 30-second burst completely.
Repeat sub-five-minute hits are a procurement signal, not a nuisance. Attackers probing with short bursts are usually mapping your detection window before the sustained attempt, and an on-demand model will lose that race. Analysis of repeat targeting, covered in reporting that half of targeted firms get hit again, is the argument for always-on in environments that have already been hit once.
Always-on is not free of cost. Inspection adds latency, routing through a distant centre adds round-trip time, and permanently hairpinning international users through the wrong region is a performance decision disguised as a security one.
Read where the SLA clock starts. Attack onset, alarm generation and customer declaration are three different moments, and a clock that begins at customer declaration can hide several minutes of outage that your own attack report will show plainly. The wording matters more than the number.
What a cloud scrubbing service does not cover
Authoritative DNS
The protected prefix usually covers the web estate. The nameservers sit with a registrar or on a legacy internal pair, outside the contract, unmanaged and unmonitored. Knock those over and every other mitigation becomes irrelevant, because nothing resolves. DNS providers have been taken offline by volumetric attacks before, as coverage of the Point DNS incident recorded. Proper DNS DDoS attack protection means anycast nameservers with their own capacity and their own SLA, bought deliberately rather than assumed.
Origin IP leakage
Capacity is almost never why a defence fails. Leakage is. A historic A record in an archived DNS dataset, a certificate transparency log entry published when you issued a certificate for a staging host, a mail server on the same range with its address in every message header, a monitoring endpoint reachable by IP. Both of those first two sources are free and public. The attacker aims at the origin, the scrubbing centre never sees a packet, and your dashboard stays green throughout.
Application-layer abuse that looks legitimate
Login floods, search endpoints with expensive queries, cart and checkout calls, API scraping at scale. Volumetric filters pass this traffic because it is well-formed and modest in bandwidth. Defending it is rate shaping, caching, bot management and application design, not packet filtering.
Third-party dependencies
Your site stays up and the payment gateway, identity provider or logistics integration does not. Map those dependencies and ask each supplier what their own mitigation looks like, because your scrubbing contract covers your prefix and nothing else.
Whose network and capacity are you actually buying?
Branded portals frequently sit on somebody else’s scrubbing platform. That is not inherently bad, but it changes who can act during an incident. Three questions surface the answer in one call: which scrubbing centres serve my region and my users’ regions, who authors the mitigation policy for my account, and who is authorised to change that policy at 03:00 without waiting for me. If the answer to the last one is a ticket queue at a different company, you have bought monitoring, not management.
Advertised terabit figures are network-wide totals. What matters is capacity at the points of presence near your users and near the botnet sending the traffic, which is why our piece on judging scrubbing capacity claims treats the headline number as the least interesting line in the proposal.
What “managed”has to include before the word means anything
Four components, and a quote missing any of them is a self-service plan with a service wrapper:
- Onboarding and baseline tuning: who writes the initial policy, how many days of traffic profiling it takes, and what triggers a retune after a product launch or a seasonal shift.
- Escalation: a named contact route, a way for your staff to authenticate when your own identity provider is unreachable, and explicit authority for the provider to act without your sign-off.
- Attack reports: vector breakdown, packet and request-level detail, filter actions taken, and timestamps you can reconcile against your own logs.
- Rehearsal: a diversion test before you need it, a failover drill, and a first-hour runbook written down and circulated.
The UK’s National Cyber Security Centre sets out similar preparation expectations in its denial of service guidance, and it is worth reading before the first vendor meeting rather than after.
How UK scrubbing pricing is structured, and how to justify it
Quotes for managed DDoS protection in the UK are typically built from the same levers, whatever the branding: a committed volume of clean bandwidth, the number of protected prefixes or hostnames, burst and overage charges once mitigated traffic exceeds the commitment, and one-off onboarding and tuning fees. Always-on carries a premium over on-demand standby because inspection capacity is reserved continuously rather than borrowed during an event. Pricing moves, so treat any figure you are shown as current only on the day you see it, and compare the overage clause as carefully as the headline rate. Our breakdown of what UK DDoS protection really costs covers the line items in more detail.
Build the case from downtime, not from fear. Revenue per trading hour, contractual service credits you would owe customers, incident staff time at loaded cost, and any regulatory or reputational exposure specific to your sector. Set that against the monthly commitment plus a realistic burst allowance. Under-buying is where the arithmetic usually goes wrong: a cheap standby plan with slow escalation, measured across a year of repeat attacks, routinely costs more than the higher commitment it was chosen to avoid. If you want the broader landscape of mitigation options before shortlisting, our overview of DDoS attacks and possible solutions is the place to start.
A cloud DDoS scrubbing service is worth buying. Buy it knowing which protocols it covers, where the clean traffic comes back, who owns the metal, and which gaps are still sitting outside the contract.
Frequently Asked Questions
What is the difference between a cloud DDoS scrubbing service and a CDN or WAF proxy?
A content delivery network or web application firewall proxy works at the application layer for HTTP and HTTPS traffic, filtering requests and caching content. Scrubbing operates on packets and flows and, when deployed over BGP, can protect every protocol across a whole prefix including mail, remote access and APIs on non-web ports. Many providers sell both, and larger estates generally need both.
How quickly does scrubbing start once an attack begins?
With always-on routing, filtering is already in path and mitigation begins within seconds of detection. On-demand diversion adds flow export interval, threshold confirmation, any required human approval and route propagation, which commonly puts real time-to-mitigate in minutes rather than seconds. Check where your SLA clock starts, because attack onset and customer declaration are not the same moment.
Do I need my own IP address range and BGP to use a scrubbing service?
No, but you need them for route diversion. Without announceable address space (a /24 is the practical floor in the global IPv4 routing table) your options are reverse proxy for web services and whatever filtering your hoster or carrier provides. That constraint decides which protocols you can protect, so establish it before shortlisting vendors.
Does a cloud scrubbing service protect my authoritative DNS?
Usually not, unless the nameservers sit inside the protected prefix or you have bought managed DNS from the same provider. Authoritative DNS is the most frequently unmanaged of these gaps, and it is the one that makes everything else reachable. Ask explicitly whether DNS DDoS attack protection is in scope and what capacity backs it.
How is cloud DDoS scrubbing priced in the UK?
Typically by committed clean bandwidth, the count of protected prefixes or hostnames, burst and overage charges beyond the commitment, and separate onboarding and tuning fees, with a premium for always-on over on-demand standby. Prices and packaging change, so verify current terms directly with providers. Justify the spend against downtime cost per hour rather than against worst-case attack size.