DDoS Protection

Any service reachable from the public internet is reachable by anyone — including someone who wants it offline. A distributed denial-of-service attack doesn't need to break in; it just needs to send more traffic, or more resource-hungry requests, than the target can handle, so legitimate visitors can't get through the flood. Renting enough compromised devices or cloud capacity to generate that flood is cheap and easy, which is why the attacks are common against anything with a public footprint.

The defense works by scale: routing traffic through a network built with far more absorption capacity than the flood, filtering out the junk, and passing legitimate requests through to the real destination — ideally before a visitor notices anything happened at all.

The problem it solves

A website, API, or network link is sized for realistic peak legitimate demand, not for an attacker deliberately trying to exceed it. Once incoming traffic outstrips available bandwidth or server capacity, everyone suffers — real customers get timeouts and failures right alongside the flood, with no way for the target to tell the difference on its own.

Attacks increasingly target the application layer rather than raw bandwidth: instead of a brute packet flood, they send seemingly valid requests designed to exhaust servers or application logic. Such attacks can down a service with far less bandwidth than a volumetric flood, and are harder to distinguish from a real, if unusually large, spike in legitimate use.

How it works

During an attack, traffic destined for the protected service gets redirected — via a BGP route announcement or a DNS change — through a provider's scrubbing network instead of going straight to the origin. That network is built with far more absorption capacity than any single customer would ever provision on their own, spread across many points of presence so an attack against one customer doesn't have to be absorbed at a single location.

Volumetric mitigation filters out floods aimed at simply saturating available bandwidth, while application-layer protection inspects requests that look superficially legitimate but are actually part of an attack pattern targeting the application itself rather than the network link. Clean, legitimate traffic is forwarded on to the real origin; the flood is dropped at the scrubbing layer and never reaches it.

Always-on vs on-demand mitigation

Always-on protection routes all traffic through the scrubbing network permanently, so mitigation is already active the instant an attack begins, at the cost of adding a small amount of latency to every request, all the time, whether under attack or not.

On-demand protection normally lets traffic flow directly to the origin, only rerouting through scrubbing once an attack is detected — avoiding that constant latency cost, but introducing a detection-and-failover window at the start of an attack during which some disruption is possible before mitigation kicks in fully.

Choosing one

Start with how much an outage would actually cost: a revenue-critical service or one with strict uptime commitments usually justifies the always-on approach despite the added latency, while a lower-stakes service may accept a brief on-demand failover window in exchange for better everyday performance and lower cost.

From there, weigh the kind of attacks most likely to matter — pure volumetric floods versus more targeted application-layer attacks — against the provider's stated scrubbing capacity and, importantly, how quickly it actually detects and mitigates an attack in practice, since a huge network that reacts slowly still lets a fast, targeted attack do damage before protection engages.