Layer 4 vs Layer 7 Load Balancers: When to Use Each

Load balancers come in two main flavors: Layer 4 and Layer 7. The OSI model labels are technical, but the practical difference is what each one knows about and what it can do with the traffic flowing through it. Picking the right one — sometimes both — is a real decision that shapes performance, observability, and the features your application can use.

This post is what each layer actually does, the cases where each fits, and the patterns where both work together.

What the Layers Are

The OSI model gives us layer numbers:

• Layer 4 (Transport): TCP, UDP. The load balancer sees connections and packets but does not decode the protocol above.
• Layer 7 (Application): HTTP, gRPC, WebSocket. The load balancer parses the application protocol and can make decisions based on headers, paths, methods, etc.

In cloud terms:

• AWS NLB (Network Load Balancer): Layer 4. Routes TCP and UDP without decoding HTTP.
• AWS ALB (Application Load Balancer): Layer 7. Routes HTTP and HTTP/2 with header awareness.
• GCP TCP/UDP Load Balancer: Layer 4.
• GCP HTTP(S) Load Balancer: Layer 7.

Other vendors follow the same pattern. The naming and exact features vary, but the L4/L7 distinction is universal.

What L4 Can Do

A Layer 4 load balancer sees:

• Source and destination IPs
• Ports
• TCP/UDP packet contents (as opaque bytes)

It can:

• Forward traffic to backend instances based on connection-level rules
• Distribute load across backends (round-robin, least connections, hash-based)
• Preserve client IP via Proxy Protocol
• Handle TCP-level health checks

It cannot:

• Read HTTP headers
• Route based on URL paths
• Terminate TLS (unless given the certificate, but it does not parse what is inside)
• Make decisions based on application content

What L7 Can Do

A Layer 7 load balancer parses the application protocol. It can:

• Route based on URL path (/api/* to one backend, /static/* to another)
• Route based on headers (host header, user agent, etc.)
• Terminate TLS and present a clean certificate
• Inspect and modify request/response headers
• Apply per-route rate limits
• Handle HTTP/2 multiplexing (multiple requests on one TCP connection)
• Run middleware (authentication, rate limiting, header transformation)
• Generate access logs with HTTP semantics

The cost: it has to actually parse the protocol, which adds CPU and a small latency penalty.

Performance Comparison

L4 is faster. Per-connection overhead is lower. For workloads where every microsecond matters (high-frequency trading, real-time gaming), L4 is often the only acceptable choice.

L7 adds latency in the single-digit milliseconds for the parsing and routing logic. For most web applications, this is negligible. For latency-sensitive backends, it matters.

For throughput: both can handle very high volume. L4 is somewhat more efficient per CPU; L7 trades CPU for features.

When to Use Each

Use L4 when:

• The protocol is not HTTP (raw TCP, custom protocols, UDP-based services)
• Latency is the dominant concern
• You only need connection-level load balancing
• The backend handles all the protocol semantics

Use L7 when:

• The protocol is HTTP/HTTPS
• You need path-based or header-based routing
• TLS termination at the load balancer simplifies the backend
• You want middleware features (auth, rate limit, etc.) at the load balancer

For most web applications, L7 is the right default. The features pay back the small performance overhead.

Common Combinations

Most production setups use both, layered:

Internet
   │
   ▼
NLB (L4) — handles TCP/UDP, very fast
   │
   ▼
ALB (L7) — handles HTTP, path routing, TLS termination
   │
   ▼
Application servers

The L4 at the edge handles the raw traffic. The L7 inside handles the HTTP routing. AWS GAS (Global Accelerator) is sometimes layered on top of this for even better anycast performance.

Why both? Sometimes:

• The L4 provides a stable IP that DNS can point at (useful for clients that resolve and cache IPs).
• The L7 provides the application-level features.
• Combining them avoids tradeoffs.

For many setups, just an L7 LB is sufficient. The two-layer pattern is optimization for specific needs.

TLS Termination

A big decision: where does TLS terminate?

At the L7 LB: Common. The LB has the certificate; backends speak plain HTTP. Simplifies backend configuration. Visible HTTP traffic for the LB to route on.

Pass-through to backend: L4 forwards the TLS-wrapped TCP connection unchanged. Backend handles TLS. Backend sees real client IPs and unencrypted data.

Both: Some setups terminate TLS at the LB, then re-encrypt to the backend. Maximum visibility plus encrypted backend traffic.

For internal services, pass-through with backend TLS makes sense (mutual TLS, application-level cert handling). For external services, terminating at the LB is usually right (simpler backend, easier cert management).

Health Checks

L4 health checks: TCP connect to a port. The port answers; it's healthy. The port refuses; it's unhealthy.

L7 health checks: HTTP request to a specific path. Healthy means a 200 response (or whatever you configure).

L7 health checks are dramatically better:

• A backend that has booted but is not ready (still warming up) can return 503 on health checks until ready
• A backend that has a degraded dependency can fail health checks before its traffic suffers
• The health check path can include real liveness logic (database connectivity, etc.)

For any HTTP backend: use L7 health checks. The L4-only "did the port answer" check is too coarse.

Sticky Sessions and Affinity

Some applications need session affinity — requests from the same user routed to the same backend. Patterns:

L4 hashing: Hash by source IP. All requests from one IP go to one backend. Works but coarse — many users share an IP.

L7 cookies: The LB sets a cookie pinning the user to a backend. Works well for HTTP-only.

Application-level: Store session state in a shared cache (Redis). Backends are stateless; affinity is unnecessary.

The application-level pattern is the right modern answer. Affinity at the LB is a workaround for stateful backends; stateless backends do not need it.

Connection Limits and Concurrency

L4 LBs care about connections. L7 LBs care about both connections and requests (multiple requests per HTTP/2 connection).

For load-testing and capacity planning, knowing what each measures matters:

• L4 max connections might be 1M. Each TCP connection counts.
• L7 max RPS might be 100K. Each HTTP request counts, even multiple requests on one connection.

A connection-heavy workload (WebSocket, gRPC streaming) sees different limits than a request-heavy workload (REST API).

Cost

Rough numbers for AWS:

• NLB: $0.0225/hour + traffic charges. Cheap.
• ALB: $0.0252/hour + LCU charges (load balancer capacity units, based on RPS, connections, etc.). More expensive at high volume.

For most workloads the cost difference is small. For very high-volume APIs, ALB's LCU charges become a real line item.

Observability

L4 LBs emit minimal observability data: connection counts, bytes, basic flow information.

L7 LBs emit rich access logs: HTTP method, path, status code, latency, user agent, request size, response size.

For most production setups, L7 logs are the primary observability source — they feed into request-level dashboards and alerting. L4 logs are useful but coarser.

Common Mistakes

• Using L4 for HTTP workloads. You lose all the HTTP-level features.
• Terminating TLS at both LB and backend with no good reason. Adds CPU cost without benefit.
• L7 LB with no path-based routing. You are paying L7 prices for L4 functionality.
• Sticky sessions on L4. Coarse, surprising affinity behavior.
• Ignoring health checks. Backends marked healthy that are actually degraded.

The Practical Default

For most public-facing web applications: an L7 load balancer (ALB, GLB) with TLS termination and L7 health checks.

For internal service-to-service: depends on the protocol. HTTP services can use L7. Custom TCP protocols use L4.

For latency-sensitive backends (real-time, gaming, trading): consider L4 or pass-through. The latency tax of L7 might matter.

For most teams: ALB or equivalent, configured well, handles 95% of needs.

Picking a load balancer for a new service or reviewing whether your current setup is doing the right thing? We help teams pick L4/L7 configurations that match the workload's actual needs. scopeforged.com