DDoS attacks come in many flavors and target different layers of the stack. A blanket "we have DDoS protection" is rarely enough. The defense that actually works is layered: protection at the DNS level, at the CDN/edge, at the load balancer, at the application. Each layer blocks different attacks.
This post is how production teams structure DDoS defense — what each layer does, where the gaps are, and the realistic responses when an attack actually happens.
The Attack Landscape
DDoS attacks fall into three broad categories:
Volumetric. Floods of traffic to consume bandwidth. Hundreds of gigabits of UDP packets, DNS amplification, NTP reflection. Goal: saturate the network pipe before traffic reaches the application.
Protocol. Floods that exploit protocol weaknesses. SYN floods (TCP handshake), Slowloris (keep connections half-open), HTTP/2 rapid reset. Goal: exhaust connection tables and resources.
Application layer (L7). Floods of legitimate-looking HTTP requests. Each request is small, but the volume overwhelms application servers. Goal: exhaust application capacity before exhausting infrastructure.
Different defenses work against different attacks. A CDN that easily absorbs a volumetric attack might not detect a sophisticated L7 attack mimicking real users.
Layer 1: DNS
The first line of defense is DNS itself. If attackers cannot find your IP, they cannot attack it directly.
Practices:
- Use managed DNS (Route 53, Cloud DNS, Cloudflare) — they absorb DNS-level attacks.
- Do not expose origin IPs in DNS. Hide behind a CDN.
- Use multiple authoritative DNS providers for redundancy.
The DNS layer rarely fails for managed services. The vulnerability is in operational hygiene — leaking origin IPs through email headers, SSL certificates, or misconfigured services.
Layer 2: The CDN and Edge
Most volumetric attacks die at the CDN. Cloudflare, AWS CloudFront, Fastly, Akamai — they have terabits of capacity and routinely absorb attacks measured in the hundreds of gigabits.
For this to work:
- All public traffic flows through the CDN
- Origin IPs are restricted to only accept traffic from the CDN
- Direct origin access is blocked
# AWS Security Group rule — only accept from CloudFront
- IpProtocol: tcp
FromPort: 443
ToPort: 443
SourcePrefixListId: pl-cloudfront # AWS-managed prefix list of CloudFront IPs
If the origin's IP leaks and attackers route around the CDN, the CDN layer cannot defend. The origin firewall enforces "only CDN" as a hard rule.
Layer 3: Load Balancers
Load balancers — both cloud-managed (ALB, GLB) and self-hosted — have built-in DDoS protections:
- SYN flood protection (SYN cookies, connection limits)
- Rate limiting per connection or per IP
- Slowloris defense (short timeouts, max keep-alive)
For most teams, the cloud load balancer's defaults are fine. The configuration question is whether to tune rate limits per route — login endpoints get tighter limits than catalog browsing.
Layer 4: WAF
The WAF (covered in another post) is the L7 defense layer. WAFs detect application-layer attacks:
- HTTP floods of identical requests
- Slow-rate L7 attacks
- Bot traffic patterns
- Known-bad signatures
The WAF is where you fight credential stuffing, scraping, and application-specific abuse. Volumetric attacks are mostly handled before reaching the WAF.
Layer 5: Application Rate Limiting
Application-level rate limiting catches what gets past the upper layers. Per-user limits, per-API-key limits, per-action limits.
// Laravel rate limiter
RateLimiter::for('api', function (Request $request) {
return $request->user()
? Limit::perMinute(60)->by($request->user()->id)
: Limit::perMinute(10)->by($request->ip());
});
For authenticated traffic, per-user limits matter most. For unauthenticated, per-IP. For both, the limit should reflect the cost of the operation — a search query can be more permissive than a database write.
During an Attack
When an attack is happening, the runbook matters as much as the architecture. The phases:
Detection. Alerts on traffic anomalies. Traffic up 100x in 10 minutes, error rate spike, latency spike on a specific endpoint.
Triage. Is this a real attack, a misbehaving client, or a release-induced issue? Look at the request patterns. Logs from the CDN and WAF show the source.
Mitigation. Apply additional controls. Cloudflare's "Under Attack Mode" challenges every visitor with JavaScript. AWS Shield's rate-based rules can be tuned higher temporarily. Block specific countries or ASNs if the attack is geographically concentrated.
Sustained response. If the attack continues, escalate. Cloudflare's Pro/Business/Enterprise tiers have different DDoS support. AWS Shield Advanced ($3,000/month) gets you 24/7 support and DDoS Response Team access during attacks.
Postmortem. What worked, what did not, what tools were missing. The next attack will be different.
What Pre-Provisioned Defenses Look Like
Realistic defaults for most production setups:
- DNS through a managed provider with global presence
- CDN/edge absorbing all public traffic (Cloudflare, CloudFront, etc.)
- WAF with managed rule sets and custom rate limits
- Cloud load balancer at the origin (ALB, etc.)
- Origin firewall allowing only CDN IPs
- Application rate limiting per route
- Monitoring for traffic anomalies with alerting
This stack handles the typical attack profile a public-facing application sees.
Specific Attack Patterns
A few attacks deserve specific mention.
SYN floods. Spoof TCP SYN packets, exhaust the server's connection table. Defense: SYN cookies, which let the kernel handle the half-open state cheaply. Modern Linux has this on by default; most cloud load balancers handle it transparently.
HTTP flood. Many requests to expensive endpoints. Defense: WAF rate limits, application caching, fast failure on expensive endpoints when load is high.
Slow-rate attacks (Slowloris, R-U-Dead-Yet). Open connections and send data very slowly. Defense: request timeouts, max-connections-per-IP. Cloud load balancers handle this; standalone Nginx/Apache need explicit configuration.
HTTP/2 Rapid Reset (CVE-2023-44487). Open many HTTP/2 streams and reset them quickly. Defense: patched servers, rate limiting on stream creation. This was a 2023 incident; servers have been patched.
Cache-busting. Requests designed to bypass the CDN cache, forcing the origin to respond to every request. Defense: ignore unknown query parameters in cache keys, normalize URLs at the CDN.
What Does Not Work
A few non-defenses worth naming:
"We have a firewall." A cloud firewall absorbs little — the bandwidth is consumed before it filters. The CDN is the relevant layer.
"We use Cloudflare's free tier." The free tier provides basic DDoS protection but no fine-grained controls during an attack. For production, Pro or higher is the credible baseline.
"We are too small to be a target." Random targets get attacked too. Attackers often probe broadly; many attacks are not targeted.
"Our application has rate limiting." Application rate limiting is not enough if the traffic exhausts upstream resources before reaching the application.
Cost Considerations
DDoS protection costs:
- Basic (Cloudflare free, AWS Shield Standard): included with the service.
- Standard (Cloudflare Pro, AWS Shield Advanced): $20-$3,000/month depending on traffic.
- Enterprise (custom): five to six figures monthly for full enterprise support.
For most teams, the standard tier of one of the major providers is enough. Enterprise-grade protection is for businesses where the cost of downtime exceeds the cost of the protection — high-revenue or high-stakes services.
The Practical Reality
Most DDoS attacks against most companies are absorbed silently by the CDN. The team never sees them. The CDN's traffic graphs might show a spike that lasted 20 minutes; nothing about user experience changed.
The attacks that get through are usually:
- Targeted L7 attacks against specific endpoints
- Attacks that exploit gaps (leaked origin IPs, missing rate limits)
- Sustained attacks larger than the team's tier of protection
For the first: WAF and application rate limiting handle it. For the second: operational hygiene. For the third: upgrade the tier or escalate.
A Practical Hardening Checklist
For a public-facing SaaS:
- DNS through a managed provider (Route 53, Cloudflare, etc.)
- All public traffic through a CDN
- Origin firewall restricts to CDN IPs only
- WAF with managed rules and custom rate limits
- Application rate limiting per user and per route
- Monitoring for traffic anomalies with paging
- Runbook for "under attack" with the contact info for your CDN's support
- Tested escalation path to the next tier of DDoS protection
A week of work to set up. Years of value when an attack hits.
Building DDoS defense for a public-facing service or reviewing whether your current setup has gaps? We help teams design layered defense without overbuying expensive tiers. scopeforged.com