DDoS Protection Across Cloud Providers

Three Different Problems Wearing One Name

Denial of service is a category, not a technique, and the defences differ completely depending on which kind arrives. Grouping them correctly is the first step, because a control that stops one does nothing about another.

Volumetric attacks aim to fill the pipe. Amplified reflection using protocols such as DNS or NTP turns a small request into a large response aimed at you. Nothing running on your server helps here, since the saturation happens upstream of it. Only a network with capacity to absorb and filter the traffic can respond.

Protocol attacks exhaust connection state rather than bandwidth. A flood of half open handshakes consumes tracking resources on servers, firewalls and load balancers alike. Kernel level mitigations and stateless filtering at the edge are the answer.

Application attacks send requests that look legitimate and are expensive to serve: a search endpoint, a report generator, a login form. Traffic volume can be modest while the database falls over. This is the hardest category, because telling a real user from a fake one requires understanding the application.

What You Already Have Without Asking

Every serious provider filters some attack traffic before it reaches customers, because an attack on one tenant degrades the network for everyone. That baseline is usually not advertised loudly and is typically aimed at the volumetric and protocol categories.

What it does not include is application layer discrimination, because the provider has no idea which requests your service considers legitimate. It also does not include any commitment about how a sustained attack against one address will be handled.

That last point deserves attention. On some budget platforms, the mitigation for a large attack against a single address is to stop routing that address entirely. The rest of the network is protected and your service is offline, which is a perfectly rational policy that you should know about before it happens rather than during.

What the Platforms Offer

A pattern emerges from that table. Baseline filtering handles the crude attacks, and anything application aware is a separate product you configure. AWS sets out the split clearly in its Shield documentation.

The other common answer is to put a content delivery and security edge in front of whatever you run. A proxied edge terminates connections far from your origin, absorbs floods across a large anycast network and applies rules before traffic ever heads toward your servers. Cloudflare's learning material on attack types is a readable primer on the mechanics.

Design Choices That Absorb Pressure

Most of the resilience comes from architecture rather than from a product purchase.

Put something in front. A CDN serving cached content answers a large share of requests without touching your origin at all, and the caching mechanics are covered in CDN basics for cloud-hosted sites. Static assets served from the edge are requests your application never sees.

Then hide the origin. An edge service is worthless if attackers can find and target your server address directly. Configure the instance firewall to accept traffic only from the edge provider's published address ranges, and make sure historical DNS records, mail headers and error pages are not still advertising the real address. The firewall layers involved are described in cloud firewalls and security groups.

Spread the load. A load balancer with several backends removes the single target, and health checks keep traffic away from an instance that is struggling. The distinction between connection level and request level balancing matters here, because only the latter can make decisions based on what is being requested.

Treat automatic scaling carefully. It can absorb a surge, and it can also convert an availability problem into a bill by faithfully provisioning capacity to serve an attack. Set a maximum you are willing to pay for, as discussed in autoscaling explained.

Defending the Expensive Endpoints

Application floods are defeated by making abuse costly and legitimate use cheap.

Rate limiting is the primary tool. A web application firewall can apply limits per address or per token, and a reverse proxy can do a reasonable job on its own. In Nginx, limit_req_zone plus a matching limit_req directive caps request rate for a location, while limit_conn caps simultaneous connections from one source. Apply them tightly on login, search and anything that generates a report, and loosely elsewhere.

Cache aggressively at the edge. An endpoint whose response can be served from cache for even a few seconds stops being an amplifier for your database.

Fail cheaply. When a dependency is overloaded, returning a small cached response or a short error is far better than queueing requests until the whole service becomes unresponsive. Timeouts on every outbound call and a circuit breaker around slow dependencies prevent one bottleneck from consuming every worker.

Protect anything that costs you money to serve: password hashing on login, email sending, file conversion, model inference. These are the endpoints an attacker finds by reading your site, and a modest request rate against them is enough to cause real damage.

What to Have Ready Before It Starts

During an attack the immediate problem is usually not technical, it is that nobody knows who decides what. A short written runbook fixes most of that.

Record how to reach your provider's support channel and what information they will ask for, including account identifiers and the affected addresses. Know in advance whether your plan includes assistance and what the escalation path is, since discovering the answer mid incident wastes the first hour.

Keep the tightened configuration prepared rather than improvised: stricter rate limits, a challenge mode at the edge, a static holding page, and a documented way to switch the origin address if it has been exposed. Rehearse the switch so it is a known procedure rather than a first attempt.

Make sure your monitoring distinguishes an attack from a marketing success. Request rate, error rate, connection counts and upstream latency together tell you which you are looking at, and the collection approach in monitoring cloud servers is the foundation for that judgement.

Finally, log to somewhere that survives the incident. If your only record of an attack is on a machine that fell over, the review afterwards has nothing to work with.

A Reasonable Posture

• Know which of the three attack categories each of your defences addresses.
• Read the provider's policy on sustained attacks, especially whether addresses get withdrawn.
• Serve through an edge or CDN so most requests never reach the origin.
• Restrict the origin firewall to the edge provider's ranges and stop advertising the real address.
• Rate limit the endpoints that are expensive to serve, not the whole site equally.
• Cap autoscaling so an attack cannot become an unbounded bill.
• Write the response runbook, including provider contacts, before you need it.
• Ship logs off the machine so the post mortem has evidence.

Providers differ most in what they include as standard. The OVHcloud account listings describe an account on a network with anti-DDoS filtering built in, and the Hetzner versus OVHcloud comparison looks at how the two European platforms present network protection.