DDoS is an attack on availability: many sources, usually a botnet, send traffic at once to exhaust bandwidth, protocol state, or application resources. The goal is not to steal data but to take the service down for real users.
Defense splits into two distinct fronts: absorbing and filtering volumetric attacks at L3/L4 on the network edge (anycast, scrubbing, caching, TLS termination) and cheaply rejecting harmful requests at L7 (WAF, rate limiting, bot management, challenges). A mature system holds both.
The chapter builds on its neighbors: OWASP Top 10 sets the security architecture frame, How a CDN Works explains anycast and caching as an absorption mechanism, and Rate Limiter is the main tool for cheap rejection. It then covers application resilience, readiness, and common mistakes.
Practical value of this chapter
Design in practice
Use guidance on DDoS defense at the network and application layers and the role of the edge to define architectural security requirements before implementation starts.
Decision quality
Validate solutions through threat model, security invariants, and production control operability, not compliance checklists alone.
Interview articulation
Frame answers as threat -> control -> residual risk, linking business scenario to concrete protection mechanisms.
Trade-off framing
Make trade-offs explicit for DDoS defense at the network and application layers and the role of the edge: UX friction, latency overhead, operational cost, and compliance constraints.
Context
How a CDN Works
Anycast and edge caching are the foundation for absorbing volumetric attacks.
DDoS (distributed denial of service) is an attack on availability: many sources, usually a botnet, send traffic at once to exhaust bandwidth, protocol state, or application resources and make the service unreachable for real users. Unlike a breach, the goal is not to steal data but to take the system down.
This chapter is about defending against DDoS at the network and application layers and the role of the edge (edge/CDN). Neighboring chapters give you the footing: OWASP Top 10 sets the security architecture frame, “How a CDN Works” explains anycast and caching as an absorption mechanism, and “Rate Limiter” is the main tool for cheap rejection at L7.
The main trap here is conflating volumetric defense at L3/L4 with application defense at L7. These are two different fronts: you can shield the pipe and the application still falls over from a stream of valid-looking requests. A mature system holds both — absorbing volume at the edge and cheaply rejecting harmful requests before they reach expensive business logic.
Attack classes: from the pipe to business logic
Volumetric attacks
L3/L4 — saturate the pipe
Goal: flood the link and network gear with junk traffic via UDP/ICMP floods and DNS/NTP/memcached amplification, where a small spoofed request triggers a reply tens or hundreds of times larger.
Metric: bits per second (bps) and packets per second (pps).
Protocol attacks
L3/L4 — exhaust state
Exploit protocol mechanics rather than bandwidth: the classic SYN flood leaves half-open TCP connections, exhausting state tables on load balancers, firewalls, and other devices between client and server.
Metric: new connections per second and the share of incomplete handshakes.
Application-layer (L7) attacks
L7 — exhaust app resources
HTTP floods of valid-looking requests, slow attacks like Slowloris (holding connections open with tiny data drips), and expensive requests to search, export, reports, or heavy-auth endpoints. Often disguised as legitimate users.
Metric: requests per second, latency, and per-request processing cost.
Where each defense layer meets the attack
Volume is absorbed and filtered at the edge; whatever gets through, the application must reject cheaply and degrade without dropping the critical path.
Three defense principles
Absorb
Anycast advertises the same IP from dozens of points of presence, so the attack spreads across the whole network capacity instead of concentrating on one data center. The larger the aggregate bandwidth, the higher the threshold an attack must break.
Works at L3/L4 for volumetric and protocol attacks at the network edge.
Filter
Scrubbing separates suspicious flows from legitimate ones by signature, reputation, and behavior. Amplification is cut by source-address filtering — providers apply anti-spoofing at network ingress following BCP 38.
Works at L3/L4 and partially L7 in scrubbing centers and at the edge.
Reject cheaply
If a request still gets through, reject it earlier and cheaper than it can consume an expensive resource: rate limiting, quotas, and challenges (JS or proof-of-work) push the cost back onto the attacker.
Works at L7 — at the edge and inside the application.
Edge and CDN: the first line
- Anycast distribution. Anycast over BGP advertises one IP from many points of presence — attack traffic scatters across the nearest nodes instead of hitting a single point.
- Volume absorption. An edge provider's aggregate capacity is orders of magnitude larger than a single origin's link, so volumetric attacks are absorbed before your infrastructure.
- Cache as a shield. The edge cache serves static and cacheable responses without touching the origin; the higher the cache-hit ratio, the less traffic reaches the application. Hiding real IPs behind an origin shield helps.
- TLS termination at the edge. Terminating TLS lets the edge see and filter L7 requests, apply a WAF, and offload expensive TLS handshakes from the origin.
- Blackholing / RTBH — last resort. Via BGP you can blackhole all traffic to the attacked address (RTBH, remotely triggered blackhole). It stops the attack but also drops legitimate users — effectively a voluntary outage, so it is used last.
L7 defense: controls and their cost
| Control | What it gives | Cost and risk |
|---|---|---|
| WAF and signatures | Cuts known attack patterns, anomalous URLs, and clearly malicious request shapes. | Low for the client, but rules need tuning against false positives. |
| Rate limiters and quotas | Cap frequency per IP, token, session, or API key and protect expensive endpoints. | Low, but grouping keys must be chosen so they do not penalize NAT and legitimate clients. |
| Bot management and reputation | Separates automated botnet traffic by behavior, fingerprints, and network reputation. | Medium: the model must keep updating, or it goes stale against new bots. |
| CAPTCHA, JS challenge, proof-of-work | Forces the client to do work before reaching the resource; the attacker's cost grows non-linearly. | Noticeable for users — apply selectively to suspicious traffic, not to everyone. |
| Signed tokens and origin verification | Drops requests without a valid token at the edge, before they reach expensive business logic. | Low to verify, but requires managing the token lifecycle. |
Application resilience
Cheap early rejection: validate request size, format, and token before touching the database or external services, so rejecting costs the application almost nothing.
Concurrency budgets and load shedding: a fixed cap on concurrent requests and explicit rejection under overload, instead of unbounded queues that turn a spike into a cascading failure.
Backpressure, timeouts, and circuit breakers: do not let slow dependencies accumulate stuck requests that amplify overload during an attack.
Graceful degradation: serve a cached or simplified version of a page, disable heavy personalization, and keep the critical path working under load.
Protect expensive endpoints: gate search, export, report generation, and writes behind separate quotas, queues, and stricter rate limiting than cheap reads.
Readiness: plan, providers, drills
Runbook and roles
Focus: What to do in the first minutes of an attack
Outcome: A ready runbook: how to recognize an attack, who to page, which switches to flip, how to enable a more aggressive defense mode, and how to roll it back afterward.
Protection providers
Focus: Cloudflare, AWS Shield, Akamai, and peers
Outcome: A connected and tested edge-protection service with anycast capacity and scrubbing centers; understanding its limits and behavior in managed (always-on) and reactive (on-demand) modes.
Responsibility model
Focus: Who owns what
Outcome: A clear line between the provider (network layer, capacity, baseline filtering) and your team (L7 rules, application defense, endpoint and quota configuration).
Drills
Focus: Proving the plan works
Outcome: Regular drills and game days that exercise defense switches, alerts, the on-call rotation, and provider contacts — before a real incident, not during one.
Trade-offs and common mistakes
Defending only at L3/L4 and assuming volumetric filtering will stop application HTTP floods and expensive requests.
Overly aggressive rules and challenges for everyone: false blocks of legitimate users and clients behind shared NAT can hurt as much as the attack itself.
No runbook and no drills: the team hunts for defense switches and provider contacts for the first time during the attack.
An exposed origin: real IP addresses are reachable directly, bypassing the edge, and the attacker hits past all the defenses.
DDoS defense is a balance: too weak lets the attack through, too strict blocks your own users.
References
Related chapters
- OWASP Top 10 in System Design - provides the security architecture frame where availability defense sits alongside confidentiality and integrity.
- How a CDN Works - explains anycast, edge caching, and distributed points of presence — the foundation for absorbing volumetric attacks.
- Rate Limiter - details rate-limiting algorithms and keys — the main tool for cheap rejection at the application layer.
- Resilience Patterns - covers timeouts, circuit breakers, load shedding, and graceful degradation, without which an application cannot survive a traffic spike.