Layer 4 vs Layer 7 Load Balancing: A Practical Guide

What Layer We're Talking About

The "layer" in load balancing refers to the OSI model. Layer 4 is the transport layer (TCP, UDP). Layer 7 is the application layer (HTTP, gRPC, WebSocket). The distinction matters because it determines what information a load balancer can see — and therefore how smart its routing decisions can be.

Layer 4 Load Balancing

A Layer 4 load balancer routes traffic based on IP address and port. It doesn't inspect the payload. It sees a TCP connection arrive on port 443 and forwards it to a backend — that's it.

How it works

1. Client opens a TCP connection to the load balancer's VIP (virtual IP).
2. The balancer selects a backend using a configured algorithm (round-robin, least-connections, IP hash, etc.).
3. The connection is proxied or NAT'd to that backend for its entire lifetime.
4. The backend handles TLS termination itself, or the connection is passed through opaque.

Because L4 balancers don't parse HTTP headers, they can't route based on URL path, hostname, or cookies. A single long-lived TCP connection — say, a database client or a WebSocket — stays pinned to one backend for its duration.

When to use it

• Non-HTTP protocols: MySQL, PostgreSQL, Redis, MQTT, custom TCP/UDP services.
• Raw throughput: L4 is cheaper computationally. HAProxy in TCP mode, AWS NLB, and Google Cloud's pass-through NLB all operate here.
• TLS passthrough: When you need the backend to handle its own certificates (mutual TLS, for example).
• Ultra-low latency: Fewer bytes inspected means fewer CPU cycles per connection.

Layer 7 Load Balancing

A Layer 7 load balancer terminates the connection, reads the application-level request, and then makes a routing decision based on what it finds inside.

How it works

1. Client opens a TLS connection; the load balancer terminates it and decrypts the traffic.
2. The balancer reads the HTTP request — method, Host header, path, cookies, query parameters.
3. It applies routing rules and forwards the request to a matching backend pool.
4. It opens its own connection to the backend (or reuses one from a connection pool).
5. The response flows back through the balancer to the client.

This two-connection model is the key difference. The balancer is a full HTTP proxy, not a transparent forwarder.

What you can do with L7 that you can't with L4

• Path-based routing: /api/* → API servers, /static/* → CDN origin, /ws → WebSocket cluster.
• Host-based routing: Route app.example.com and admin.example.com to different backends on the same IP.
• Header inspection: Canary deployments by X-Canary: true, A/B testing by cookie value.
• Request rewriting: Strip path prefixes, inject headers, redirect HTTP to HTTPS.
• Sticky sessions: Hash on a session cookie so a user always hits the same backend.
• gRPC and HTTP/2: Frame-aware multiplexing that L4 can't do sensibly.
• WAF integration: Inspect and block malicious payloads before they reach your app.

Nginx, HAProxy (HTTP mode), Envoy, AWS ALB, Traefik, and Caddy all operate at Layer 7.

Latency and Resource Trade-offs

L7 isn't free. Terminating TLS, parsing HTTP frames, and evaluating routing rules adds a small but real overhead — typically a few hundred microseconds per request on modern hardware. For most web workloads this is negligible. For high-frequency trading or sub-millisecond SLA services, it isn't.

L4 also scales connection counts more easily. An L4 balancer handling 1 million concurrent TCP connections is straightforward; an L7 proxy at the same scale needs considerably more memory because it tracks HTTP request state per connection.

Mixing Both Layers

Production setups often stack them:

• An L4 NLB at the edge absorbs the raw TCP load, preserves client IP, and passes traffic to a fleet of L7 proxies.
• The L7 tier handles TLS termination, routing logic, and observability.
• Internal service-to-service traffic (service mesh) may use another L7 layer (Envoy sidecars, Linkerd).

This is the pattern AWS, GCP, and most large-scale Kubernetes ingress setups follow.

Health Checks Behave Differently at Each Layer

An L4 health check confirms a TCP port is accepting connections. An L7 health check sends an actual HTTP request and validates the status code and optionally the response body.

L4 checks can pass while your application is deadlocked but still binding the port. L7 checks catch that. If you're running L7 load balancing, configure L7 health checks — don't rely on TCP pings alone.

For external validation, multi-region uptime monitoring (Pingy probes from several geographic locations) catches asymmetric failures that internal health checks miss: a backend that's healthy from your VPC but returning 502s for real users due to a routing or DNS issue.

Key Takeaways

• Layer 4 routes by IP/port, is protocol-agnostic, fast, and doesn't touch the payload.
• Layer 7 terminates connections, inspects HTTP, and enables content-based routing, rewrites, and fine-grained control.
• Use L4 for non-HTTP protocols, TLS passthrough, and maximum throughput; use L7 for web traffic where you need routing flexibility.
• Stacking L4 in front of L7 is common and sensible in high-scale architectures.
• Always match your health check depth to your load balancer layer — TCP checks are not a substitute for HTTP checks on an L7 proxy.
• External monitoring complements internal health checks; they see what real users see.