Volumetric attacks: filling the link

That last row is the honest answer and the reason this category is documented separately. The mechanism behind it is on attack layers.

A link has a fixed capacity. When arriving traffic exceeds it, the excess is discarded somewhere upstream, and the discarding does not distinguish between an attack and a customer. Legitimate requests are dropped in the same proportion as everything else, which is why the site becomes unreachable rather than slow.

Nothing has to be exploited for this to work. No vulnerability, no malformed packet, no clever request. The attack succeeds by arithmetic, and the only variable that matters is whether the attacker can generate more traffic than the target can absorb.

The arithmetic changes when an attacker does not have to send the traffic themselves.

Certain services answer a small request with a much larger response. If the request carries a forged source address, the response is delivered to that address instead of to the sender. The attacker sends a little; the service sends a lot; the victim receives all of it. The ratio between the two is what makes this the dominant technique in the category.

Two properties follow, and both matter for defence.

The traffic comes from legitimate servers. The machines flooding you are not compromised, and they are doing what they were designed to do. Blocking them by address is endless, because there are always more.

Forged source addresses are the enabling condition. Networks that verify traffic leaves them with addresses they own remove the possibility at the source. That is a property of other people's networks rather than of yours, which is why the technique persists.

One vector deliberately sits elsewhere. Amplification through the domain name system belongs with the naming layer of this network, where the record types and the resolver behaviour that make it possible are already explained, and duplicating it here would describe the same mechanism twice in two places.

Capacity is usually described in bits per second, and that single figure hides a second limit.

Equipment that handles traffic also has a ceiling on how many packets it can process each second, independent of how large those packets are. An attack made of very small packets can reach that ceiling while the bandwidth figure still looks comfortable. The link is not full; the device forwarding traffic across it is.

The practical consequence is that "we have plenty of bandwidth" is not by itself an answer. Where an outage happens well below the nominal capacity of a connection, the packet rate is the thing to look at, and the bottleneck is a router or firewall rather than the pipe.

The signature of this category is what you cannot see.

Your own monitoring goes quiet. Graphs stop updating because the data cannot get out over a saturated link. An absence of information during an outage is itself a signal.

Upstream sees traffic you never do. Whoever provides your connectivity can tell you the arriving volume and its shape. That conversation is the fastest way to confirm the category, and it is often the only source of evidence.

Application logs look normal, then stop. No error pattern, no unusual requests, just fewer entries and then none. Compare this with an application-layer attack, where logs fill rather than empty.

Recovery is not automatic, and two effects catch people out.

Clients that failed during the outage retry, often all at once and often more aggressively than normal traffic. The first minutes after the flood subsides can carry a load spike that has nothing to do with the attacker.

And whatever was blocked during the incident stays blocked until someone removes it. Emergency filters are written under pressure, applied broadly, and forgotten, which turns a finished attack into a quiet loss of legitimate traffic that shows up weeks later as an unexplained drop.

Three things work, and they sit in a specific order.

Capacity upstream. Absorbing the traffic requires more capacity than the attack generates. This is the only defence that addresses the mechanism directly, and it is infrastructure rather than configuration.

Filtering before your link. Traffic can be dropped by whoever carries it, based on properties visible in packets. Coarse but effective, and it must happen upstream to matter: filtering on your own equipment discards traffic that has already consumed the resource it was targeting.

Not being the reflector. Services that answer unauthenticated queries should not be reachable from the whole internet. This does not protect you from being a victim; it stops your servers from becoming the source of someone else's attack, which is a responsibility rather than a defence.

What does not work is anything applied at the application: rules, challenges, and request limits all operate on requests that, in this category, were never made.

Bridge WAF inspects requests at the application layer, which is the wrong layer for this family and is stated plainly for that reason. What does apply is where traffic terminates: when requests are served from the platform's edge rather than from your origin, the capacity in front of you is the platform's, and your origin's link stops being the constraint that a volumetric attack targets. Which component covers which layer is a fair question to ask any provider. See what the platform offers at Bridge CDN.