In security discussions, the term DDoS is often used as if it referred to a single type of threat. In reality, today it covers two very different strategies that share the same goal but not the same execution: volumetric attacks at layers L3/L4 and application exhaustion attacks at layer 7.

Both aim to take a service offline, but they exploit different parts of the infrastructure — and therefore require different mitigation layers.

Two attack families, two impact surfaces

When some vendors claim that “modern DDoS attacks are stealthy and bypass traditional defences”, what they are actually describing is not classic volumetric DDoS, but L7 exhaustion: low-rate traffic, fully valid requests, almost indistinguishable from legitimate clients.

These attacks don’t flood the network — they drain the application from inside.

That doesn’t mean volumetric DDoS has disappeared. It remains cheap to launch, common in the wild, and extremely effective unless it is filtered before the kernel, firewall, or load balancer accepts the connections.

The threat has not changed — the point of mitigation has.

Type Layer Objective How the service breaks
Volumetric DDoS L3 / L4 Saturate bandwidth, connection tables, kernel resources The infrastructure collapses before the application can respond
Application-layer DoS L7 Exhaust CPU, memory, threads, or DB calls The service is “up”, but unusable for real users

Or, even more directly:

  • L3/L4 volumetric attacks → try to take down the network before the service responds
  • L7 exhaustion attacks → mimic valid traffic to drain the app’s internal resources

Layered defence: why L3/L4 and L7 do not compete — they complement each other

One of the most common misconceptions is assuming that a single protection layer is enough to stop any kind of attack. In practice, filtering only at layer 4 leaves the application exposed, while filtering only at layer 7 allows the kernel or load balancer to be overwhelmed before the WAF ever sees the request.

An L4 firewall can drop malformed packets or abnormal connection patterns before they consume resources, but it has no context to detect that a perfectly valid HTTP request is trying to exploit an SQLi pattern.

A WAF can detect that behaviour — but only after the connection has already been accepted, a socket has been created, and memory has been allocated.

Attack type Where it must be stopped What is inspected Typical tooling
Volumetric (L3/L4) Before accepting the connection (edge / kernel / LB) Packets, TCP flags, connection rate SYN flood protection, rate limiting, conntrack offload
Application exhaustion (L7) Once the TCP session is established HTTP headers, URL patterns, payload TWAF, OWASP rulesets, bot filtering

Effective protection is not about choosing the right layer — it is about dropping as much as possible before the app, and reserving deep inspection only for what deserves to reach it.

What happens when mitigation only works at L7 (and why it fails)

When protection is applied solely at the application layer, the TCP connection has already been accepted before any evaluation occurs. In other words, the system has completed the handshake, allocated a socket, reserved memory and promoted the session to HTTP/S before deciding whether the request should be blocked.

That removes the attacker’s need to generate massive traffic: a few thousand seemingly valid, slow, or incomplete connections are enough to consume server resources without ever saturating the network.

The result is not an immediate outage, but a progressive exhaustion:

    • Load balancer or backend CPU spikes
    • Response times increase exponentially
    • The service is still “up”, but unusable for legitimate users

This is the usual pattern of L7 exhaustion attacks: they don’t bring the network down; they wear the application out from the inside. And it happens for a simple reason: the blocking decision is made too late. First the connection is accepted, then the request is inspected, and only at the end is it decided whether to discard it. By then, the damage is already done.

How SkudoCloud applies two-phase mitigation

Effective protection against DDoS and exhaustion attacks is not about choosing between filtering at L4 or L7, but about enforcing both defenses in the right order. SkudoCloud implements this model natively inside the load-balancing engine itself, without relying on external scrubbing services or additional appliances.

Phase What is mitigated How SkudoCloud acts Where it happens
1. Early filtering (L4) TCP floods, anomalous connections, malformed packets Session rejected before allocation, per-IP/VIP limits, SYN protection, IP reputation / blocklists Load balancer kernel
2. Deep inspection (L7) SQLi, XSS, bots, valid-but-abusive requests Advanced WAF + behavioural rules HTTP/S module of the engine

This model ensures that high-volume traffic cannot saturate the system before being analysed, and that low-volume abusive requests cannot hide inside seemingly legitimate sessions. The result is an environment where the network does not collapse under load and the application does not degrade due to resource exhaustion.

Everything is managed from a single interface, with unified policies, metrics and event logging — without depending on multiple vendors, external mitigation layers or duplicated configurations.

👉 To see how this model works in a real deployment, follow the step-by-step guide: Configure the First SkudoCloud Service