← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

Load Balancer Types — L4 vs L7

cloud Intermediate

Also Known As

L4 load balancer L7 load balancer application load balancer network load balancer layer 4 vs layer 7

TL;DR

Layer-4 load balancers forward raw TCP/UDP packets based on IP and port; layer-7 load balancers terminate HTTP and route based on paths, headers and cookies — different trade-offs for different traffic.

Explanation

An L4 (transport-layer) load balancer operates at TCP/UDP: it sees source IP, destination IP, and ports, and forwards connections without inspecting their contents. This makes it fast, protocol-agnostic and cheap (AWS NLB, GCP TCP/UDP LB). An L7 (application-layer) load balancer terminates the application protocol — almost always HTTP(S) — so it can read URLs, headers, cookies and body content. That lets it do path-based routing, host-based routing, header-based A/B testing, sticky sessions by cookie, and request rewriting (AWS ALB, GCP HTTPS LB, Nginx, HAProxy in HTTP mode, Envoy). L7 is slower per packet and costs more, but unlocks the routing features modern microservices need. Service meshes add L7 sidecars on every pod, which is why a mesh's data plane needs careful tuning. Choosing between them is a question of: do you need protocol-aware routing, and can you afford to terminate TLS at the LB?

Common Misconception

L7 is not strictly 'better' than L4 — for a raw-TCP workload like a database proxy or a gaming server, L4 is the right choice because it preserves the client IP cleanly and introduces no protocol overhead.

Why It Matters

Picking the wrong tier causes expensive rewrites: L4 cannot route /api vs /app to different services, and L7 adds latency and cost for workloads that do not need its features. TLS termination, client-IP preservation (PROXY protocol / X-Forwarded-For), and WebSocket support all hinge on the choice.

Common Mistakes

  • Using an L7 load balancer for a raw TCP protocol — you either lose features or pay for routing you never use; prefer L4 for MySQL, Redis, gaming servers.
  • Forgetting that L4 does not preserve the client IP by default — enable PROXY protocol and configure the backend to parse it.
  • Terminating TLS at L7 without handling the re-encryption to the backend — internal traffic ends up in cleartext; set up an upstream TLS context or use the mesh.
  • Relying on sticky-session cookies on an L4 LB — it cannot see cookies; use source-IP hashing or move to L7.
  • Configuring both L4 and L7 in line without a plan — every additional hop is another timeout, retry and failure mode to debug.

Avoid When

  • Mixing them without a clear boundary — if you need both, terminate L7 behind an L4 tier, not the other way around.

When To Use

  • L7 — HTTP-based microservices needing path/host routing, sticky sessions by cookie, or centralised TLS termination.
  • L4 — pure TCP/UDP workloads, very high throughput with minimal CPU, or preserving the exact client connection to the backend.

Added 18 Apr 2026
Views 21
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings W 0 pings T 0 pings F 0 pings S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 2 pings S 0 pings M 0 pings T 1 ping W 0 pings T 1 ping F 0 pings S 0 pings S 0 pings M 0 pings T 0 pings W 4 pings T 1 ping F 1 ping S 1 ping S 0 pings M 0 pings T 1 ping W 0 pings T
No pings yet today
Google 5 Perplexity 3 SEMrush 2 Meta AI 2 Ahrefs 1
crawler 12 crawler_json 1
DEV INTEL Tools & Severity
🔵 Info ⚙ Fix effort: Medium
⚡ Quick Fix
Rule of thumb: HTTPS/gRPC with routing needs → L7 (ALB, Envoy). Raw TCP/UDP or huge throughput → L4 (NLB).
🔗 Prerequisites

✓ schema.org compliant