DDoS and Abuse: What Providers Handle and What You Must

What providers include

All of this stops network-layer floods. None of it knows that your search endpoint runs an expensive query.

The attacks that actually hurt

• Application-layer floods — well-formed requests to the most expensive endpoint. Low bandwidth, high cost per request.
• Slow attacks — connections held open with minimal data, exhausting worker slots rather than bandwidth.
• Cache-busting — random query strings so every request misses the CDN and reaches the origin.
• Credential stuffing — not denial of service, but the same load pattern, plus account takeover risk.
• Scraping — aggressive crawlers that cost real money in egress.

These are cheap to launch and cannot be distinguished from legitimate traffic at the network layer, which is why they need application-layer defences.

Defences, in order of value

1. Put a CDN in front of everything. Cached responses never reach your origin, and the CDN absorbs the volume.
2. Rate limit per IP and per identity, at the edge if possible. Most abusive traffic stops here.
3. Cache aggressively, including short-lived caching of dynamic responses. Even ten seconds collapses a flood.
4. Deploy a WAF with managed rules for the common patterns.
5. Ignore query strings you do not use in cache keys, so cache-busting fails.
6. Autoscale with a ceiling. Scaling protects availability; the ceiling protects the bill.
7. Add a challenge — a proof-of-work or CAPTCHA on suspicious traffic only, never on everyone.

Protect the origin address

If an attacker learns the origin IP, they bypass the CDN entirely. Common leaks: historical DNS records, mail sent directly from the web server, TLS certificate transparency logs, and error pages that disclose the address.

Where possible, restrict the origin firewall to the CDN’s published address ranges so direct connections are refused.

Watch the bill as well as the availability

A successfully absorbed attack can still be expensive. Autoscaling and egress both bill by usage, so an attack you survived can arrive as an invoice.

• Set billing alerts that fire quickly, not just monthly.
• Cap autoscaling group maximums deliberately.
• Prefer CDN egress, which is usually cheaper than origin egress.
• Monitor requests per second alongside cost per hour.

Have a short plan written down

1. How do you tell an attack from a traffic spike? Which dashboard, which metric.
2. Who can enable stricter rate limits, and how.
3. Which endpoints can be disabled temporarily without breaking the product.
4. How to enable a challenge page for all traffic if it comes to that.
5. Provider support contact and account details, available offline.
6. How you will tell customers what is happening.

Half an hour writing this beats an hour improvising it during the incident.

Common questions

Where to go next

See CDN and caching, which is the single most effective defence here, and security groups and firewalls.