Rate limiting and DDoS scrubbing get discussed as if they're the same idea at different price points. They aren't. They operate at different layers of the stack and defend against different failure modes.
The distinction becomes expensive when you discover it during an incident: a carefully tuned application-layer rate limiter does nothing for a server whose uplink is already saturated, because the limiter never receives the traffic it was supposed to evaluate.
This piece covers where each one actually works, what scrubbing infrastructure does mechanically, the tradeoffs between always-on and on-demand approaches, and how to tell which layer your own risk sits at.
Why basic rate limiting isn't enough against a real DDoS attack
Rate limiting works at the application or server level. A request arrives, the limiter identifies the source, checks a counter, and decides whether to serve or reject it. That's genuinely useful against scrapers, credential stuffing, and API abuse from a misbehaving client.
Notice what the mechanism requires: the request has to arrive and be processed before a decision can be made. Rate limiting assumes your server has enough bandwidth to receive traffic and enough CPU to evaluate it, and that assumption is exactly what a volumetric attack removes.
A flood measured in tens or hundreds of gigabits per second, and modern attacks have reached well past that, saturates the link before your application sees anything. Your rate limiter is intact, correctly configured, and irrelevant, because the packets it was supposed to reject are already occupying all available capacity on the way in. Legitimate traffic is dropped by congestion rather than by policy.
Even below full saturation, some attack types exhaust resources other than bandwidth. Half-open connection floods consume connection table entries, and application-layer floods hitting expensive endpoints consume CPU and database capacity. Rate limiting helps against application-layer floods, where per-source judgment is exactly the right tool, and does relatively little against link saturation or connection-table exhaustion.
What DDoS scrubbing actually does
Scrubbing moves filtering upstream, away from the thing being protected. The core idea is that a link with 10 Gbps of capacity cannot defend itself against 100 Gbps of traffic, so the filtering has to happen somewhere with more capacity than the attack.
Mechanically, traffic destined for a protected address is diverted into a scrubbing center or a distributed scrubbing network, typically by announcing the prefix from the scrubbing provider's infrastructure via BGP, or by routing through a GRE tunnel or similar. Distributed scrubbing networks often lean on anycast here, spreading one address across many sites so an attack is absorbed in pieces rather than landing in one place. That infrastructure is provisioned with far more aggregate capacity than any single customer's uplink.
Inside, traffic is analyzed and filtered. The techniques stack: known attack signatures and spoofed-source packets are dropped, traffic is compared against a learned baseline of what normal looks like for that destination, protocol-level checks discard malformed or non-conforming packets, and challenge-response mechanisms distinguish real clients from simple attack tools. What survives is forwarded on to your actual server, usually over a dedicated path.
The important property is where the drop happens. Attack traffic is discarded while it's still on infrastructure sized to absorb it, so your uplink only ever carries what passed filtering.
Always-on versus on-demand scrubbing
Always-on scrubbing routes all your traffic through the scrubbing path permanently. Protection is immediate because there's no detection or diversion step, and the cost is a small, constant latency addition from the extra network hop, plus generally higher pricing since the provider carries your traffic continuously.
On-demand scrubbing leaves traffic on its normal path and diverts only when an attack is detected, either automatically from flow monitoring or manually. Baseline latency stays clean and cost is lower, but there's a window between the attack starting and the diversion completing, typically measured in seconds to a few minutes depending on detection method and BGP convergence, during which the attack reaches you.
The choice comes down to what that window costs. For a service where a few minutes of degradation is survivable, on-demand is a reasonable economic tradeoff. For payment processing, competitive gaming, or anything where brief unavailability has immediate revenue or reputational cost, always-on is usually worth the premium.
Rate limiting versus scrubbing: where each one fits
Rate limiting belongs at the application layer, where it has context scrubbing lacks. It knows which endpoint is expensive, which user is authenticated, and what a reasonable request rate looks like for your specific API. That contextual judgment is something upstream filtering can't replicate, because it doesn't know your application.
Scrubbing belongs upstream, where it has capacity your server lacks. It doesn't know or care what your application does; it knows how to absorb and discard a volume of traffic that would otherwise fill your pipe.
They're complementary rather than alternatives, and a well-protected setup runs both. Scrubbing handles the network-level flood, rate limiting handles the application-level abuse that survives filtering because it looks superficially legitimate, and each covers a gap the other has. Choosing one and skipping the other leaves an obvious hole in whichever direction you skipped.
Signs a server might need dedicated scrubbing, not just rate limiting
The clearest signal is outage behavior. If you've seen incidents where the server became unreachable rather than merely slow, and monitoring showed the uplink saturated, that's a bandwidth-layer problem and no amount of application tuning addresses it.
Threat profile is the other input. Competitive gaming services, high-profile e-commerce, cryptocurrency-adjacent services, and anything that attracts organized hostility have historically drawn larger and more persistent attacks than a typical business site. So does anything where a competitor benefits directly from your downtime, which is a more common motive than people assume.
Uptime requirements matter independently of likelihood. If your service is contractually or commercially unable to absorb even a brief network-level outage, that argues for always-on protection regardless of how probable an attack is, because the cost of the tail event dominates the calculation.
There's also a capacity-ratio point worth naming alongside those. If your total uplink is 1 Gbps, even a modest attack by contemporary standards exceeds it, so headroom is a separate input from likelihood: a small deployment nobody targets may never need scrubbing, while a small deployment that does get targeted hits the wall faster than a larger one would.
Wrapping up
Rate limiting and scrubbing solve different problems, and neither substitutes for the other. Rate limiting is contextual judgment applied at your application, bounded by your own capacity. Scrubbing is volume absorption applied upstream, bounded by infrastructure much larger than yours.
Work out which layer your actual risk sits at: whether your bad days look like a saturated uplink or like an expensive endpoint being hammered. That answer tells you where to spend, and in many cases the honest answer is both, with the balance set by how much a few minutes of downtime genuinely costs you.
Thanks for reading! If you're weighing DDoS protection for a growing service, xTom offers enterprise-grade dedicated servers and colocation alongside NVMe-powered KVM VPS through V.PS, IP transit, shared hosting, and general IT services for whatever your infrastructure needs next.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
Frequently asked questions about DDoS scrubbing
Is DDoS scrubbing just a more aggressive version of rate limiting?
No, they work at different layers. Rate limiting evaluates requests at your server, which requires the traffic to arrive first. Scrubbing filters upstream on infrastructure with far more capacity than your uplink, discarding attack traffic before it reaches you.
Does scrubbing add latency to normal traffic?
Always-on scrubbing adds a small constant amount, since traffic takes an extra hop through the scrubbing network. On-demand avoids that baseline cost but introduces a detection and diversion window at the start of an attack, during which traffic reaches you unfiltered.
Can rate limiting stop a volumetric DDoS attack on its own?
No. Once the uplink is saturated, legitimate and attack traffic are both dropped by congestion before your application processes anything. Rate limiting only acts on requests that actually arrive.
Do small websites actually need dedicated DDoS scrubbing?
It depends on threat profile and downtime tolerance rather than size. A smaller deployment often has less bandwidth headroom, so it can be overwhelmed by a smaller attack, but many low-profile sites are adequately served by rate limiting and their provider's baseline protections.
How does scrubbing infrastructure tell legitimate traffic from attack traffic?
Through layered techniques: signature matching against known attack patterns, spoofed-source detection, comparison against a learned baseline of normal traffic for the destination, protocol conformance checks, and challenge-response methods that simple attack tools fail.
Should I use both rate limiting and DDoS scrubbing together?
Yes, in most serious setups they're complementary. Scrubbing absorbs the volumetric flood, and rate limiting handles application-layer abuse that passes filtering because individual requests look legitimate.