A load balancer distributes incoming requests across several servers so no single machine has to carry the full load alone.
It can also end encrypted sessions, check which servers are healthy, and hide the individual machines from the public address.
How it works
Algorithms send the next request to the least busy server, stick a user to one server for a session, or simply walk through the pool in order.
Health checks remove a server that stops answering so clients are not handed a machine that is already down.
Because many designs place the balancer on the forwarding path, its failure or misconfiguration becomes an outage for every server behind it.
From a security view it is also a place to enforce which traffic may pass, and a place attackers will probe because it fronts the application.
Concrete examples
- A retail site keeps checkout available when one of four application servers fails its health check and is removed from the pool.
- Administrative pages are published only on an internal balancer address that is not resolvable from the public internet.
- A configuration error sends all sessions to one server, which then exhausts memory while the other three sit idle.
Protective measures
- Run at least two balancers and test failover so a single device is not the whole site.
- Restrict management interfaces to an administration network and require strong authentication there.
- Alert when one server receives a sudden share of traffic that the policy did not intend.
- Review which headers and client addresses you forward so logs behind the balancer still identify the real source.