Least-connections load balancing selects an eligible backend with the smallest number of active connections when a new connection arrives. Unlike round-robin routing, which distributes assignments in a repeating sequence, it responds to changes in connection occupancy. If three equally capable servers have 80, 25, and 10 active connections, the next connection normally goes to the third server. Tie-breaking behavior depends on the implementation.
The algorithm is particularly useful for workloads with variable connection durations, such as persistent TCP sessions. Round robin can assign the same number of new connections to each server even while long-lived sessions accumulate unevenly. Least connections instead favors servers whose existing connections have finished. It does not move established connections between servers, so correcting an existing imbalance depends on connection turnover and new arrivals.
Connection count is only an approximation of load. A server with five computationally expensive connections can be busier than one with fifty mostly idle connections. HTTP keep-alive, connection pooling, and HTTP/2 multiplexing further weaken the relationship between connections and application work. One HTTP/2 connection can carry many concurrent requests. Consequently, least connections, least outstanding requests, and least response time are distinct algorithms, even though all attempt to improve distribution using runtime observations.
Cloud implementations must be checked individually. AWS Application Load Balancer offers least outstanding requests, not a configurable least-connections algorithm. Its routing decision concerns requests in progress rather than simply counting open connections. AWS Network Load Balancer uses flow-hash-based target selection rather than a user-selectable least-connections policy. Exam questions often test this distinction: a desirable general algorithm is not necessarily supported by the named service.
Backend eligibility matters as much as the algorithm. Health checks normally remove unhealthy targets from ordinary selection, subject to the load balancer's documented failure behavior. Cross-zone load balancing determines whether a load balancer node can select targets outside its own Availability Zone. Least connections then operates within the eligible selection scope; it does not automatically provide cross-zone routing or a globally synchronized view of every connection.
Session affinity can constrain load-aware selection because subsequent traffic may remain associated with an earlier target. Similarly, an established TCP connection stays on its selected backend regardless of later counter changes. During scale-out, newly added targets have few connections and can attract traffic rapidly. Validate readiness checks, connection limits, and any supported gradual traffic introduction before relying on this behavior. Weighted least-connections variants can account for unequal backend capacity, but weighting is implementation-specific.
Routing policy is separate from security and client identity handling. Proxy Protocol conveys connection metadata to compatible backends; it does not select the least-connected target or encrypt traffic. Configure compatible listeners and backend parsers, restrict backend access to trusted load balancer paths, and apply TLS and appropriate network controls independently. Validate the design using realistic connection lifetimes, backend resource utilization, latency, errors, and connection-draining behavior during deployments.