API DDoS Protection: What the Network Stops and What You Must Build

API DDoS protection works in two layers. The network absorbs volumetric and protocol floods, and every voxa.host server includes 100 Gbps of always on L3/L4 filtering for that. But an API usually fails before its link fills: expensive requests, login and token endpoints, and clients that retry. Those you control at your own edge and in code.

SaaS DDoS protection is mostly an architecture question. Some of it you buy from the network, the rest you build.

What does API DDoS protection cover at the network layer?

Layer 3 and Layer 4 attacks, such as SYN floods and UDP amplification through open DNS, NTP, memcached, CLDAP and SSDP servers, try to fill your port or exhaust connection state before any HTTP request is parsed. On voxa.host they are filtered upstream up to 100 Gbps, active from delivery, with nothing to switch on and no extra charge.

The network layer cannot judge a valid request: a flood of well formed HTTPS calls arrives over completed TLS sessions and looks like your busiest customer. Layer 7 filtering exists only on the 10 Tbps tier, so on every other tier HTTP floods are handled in your own stack.

There is also a cap. The first five attacks a month above 100 Gbps are still mitigated at no charge. From the sixth in the same month, the targeted IP address is null routed until the attack ends or the server is upgraded to a larger tier. Only that address goes dark, not the whole server.

Why is an API harder to protect than a website?

A brochure site survives a lot by caching every page. An API rarely can.

• Machine clients. Legitimate traffic is already scripts and SDKs, so an attacker's script differs from a customer's cron job only in its key and its pace.
• Personalised responses. Most calls return one account's data, so they bypass any shared cache and reach the database.
• Expensive endpoints. Search, exports, report generation, token issuance and inbound webhooks cost far more than a read. Login is expensive by design, because password hashing is deliberately slow.
• Long lived connections. Each websocket holds memory and a file descriptor for hours, so connections run out before bandwidth does.
• Clients that retry. When you slow down, well behaved clients send more traffic, not less.

To see the asymmetry, take an example export endpoint that needs 2 seconds of CPU per call. Fifty calls a second ask for 100 CPU seconds every second, or 100 cores flat out, from a few hundred kilobits a second that no network filter would call an attack.

Retry storms: when your own clients join in

As an example, take 2,000 integrations that each call you once every 10 seconds: 200 requests a second. A database stall pushes responses past the clients' 5 second timeout and every SDK retries three times straight away. Arrivals climb towards 800 a second just as the backend can serve fewer, so the incident outlives its cause. Nothing malicious happened, yet from the server's side a retry storm looks exactly like a flood.

How should you design an API so the edge takes the hit?

Only the edge, meaning your load balancer, reverse proxy or API gateway, should answer on a public address and appear in DNS. Application servers, databases and queues should be reachable only over a private network or an encrypted tunnel such as WireGuard, with every other port dropped by nftables.

Keep backend addresses hidden. Webhooks and email sent directly from an application server reveal its IP to every recipient, so route them through the edge. A leaked origin skips your rate limits entirely.

This layout also changes the bill. DDoS protection is priced per server and covers every IP address on that server, so you buy a larger tier only for the one or two exposed edges. As an example, two edges, four application servers and two database servers would pay €4,191.60 a month for the 1 Tbps tier on all eight, or €1,047.90 on the edges alone, while the private six keep the included 100 Gbps.

Which API rate limiting and controls do you need to build?

To protect an API from DDoS above the network layer, build these controls. They are listed roughly in order of payoff.

Per API key and per IP rate limits

Rate limit by API key for authenticated traffic and by IP for everything else, at the edge or API gateway, before application code runs. A token bucket per key (limit_req_zone keyed on a header in nginx, a stick-table in HAProxy) absorbs bursts without punishing steady clients. Reject unknown keys from an in memory cache, so a flood of random keys never touches the database.

Answer over limit requests with 429 and a Retry-After header. Give login, signup, password reset and token endpoints much tighter limits per IP and per account, because an attacker can call them without any key.

A cost budget per request class

Equal request counts are not equal load. Give each class a weight and each key a budget: for example a cached read costs 1 unit, a search 10 and an export 100, with 600 units a minute per key. That allows 600 reads or 6 exports a minute, so nobody can drown the cluster by picking the most expensive route. Measure the real weights with a load test in your CI pipeline.

Strict timeouts and body size limits

Slow request attacks hold connections open by sending a few bytes at a time. Set short header and body timeouts (client_header_timeout, client_body_timeout), cap body size per route with client_max_body_size, and give every upstream call a deadline shorter than your clients' timeout. For websockets, cap connections per IP and per key and close idle sockets.

Queue heavy work and shed load

Exports, reports and bulk imports should return 202 with a job ID and run on separate workers (see splitting background jobs off your web server), so a flood grows a queue instead of starving the request path. Wrap database and third party calls in circuit breakers so failures return fast instead of piling up threads, and shed low value traffic first so logins and payments keep working.

Cache what is public

Cache anonymous responses that are the same for every caller, such as public catalogues and pricing, at the edge. Even a one second cache turns ten thousand identical requests a second into one for the backend.

Retries in your client SDK

Ship client libraries that retry with exponential backoff and full jitter, honour Retry-After, and give up after a few attempts. Add a retry budget, for example retries capped at 10 percent of normal traffic, and idempotency keys on POST so a retried payment is not charged twice. It is the only control that stops retry storms at the source.

A status page hosted off site

Host your status page on its own domain, on a separate server in another location or with another provider. If it shares an address with the API, it vanishes exactly when customers look for it.

Which layer stops which threat?

Threat	Stopped by	What to configure
UDP reflection, amplification and SYN floods	Network, included 100 Gbps L3/L4	Nothing to switch on. Keep net.ipv4.tcp_syncookies on
Floods above 100 Gbps	Network: five a month free, then null route or a larger tier	A larger edge tier, a spare address
HTTPS request flood from many addresses	Your edge, or the 10 Tbps + Layer 7 tier	Per IP and per key limits, connection caps, micro cache
Login and token endpoint floods	Your edge and app	Tight limits per IP and per account
Search, export and report abuse	Your app	Cost budget per key, job queue, page size caps
Slow request attacks	Your edge	Header and body timeouts, body size limits
Websocket connection floods	Your edge	Connections per IP and per key, idle timeout
Retry storm from your own clients	Your SDK and app	Backoff with jitter, retry budget, circuit breakers
Attack on a leaked backend address	Your architecture	Private backends, egress through the edge

When is the 10 Tbps and Layer 7 tier worth it for an API business?

Prices are flat per server per month, exclude VAT and cover every IP address on that server, with no per attack fee. Pick a tier at checkout or change it later from the client area.

Tier	Layers	Per server, per month
100 Gbps	L3/L4	Included
500 Gbps	L3/L4	€156.45
1 Tbps	L3/L4	€523.95
2 Tbps	L3/L4	€1,048.95
5 Tbps	L3/L4	€2,623.95
10 Tbps + Layer 7	L3/L4/L7	€4,723.95

Layer 7 filtering helps against HTTP floods spread over so many addresses that each stays under your per IP limit. Like any DDoS protection for web applications, it cannot know that an export costs a hundred reads. It adds to your per key limits and cost budgets rather than replacing them.

As an example, two edge servers on the 10 Tbps + Layer 7 tier cost 2 × €4,723.95, which is €9,447.90 a month, against €1,047.90 on the 1 Tbps tier. The €8,400 difference is what HTTP filtering at the network has to be worth to you each month.

It pays off with a large anonymous surface (public signup, a free plan, unauthenticated search), or once HTTP floods have saturated your edge before your limits could act. It rarely does when nearly every call carries a key you can reject quickly, or your clients are known business integrations. Our guide on how much DDoS protection you need covers sizing the L3/L4 tiers.

How do you plan for a null routed API address?

Treat the null route that follows a sixth attack over 100 Gbps in a month as a known failure mode (null routing explained covers the mechanics). Three design choices make it a DNS change rather than an outage.

1. A spare address on the edge. Order an extra IPv4 address at checkout and keep it configured but unpublished. The tier covers every IP on the server, so the spare is protected too.
2. A second edge in another location. A standby edge that reaches your backends lets you move the hostname without a rebuild (see pairing two locations for failover).
3. Short TTLs and hostnames only. Keep the API record's TTL short, for example 60 to 300 seconds, and make sure SDKs and partners connect by hostname, never a hardcoded IP.

An attacker who resolves your hostname can follow you, so moving buys time. The durable answer to repeated large attacks is a larger tier on the edge.

Where to run an API edge and its backends

An API edge spends its CPU on TLS handshakes and connection handling, exactly what an HTTP flood consumes, so cores matter more than disk. A Single EPYC 9254 (24 cores, 128 GB DDR5 ECC) costs €449 a month, built to order. The Dual Xeon E5 2690 v4 (28 cores, €229) is delivered in under an hour. Both include a guaranteed 1 Gbps unmetered port and no setup fee.

Compare the full EPYC and Xeon dedicated range, then choose the tier for your edge servers on the DDoS protection page. Backends keep the included 100 Gbps.