DDoS Resilience: Designing for the Flood

A distributed denial-of-service attack does not exploit a bug. It exploits arithmetic — more requests, or more raw bandwidth, than your infrastructure can absorb. That makes DDoS unusual among threats: there is nothing to patch, and no amount of secure coding prevents it. Resilience is a property of how you are built and how you have rehearsed, decided long before the traffic spikes. The organisations that ride out an attack are the ones that designed for it while it was hypothetical.

It helps to separate the layers an attack can target, because the defences differ. Volumetric attacks aim to saturate your bandwidth with sheer traffic, often amplified by abusing open internet services to multiply their firepower. Protocol attacks exhaust finite resources in the network stack — connection tables, handshake state — with comparatively little bandwidth. Application-layer attacks are the subtlest: modest volumes of requests that each look legitimate but are individually expensive, targeting a search endpoint or a login flow until the backend buckles.

Why you cannot self-host your way out

The uncomfortable reality is that a large volumetric attack can exceed the total bandwidth of your internet connections before a single packet reaches any device you own. No firewall you can rack survives traffic that fills the pipe upstream of it. This is why serious volumetric defence happens in the network of a provider with vastly more capacity than any attack — traffic is scrubbed far from your infrastructure, and only clean traffic is delivered. Absorbing the flood is a capacity game, and capacity is the thing you rent, not buy outright.

• Put scrubbing capacity in front of you. Volumetric defence must live upstream, in a provider network large enough that the attack is a rounding error — not in your own rack.
• Design the application to shed load gracefully. Rate limiting, caching, queueing and the ability to serve a degraded-but-up experience decide whether an application-layer attack is an annoyance or an outage.
• Eliminate single points of failure. Anycast, multiple providers and geographic distribution mean no one link or region is the whole target.
• Protect the dependencies, not just the front door. DNS and authentication are favourite DDoS targets because taking them down takes down everything behind them.
• Rehearse the runbook. Know in advance who declares an incident, how scrubbing is engaged, and how you communicate — an attack is the worst time to discover the process does not exist.

The application layer is where preparation shows

Volumetric attacks make headlines, but application-layer attacks are where most organisations actually fall over, because they slip past crude volume thresholds — the traffic looks like users. Defending here is an engineering discipline: knowing which endpoints are expensive, capping how hard any client can hit them, caching what can be cached, and ensuring an overloaded component degrades instead of cascading. This work pays off far beyond DDoS; a system that stays up under a flood is a system built with real capacity discipline.

Resilience is rehearsed, not purchased

The failure mode is predictable: an organisation buys DDoS protection, never tests it, and discovers during the real attack that traffic was not actually routing through the scrubber, or that a critical dependency sat outside the protection. Resilience is a property you verify — through game days and controlled tests — not a licence you hold. The flood will find whatever you did not rehearse.

You can only protect the internet-facing assets and dependencies you know you have — and the forgotten subdomain pointing straight at origin is the one the flood hits. DDoS resilience, like everything upstream of it, starts with discovering your real attack surface.