What's the actual difference between a Layer 4 and a Layer 7 load balancer, and how does that difference affect what routing decisions each can make?

A Layer 4 load balancer routes based only on transport-layer information (IP address and port), without ever inspecting the actual application data inside the connection — it's fast and protocol-agnostic, but can only make coarse routing decisions (which backend gets this connection). A Layer 7 load balancer terminates and inspects the actual application-layer content (HTTP headers, paths, cookies), letting it make much richer routing decisions (route /api to one backend, /static to another) at the cost of more processing overhead and being protocol-specific (typically HTTP/HTTPS-aware).

The distinction maps directly to the OSI model layers each operates at, and that determines exactly what information is available to base a routing decision on.

Layer 4 load balancing works at the transport layer, seeing only IP addresses, ports, and the TCP/UDP connection itself — it doesn't decrypt or parse anything above that, which means it can distribute connections (typically via round-robin, least-connections, or a hash of source IP/port) but has no visibility into what's actually being requested. This makes it fast (minimal processing per packet) and works for any protocol running over TCP/UDP, not just HTTP — but it also means all routing decisions are effectively "which backend server" with no ability to route based on request content.

Layer 7 load balancing works at the application layer, meaning it actually terminates the connection (including decrypting TLS, if used) and parses the application protocol — for HTTP, this means reading the request path, headers, cookies, or method, and making routing decisions based on that content (route requests for /api/* to one backend pool, /images/* to a CDN-backed pool, route based on a cookie for session affinity). This unlocks much more sophisticated routing but requires the load balancer to actually understand and parse the specific application protocol, and to terminate TLS (meaning it needs the certificate/keys, and traffic between the load balancer and backend may be a separate, potentially unencrypted or re-encrypted hop).

The practical trade-off is routing sophistication versus overhead and protocol coupling: Layer 4 is simpler, faster, and works for any TCP/UDP-based protocol, appropriate when you just need to distribute load across identical backends; Layer 7 is necessary the moment routing needs to depend on the actual content of the request — path-based routing, header-based routing, canary/percentage-based routing by content, or WAF-style content inspection — but comes with more processing cost per request and ties the load balancer to understanding the specific application protocol.

Many real-world setups use both, layered: a Layer 4 load balancer (or a cloud provider's network load balancer) distributing traffic across a fleet of Layer 7 load balancers/reverse proxies (like NGINX or an API gateway), which then do the content-aware routing — combining Layer 4's raw throughput and simplicity at the edge with Layer 7's routing sophistication at the next layer in.

• Layer 4 load balancers see only IP/port and route based on transport-layer information, without inspecting request content — fast and protocol-agnostic.
• Layer 7 load balancers terminate the connection and parse application-layer content (HTTP paths, headers, cookies), enabling content-aware routing at the cost of more processing overhead and protocol-specific handling.
• Choose Layer 4 when you just need to distribute load across identical backends; choose Layer 7 when routing needs to depend on actual request content.
• Real-world architectures often layer both — a Layer 4 balancer distributing across a fleet of Layer 7 balancers/proxies doing the content-aware routing.

• NGINX: Load Balancing Concepts
• Cloudflare: What is a load balancer?