Load Balancing
Intermediate 12 min read Load Balancing

L7 vs L4 Load Balancers

Packet-level vs request-level routing

Layer 4 balancers forward packets/TCP by IP+port with minimal intelligence; layer 7 balancers read HTTP(S) content (paths, headers, cookies) to route precisely. Knowing which one serves which protocol shape is the core decision.

L4L7TCPUDPHTTPNLBALBApplication Gateway
Prerequisites: Load Balancing Basics
Before we start

What you will learn

  • Compare L4 (TCP/UDP) and L7 (HTTP/HTTPS) behavior
  • Choose the right balancer class per workload
  • Explain TLS termination's role at L7
In 60 seconds

L4 (NLB, Azure LB/TCP proxy) forwards connections by IP/port with near-zero overhead. L7 (ALB, App Gateway, GCP HTTP LB) reads the request — path, host, cookies — enabling microservice routing, WAF and traffic shaping at some cost.

Introduction

What is this?

L4: AWS NLB, Azure Load Balancer, GCP TCP/UDP proxy. Fast, connection-preserving, works for any TCP/UDP protocol (gRPC, MQTT, game servers, databases). L7: AWS ALB, Azure Application Gateway, GCP external HTTP(S) LB. Route by path/host/header/query, rewrite, sticky by cookie, TLS termination, WAF. L4 keeps source IP (proxy protocol optional); L7 inserts X-Forwarded-* headers. L4 = no protocol awareness (UDP supported); L7 = HTTP/2, WebSocket, gRPC-aware.

Motivation

Why do you need it?

  • L4 sustains millions of connections/sec with tiny overhead — IoT, game, VPN transports need it.
  • L7 gives precise routing so /api vs /static split cleanly across services.
  • TLS at L7 centralizes certificates; L4 passes raw TLS (you terminate elsewhere).
  • Protocol choice drives everything: you can't route HTTP on a dumb TCP balancer.
Think about it

Mental model

Imagine

Receptionist who just points to a queue vs one who reads your ticket

Think of

L4 vs L7

L4: taken to whatever door matches the floor number (TCP port). L7: reads your request subject (path) and sends you to accounts or support — more work, way more useful routing.

Mechanics

How it works

  • L4: forwards TCP/UDP flows between client and chosen target, keeping a 5-tuple flow table; no payload inspection.
  • L7: terminates HTTP(S), parses headers/path, applies rules, then re-encrypts (or passes HTTP) to the target.
  • L7 inserts X-Forwarded-For/Proto/Host so apps see real clients behind the proxy.
  • Sticky sessions at L7 use cookies; at L4 use source-IP affinity (client IP to same target).
  • TLS: L7 offload terminates cert; L4 can do TLS passthrough or TCP+TLS termination (signatures none).

Two balancer lenses.

Client
L4 (NLB)
Target
L7 (ALB)
Service A/B
Hands-on

Examples

Route by path (L7) and forward TCP (L4)

Route by path (L7) and forward TCP (L4)
# ALB rule: /api -> api target group, everything else -> web
aws elbv2 create-rule --listener-arn <arn> --priority 10   --conditions Field=path-pattern,Values=/api/*   --actions Type=forward,TargetGroupArn=<api-tg>
# NLB: TCP passthrough for a game server
aws elbv2 create-load-balancer --name game-lb --type network   --subnets subnet-aaaa subnet-bbbb

L7 rules read the request; L4 just forwards the TCP stream.

Real world

In production

  • A VoIP platform forwards UDP via NLB to media servers preserving source IP.
  • App Gateway routes /api plus WAF and header rewrites at the edge.
  • GCP HTTP LB serves gRPC (h2c) with path-based backend selection.
Guidelines

Best practices

  • Use L7 when you need routing/rewrites/WAF; L4 when you need raw protocol speed.
  • Terminate TLS at L7 for central cert management; use L4 passthrough for end-to-end TLS.
  • Preserve client context: enable proxy protocol on L4 or rely on X-Forwarded-* at L7.
  • Match the balancer class to the fleet's protocol before sizing capacity.
Watch out

Common mistakes

  • Routing gRPC or WebSocket over an L4 box and losing path-based scaling.
  • Using L7 for a TCP stream (it can't parse frames) → just a very expensive TCP proxy.
  • Trusting X-Forwarded-For blindly from CDNs (spoofing) — validate with trusted hops.
  • Putting L7 behind L4 and losing client IP unless proxy protocol is forwarded.
Root cause analysis

Common issues

Error
L7 balancer drops long-lived WebSocket
Root cause

L7 idle timeout or HTTP/1.1 upgrade handling

Fix

Raise idle timeouts / enable WebSocket on the LB or route that traffic over an L4.

Error
UDP traffic silently dropped
Root cause

L7 (HTTP) balancer can't carry UDP

Fix

Switch to an L4/TCP-UDP balancer for non-HTTP transports.

When things break

Debugging tips

  • L7 rules not firing: check path-pattern match and rule priority order.
  • 'Connection reset' on an L4: verify the flow table and target port; L4 won't tell you about HTTP.
  • X-Forwarded-*-confusion: trust chains fixed via known proxies in the app config.
  • Sticky mismatch: cookie vs source-IP stickiness behave differently under NAT — test both.
Interviews

Interview checkpoint

Practice

Hands-on lab

Pick L4 vs L7 for Three Workloads
15 min · intermediate
In progress
Objectives
  • Classify each workload as L4- or L7-appropriate
  • Sketch the balancer + routing layout
  • Justify TLS handling per choice

Pick L4 vs L7 for Three Workloads

15 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Which balancer class can route by request path?

Go deeper

Official documentation

AWS — Choose an ELB
docs
Azure — Load balancing options
docs
GCP — Load balancer flavors
docs