Layer 4 Load Balancing

The name comes from the OSI model. Layer 4 is the transport layer, where TCP and UDP live. A Layer 4 load balancer makes its routing decision using the four or five values it can see in the packet headers: source IP, source port, destination IP, destination port, and the protocol. That set is often called the connection 5-tuple.

Because it works at this level, it has no idea whether the traffic is HTTP, gRPC, a MySQL query, an MQTT message, or a video stream. It treats every connection as an opaque flow of bytes. This is the key difference from Layer 7 load balancing, which terminates the connection, reads the full HTTP request, and can route based on the URL path, host header, or cookie.

A common way to picture it: a Layer 4 balancer is a smart switchboard that connects caller to agent based on the number dialed, without ever listening to the conversation.

There are two main modes. In NAT mode, the balancer rewrites the destination IP of each incoming packet to a chosen backend, forwards it, and rewrites the source IP on the way back so the client only ever sees the balancer's address. The balancer keeps a connection table mapping each 5-tuple to a backend so all packets in a flow land on the same server.

In Direct Server Return mode, the balancer only rewrites the destination MAC address and forwards the packet. The backend then replies straight to the client, bypassing the balancer entirely. This skips the return-path bottleneck and lets one balancer handle far more throughput, which is why high-volume CDNs and stream services prefer it.

Backend selection usually uses a consistent hash of the 5-tuple so the same client connection keeps hitting the same server, or simple round robin and least-connections for new flows. There is no TLS termination and no buffering, so a Layer 4 balancer can push millions of packets per second on commodity hardware while adding well under a millisecond of latency.

Reach for Layer 4 when you need raw speed and protocol independence: database connection pools, game servers over UDP, MQTT brokers, SMTP, or any non-HTTP TCP service. It also shines as the first tier in front of a fleet of Layer 7 proxies, absorbing huge connection volume cheaply before handing off the smart routing.

The cost of that speed is blindness. You cannot route by URL path, do host-based virtual hosting, rewrite headers, terminate TLS, or do content-aware health checks. A Layer 4 health check can confirm a TCP port is open, but it cannot tell you the app behind it is returning 500 errors.

Sticky sessions are coarser too. Stickiness is per source IP or per 5-tuple, so thousands of users behind one corporate NAT or mobile carrier gateway can all hash to the same backend, creating hot spots. If you need cookie-level affinity or path routing, you want Layer 7, often layered behind Layer 4.

AWS gives you both flavors as separate products, which makes the distinction obvious. The Network Load Balancer is a pure Layer 4 device that handles millions of requests per second at ultra-low latency and preserves the client source IP. The Application Load Balancer is Layer 7 and routes on paths and host headers but is heavier.

Many large architectures stack them. Cloudflare and Google both run Layer 4 software balancers (Google's Maglev, Cloudflare's Unimog) at the network edge to spread connections across many machines, and those machines then run Layer 7 proxies for the actual HTTP logic. The Layer 4 tier does the cheap, fast spreading; the Layer 7 tier does the smart routing.