A load balancer works by spreading incoming connections across a pool of backend servers, rather than by adding capacity of its own. That distinction is the whole of how it behaves under a flood, and putting it under one is a core part of a DDoS test. It sits in front of the backend pool, spreads connections across the healthy nodes, and removes failed ones from rotation through health checks. In DDoS terms it is a defensive layer that can absorb load by fanning traffic across capacity, and a chokepoint that can fail before any backend is touched.
How a load balancer distributes load
Where it makes its decision determines what it costs. A Layer 4 network load balancer works at the connection level: it picks a backend for each new flow and forwards packets, holding only enough state to keep a connection pinned to its node. A Layer 7 application load balancer or reverse proxy works at the request level, terminating the client connection, often terminating TLS with it, parsing the request, and opening its own connection to a backend. The L7 model can route on paths and headers and shield backends from raw connections, but it pays for that with far more state and CPU per client.
The algorithm it uses to pick a node matters more under attack than at rest. Round-robin spreads connections evenly regardless of what they are, so a flood is smeared across the whole pool. Least-connections sends the next request to the node holding the fewest, which sounds fairer but can steer a burst of cheap-to-open, expensive-to-serve attack connections at whichever node just freed a slot. Sticky sessions, which pin a client to one backend for the life of a session, can concentrate an attacker who holds a session open onto a single node while the rest sit idle.
Health checks sit underneath all of it. The balancer probes each backend and pulls unhealthy nodes out of rotation so traffic only goes where it can be served. That logic is a strength at steady state and a liability under load, because the probe is only a heuristic for whether a node can take more work.
Why it becomes the layer of first failure
A load balancer is often assumed to be pure spare capacity, but it holds finite resources of its own, and a flood spends those first. Its connection or session table has a hard ceiling, and under a connection flood that table fills while the backends behind it sit almost idle. On an L7 balancer, TLS termination burns CPU on every handshake, so a flood of new TLS connections exhausts the front node before any request is even parsed, the same crypto-cost pressure a conntrack exhaustion event applies to a firewall.
Health checks add a failure mode of their own. When a backend slows under partial load, its probe fails, the balancer pulls it, and the remaining nodes each take a larger share, which pushes the next one over. That cascade can empty a healthy pool exactly when it is needed most. And because the balancer distributes rather than adds, it cannot conjure headroom the way an autoscaler is meant to.
What a DDoS test measures
A test finds where the ceiling actually is, and which component owns it. It drives connections at a rising rate and measures the concurrent-connection limit the balancer holds before a new legitimate connection is refused, the connection setup rate it can sustain, and the TLS handshake throughput of the front node. Those are usually smaller numbers than the datasheet bandwidth, and one of them is the real capacity of the system.
It also watches the health checks under partial load, because a balancer that flaps nodes in and out during an attack turns a survivable event into an outage. Separating a state-bound ceiling from a bandwidth-bound one, and finding where it sits without taking production down in the process, is one of several things DDoS resilience testing sets out to isolate.