L4 vs L7 Load Balancing
Layer 4 TCP/UDP forwarding vs Layer 7 HTTP routing, when to use each, and hybrid architectures.
Overview
Overview Load balancers are categorised by the OSI layer at which they make routing decisions. This determines what information they can use to route traffic and what overhead they introduce.
Layer 4 (L4) load balancers operate at the TCP/UDP level. They see source IP, destination IP, and port number but not the content of the payload. Routing decisions are made purely on connection-level metadata. The LB acts as a TCP proxy: it accepts the connection, forwards packets to a backend, and tracks the connection state for the duration of the session. Because it does not parse HTTP, it cannot route based on URL, headers, or cookies. L4 LBs are extremely fast (no protocol parsing) and support any TCP/UDP protocol.
Layer 7 (L7) load balancers operate at the HTTP level. They terminate the TLS connection, parse the HTTP request (URL, headers, body, method), and make routing decisions based on that content. This enables: path-based routing (/api to service-A, /static to CDN), host-based routing (api.example.com vs web.example.com), header-based routing (canary with X-Version: beta header), cookie-based sticky sessions. L7 LBs add latency (TLS termination, HTTP parsing, new connection to backend) and are limited to HTTP/HTTPS/gRPC/WebSocket.
In AWS: NLB (Network Load Balancer) = L4. ALB (Application Load Balancer) = L7. A common pattern is L4 NLB in front of L7 ALB for environments requiring static IPs (NLB has Elastic IPs) while still needing HTTP routing (ALB).
HAProxy and nginx support both L4 (stream block) and L7 (http block) mode in the same binary. Envoy Proxy (used in service meshes) operates at L7 with rich HTTP/gRPC routing and observability.
Key concepts
- L4 passthrough
- L4 LB forwards TCP/UDP packets without parsing the content. Backend sees the original connection (source IP preservation is possible). No TLS termination unless TLS passthrough is configured.
- L7 termination
- L7 LB terminates TLS and the TCP connection. Backend receives a new connection from the LB, not from the client. Source IP is sent via X-Forwarded-For header.
- Sticky sessions
- Routing subsequent requests from the same client to the same backend. L4: based on source IP hash. L7: based on a cookie the LB sets/reads. Breaks stateless assumptions.
- Health checks
- L4: TCP connection success. L7: HTTP 200 response from a specific path (/healthz). L7 health checks are more accurate but require HTTP parsing.
- Connection draining
- Before removing a backend, the LB waits for in-flight connections to complete (with a timeout). L7 LBs can drain gracefully at the request level; L4 drains at the connection level.
When to use it
- Choosing between ALB and NLB for a new AWS service
- Implementing blue-green or canary deployments using L7 routing rules
- Routing WebSocket connections that must stay on the same backend
- Exposing a non-HTTP service (SMTP, custom TCP protocol) through a load balancer
Interview questions
- How do you implement a canary deployment using an ALB?
Sign up free to read the full topic
More Networking topics
Start free on Cariara · Coding problems · System design studio