Running more than one server behind a service raises an immediate question: which server handles each incoming request? A load balancer answers that question, and the level of the network stack it operates at — layer 4 or layer 7 — determines how smart that decision can be.
What a load balancer actually does
A load balancer sits in front of a pool of backend servers and distributes incoming requests across them according to some algorithm — round robin, least connections, or something more sophisticated — so that traffic is spread out and no single server is overwhelmed while others sit idle. It also typically performs health checks, routing traffic away from servers that stop responding correctly, which makes it a key piece of the resilience story alongside the availability-zone architecture covered in Regions, Availability Zones, and Why Cloud Architecture Is Geographic: distributing servers across zones only helps if traffic actually gets rerouted away from a failed zone, and that rerouting is exactly what a load balancer’s health checks are for.
Layer 4: fast, simple, protocol-agnostic
Layer 4 refers to the transport layer of the OSI networking model — the level at which TCP and UDP operate. A layer 4 load balancer makes routing decisions based only on network-level information: source and destination IP addresses and ports. It doesn’t inspect the actual content of the request at all.
This makes layer 4 load balancing fast and computationally cheap, since there’s comparatively little for the load balancer to examine before making a routing decision, and it works for any protocol running over TCP or UDP, not just HTTP. The trade-off is that it can’t make any decision based on what’s actually inside the request — it has no visibility into a URL path, an HTTP header, or a cookie, because it never looks past the transport-layer information.
Layer 7: application-aware, more capable, more overhead
Layer 7 refers to the application layer — the level at which protocols like HTTP operate. A layer 7 load balancer terminates and actually reads the application-level request: the URL path, headers, cookies, and other content. Cloud providers describe this distinction directly; see, for example, AWS’s overview of load balancing, Google Cloud’s load balancing overview, and NGINX’s explanation of layer 4 versus layer 7 load balancing.
That visibility enables routing decisions layer 4 simply can’t make: sending requests for /api/ to one backend pool and /images/ to another, routing based on a cookie to keep a user’s session on the same backend, or making decisions based on the actual HTTP method or header content. This capability comes at a real cost: reading and processing the full application-level request takes more computational work than inspecting transport-level headers alone, which generally makes layer 7 load balancing somewhat slower and more resource-intensive per request than layer 4.
Choosing between them
In practice, many systems use both, at different points: a layer 4 load balancer handling the outermost, highest-volume traffic distribution, with layer 7 load balancing applied where its application-level routing intelligence is actually needed — often closer to the application itself, or wherever a service mesh is managing traffic between internal services. Choosing purely layer 4 when you need content-based routing simply won’t work; choosing layer 7 everywhere by default, when transport-level routing would do, adds latency and cost without a corresponding benefit.
Why this matters for deployment strategy
Layer 7’s ability to route based on request content is what makes fine-grained traffic-shifting techniques practical — sending a specific percentage of requests, or requests matching a specific header, to a new version of a service, which is exactly the mechanism behind canary releases covered in Blue-Green and Canary Deployments. A purely layer 4 setup can still shift traffic between backend pools, but it can’t make that decision based on anything about the request itself.
Key takeaway
Layer 4 load balancing is fast and protocol-agnostic but blind to request content; layer 7 load balancing reads the actual application request and can route far more intelligently, at the cost of additional processing overhead. Most real systems use the two at different points in their architecture rather than treating the choice as all-or-nothing.
This article explains general networking concepts; specific load balancer features and performance characteristics vary by provider and product. See our disclaimer.