DDoS resilience: the attack you cannot patch your way out of

DDoS is unusual among attacks in that there is nothing to exploit and nothing to patch. The traffic is often individually legitimate; there is simply too much of it, or it is aimed at the most expensive thing your application does. That changes the defence from prevention to capacity and discrimination.

Two very different problems

• Volumetric and protocol attacks aim to saturate bandwidth or exhaust network state. These are largely a solved commercial problem - a CDN or scrubbing provider absorbs them at a scale you cannot match on your own infrastructure.
• Application-layer attacks send comparatively little traffic but aim it precisely: search endpoints, login flows, report generation, anything that hits a database hard. Each request looks legitimate because it is legitimate. This is the hard problem.

The practical asymmetry is brutal: a request that costs the attacker almost nothing to send can cost you a database query, a cache miss and a second of CPU. Defence is largely about removing that asymmetry.

Protect the origin, or the rest is theatre

The most common expensive failure is not the attack volume - it is that the attacker found the origin. If your servers are reachable directly by IP, a CDN in front of them is decoration. Historic DNS records, certificate transparency logs, mail server addresses and old subdomains all routinely leak origin IPs.

Lock the origin so it only accepts traffic from your provider, rotate the IP if it has already leaked, and check what your own DNS history discloses.

What actually helps

• A CDN or scrubbing service in front of everything public, configured before you need it.
• Rate limiting per identity, not just per IP - attackers rotate addresses, and per-IP limits punish shared corporate NATs.
• Caching aggressively, because a cached response costs nothing to serve.
• Cost-aware endpoints: pagination limits, query timeouts, no unbounded exports, no expensive operations before authentication.
• Autoscaling with a ceiling - scaling without a limit converts an outage into a bill, which is its own kind of denial of service.
• Graceful degradation: shed load, serve stale content, disable expensive features rather than falling over entirely.

Prepare before, not during

Nearly everything useful must exist in advance: provider contacts and account access, the runbook for enabling emergency protection modes, who is authorised to make degradation decisions, DNS TTLs low enough to reroute quickly, and a status page hosted somewhere your attack cannot take down.

That last point is missed constantly. A status page on the same infrastructure as the service is unavailable exactly when you need it.

Extortion

Ransom demands accompanied by a short demonstration attack are common, and many are bluffs from actors with no real capacity. Decide the policy in advance rather than under pressure, involve law enforcement and your insurer, and be aware that paying marks you as willing to pay.

Where compliance touches this

Availability sits inside business continuity for most frameworks, and it is an explicit criterion if you have committed to the availability trust services criterion under SOC 2 or made contractual uptime commitments. Evidence usually means the protection is in place, the runbook exists, and it has been exercised.

Key takeaways

• Volumetric attacks are a commercial problem; application-layer ones are an engineering problem.
• If the origin is reachable directly, upstream protection is decoration.
• Rate limit per identity, cache hard, and cap autoscaling.
• Host the status page somewhere the attack cannot reach.