Layer 7 DDoS Mitigation: Why Bandwidth Doesn't Save You

Layer 3/4 DDoS attacks flood your network pipe with raw traffic measured in Gbps, and scrubbing capacity plus bandwidth is what stops them. Layer 7 attacks flood your application with requests that look like real visitors, measured in requests per second, and they take down small sites with a fraction of the bandwidth because they exhaust PHP workers, database connections and CPU rather than the network itself. Most hosting sales pages only defend against the first kind.

What actually separates layer 3/4 attacks from layer 7 attacks?

The OSI model has seven layers, but for DDoS purposes only two matter to you as a site owner. Layers 3 and 4 are the network and transport layers, the plumbing that moves packets around. An attack here is a volumetric flood: SYN floods, UDP floods, ICMP floods, all designed to saturate your connection or exhaust the connection tables on your firewall and load balancer before a single request reaches your application code.

Layer 7 is the application layer, where HTTP requests actually get processed by your web server, your PHP-FPM workers, your database. An L7 attack doesn't try to fill the pipe. It sends what looks like legitimate traffic, real browser headers, real cookies, sometimes even solved JavaScript challenges, and just keeps hammering an expensive endpoint like a search page or a login form until your server runs out of resources to serve genuine visitors.

How does a volumetric flood actually take down a server?

Volumetric attacks are a numbers game measured in gigabits or terabits per second. The attacker isn't trying to be clever, they're trying to fill every bit of bandwidth your host allocates to you so legitimate packets simply can't get through. This is why hosts love quoting network capacity figures: volumetric mitigation genuinely is about scale, and more scrubbing capacity upstream means more attack traffic gets absorbed before it reaches your server.

The problem is that raw capacity says nothing about what happens once traffic gets past the network layer. A provider can have enormous inbound capacity and still let every single packet that survives filtering hit your web server directly, with no inspection of whether the HTTP request behind it is genuine.

What makes an application layer flood so hard to spot?

This is the part most hosting documentation glosses over. An application layer DDoS attack doesn't need much bandwidth at all. A few hundred requests per second aimed at a slow WordPress search query or an unauthenticated API endpoint can bring a modest VPS to its knees, because each request forces a database query or spins up a PHP worker, and workers are finite. Volumetric protection measured in Gbps won't even register this as unusual traffic, because in raw bandwidth terms it isn't.

The traffic often comes from thousands of distinct residential IPs via botnets, uses real browser user agents, and arrives at a rate that looks plausible for a busy day. Without behavioural analysis or rate limiting tied to specific endpoints, this traffic sails straight past network-level defences and lands on your application, which is exactly where it does the damage. This is also why site speed tanks under an L7 attack well before anyone notices the network graphs look unusual: the bottleneck is workers and queries, not bandwidth.

Where does DNS amplification fit into this?

DNS amplification is a specific and very common reflection attack that sits in the volumetric category but deserves its own mention, because it's still one of the cheapest ways to hurt a site. The attacker spoofs your IP address and sends small DNS queries to open resolvers, requesting large records. The resolvers dutifully send the big responses to your IP, not theirs, and a small request becomes a much larger flood aimed at your server. It's the same trick used against NTP and memcached servers, and it's covered well in the technical background on amplification and denial-of-service behaviour in RFC 4732.

DNS amplification is why gaming and streaming infrastructure gets hit constantly, since UDP-based protocols are easy to spoof and amplify. If you're running anything latency sensitive, read how this plays out specifically for real-time services in our guide to game server hosting and DDoS exposure.

Why does a host's Tbps marketing number tell you nothing about L7 protection?

This is the single most useful distinction in the whole topic, and the one hosting sales pages deliberately blur. A provider can genuinely have several terabits of scrubbing capacity, built for absorbing volumetric floods aimed at large infrastructure, and have zero meaningful protection against a slow, low-bandwidth application layer attack. These are different problems solved by different tools. Volumetric defence is about upstream network capacity and traffic scrubbing. L7 defence is about a web application firewall that understands HTTP behaviour, rate limits specific endpoints, challenges suspicious clients, and can tell the difference between a genuine visitor and a bot mimicking one.

If a host's marketing page leads entirely with a big bandwidth number and says nothing about request-level filtering, bot detection or WAF rules, assume they have no real L7 story. Ask directly rather than inferring it from a Tbps figure that has nothing to do with the attack actually likely to take a small site offline.

What questions should you ask a host about DDoS mitigation?

Skip the marketing copy and ask specific questions. Does mitigation happen automatically, or do you have to open a support ticket while your site is already down? Is there a separate layer for application-level filtering, or is protection purely network level? Can you set custom rate limits on specific paths like login and search? Is there a CDN layer in front of origin, and does it absorb attack traffic before it reaches your actual server, or just cache static assets?

Also ask what happens to legitimate traffic during mitigation. Some cheap mitigation is really just "null route everything," which stops the attack by also stopping your site. Good mitigation should be selective. If you're comparing providers properly, our hosting directory lists which hosts publish real detail on this rather than vague reassurance, and our security section breaks down what a proper WAF and mitigation stack actually looks like in practice.

What should you look for in a status page history?

A provider's public status page tells you more than any sales page. Look for incidents explicitly labelled as DDoS mitigation events, not just "network issues" or "degraded performance," which is often the same thing described vaguely. Check how long incidents lasted and whether the resolution note mentions specific action taken, such as filtering rules or upstream scrubbing, rather than generic language about "monitoring the situation."

Frequent short DDoS-related incidents that resolve in minutes suggest active, automated mitigation working as intended. Rare but long outages described as network problems, with no DDoS mention at all, can mean either genuinely low attack volume or a host that doesn't disclose incidents honestly. Cross reference against independent uptime monitoring if you can, rather than trusting the host's own dashboard as the sole source.

How do you actually defend a small site against layer 7 floods?

Start with a CDN and WAF combination in front of origin, since this filters obvious bot traffic and absorbs cached requests before they ever touch your server. Set rate limits on expensive endpoints specifically, not just globally, since a global limit loose enough to let real users through is often loose enough to let an L7 flood through too. If you're on shared hosting, understand that your neighbours' PHP workers and yours often share the same pool, so an attack on someone else's site on the same server can degrade yours.

Moving to a properly isolated VPS gives you dedicated resources and the ability to configure your own rate limiting and firewall rules, rather than relying on shared, one-size-fits-all protection. If you're weighing that move against cloud infrastructure, our piece on cloud hosting versus VPS covers how isolation and scaling actually differ between the two when handling traffic spikes, malicious or otherwise.

Frequently asked questions

Does a CDN alone stop layer 7 DDoS attacks?

A CDN helps by absorbing cached, static requests and hiding your origin IP, but it doesn't automatically stop application layer attacks aimed at dynamic, uncached endpoints like login forms or search. You need a WAF with rate limiting and bot detection layered on top, not a CDN alone.

Is DDoS protection included free with most hosting plans?

Basic network-level filtering against small volumetric attacks is often included, but meaningful application layer protection with custom rate limiting and bot challenges is usually a paid add-on or restricted to higher tier plans. Read the specific plan documentation rather than assuming "DDoS protection included" covers layer 7.

Can a VPS survive a DDoS attack without a WAF?

A VPS can survive a small volumetric flood if the provider's network filters it upstream, but an application layer attack aimed directly at your web server will still exhaust your PHP workers and database connections without a WAF or application-level rate limiting in place, regardless of how much raw compute the VPS has.

How is DNS amplification different from a typical application layer attack?

DNS amplification is a volumetric, reflection-based attack that abuses open DNS resolvers to flood your server with traffic far larger than the attacker's original request, measured in bandwidth. An application layer attack sends comparatively little traffic but targets your server's processing capacity directly, measured in requests per second rather than bandwidth.