Cloud Load Balancer Types: L4 vs L7

L4 vs L7: the OSI layer distinction

Network protocols are conventionally described in OSI layers. Load balancers operate at one of two:

Layer 4 (transport)

L4 load balancers see only the TCP or UDP packet headers — source IP, destination IP, source port, destination port, sequence numbers. They cannot see the application payload (HTTP headers, URLs, request bodies). Routing decisions are based purely on connection-level information.

• Protocols: Any TCP or UDP-based protocol. HTTP, HTTPS (TLS passthrough), gRPC, MQTT, custom binary protocols, DNS, RDP, SSH, FTP.
• Speed: Very fast. No application-layer parsing per connection. Millions of connections per second per LB.
• Sticky sessions: Based on source IP only.
• Limitations: Cannot route by URL path, host header, or any application data. Cannot terminate TLS for inspection (only for offload).

Layer 7 (application)

L7 load balancers parse the application protocol — almost always HTTP/HTTPS — and make routing decisions based on its contents. They terminate the TLS connection, inspect headers and (optionally) body, route to backends, and forward the request.

• Protocols: HTTP/1.1, HTTP/2, HTTP/3, WebSocket, gRPC. Specifically HTTP-aware features.
• Routing: Path-based ("/api/* goes here"), host-based (api.example.com vs www.example.com), method-based, header-based.
• Features: Content rewriting, response header manipulation, request authentication, OAuth/OIDC integration, WAF integration, rate limiting per path.
• Speed: Slower than L4. The TLS handshake + HTTP parse on every request adds latency (typically 1-5 ms per request).
• Limitations: HTTP-specific. Cannot load-balance arbitrary TCP/UDP. Cannot preserve client source IP without explicit configuration.

The AWS load balancer trio

Application Load Balancer (ALB)

The default choice for HTTP-based workloads. Distinctive features:

• Path and host-based routing via listener rules (max 100 rules per listener).
• Native WebSocket support.
• HTTP/2 for client connections, HTTP/1.1 to backends (HTTP/2 to backends added 2023).
• Built-in authentication via Cognito or OIDC providers.
• Sticky sessions via ALB-managed cookie or app-managed cookie.
• WAF integration — AWS WAF rules apply to the ALB.

Network Load Balancer (NLB)

The right tool when you need L4. Distinctive features:

• Static IPs — one per AZ, optionally Elastic IPs you control.
• Preserves client source IP by default (when targets are instances; with IP targets, proxy protocol is required).
• UDP support — required for QUIC/HTTP/3 origin LBs, DNS, syslog, real-time media.
• TLS termination or passthrough.
• Extreme connection rate. Sustains millions of new connections per second.

Gateway Load Balancer (GLB)

A specialized type for inserting third-party network appliances (Palo Alto, Check Point, Fortinet) transparently into a traffic path. Not a general-purpose load balancer.

Azure's load balancer types

Azure Load Balancer ≈ AWS NLB. Azure Application Gateway ≈ AWS ALB. Azure Front Door is closer to AWS CloudFront with built-in load balancing features.

GCP's load balancer types

GCP differentiates by whether the LB is internal or external, regional or global, and the protocol level. The global LBs use GCP's anycast network — a single anycast IP terminates connections in the closest region to the client.

Decision tree: which LB type to pick

1. Is the protocol HTTP/HTTPS?
   • Yes → use the L7 LB (ALB, Application Gateway, Cloud Load Balancer HTTP).
   • No → use the L4 LB (NLB, Azure LB, Network LB).
2. Do you need path-based or host-based routing?
   • Yes → L7 (ALB / Application Gateway).
   • No → either layer works; L4 is cheaper if no other L7 feature is needed.
3. Do you need to preserve client source IP without proxy protocol?
   • Yes → NLB (instance targets) or Azure Standard LB.
   • No → either layer works.
4. Do you need static IP for the LB?
   • Yes → NLB (Elastic IPs per AZ) or Azure Standard LB.
   • No → ALB is fine (uses dynamic IPs behind DNS).
5. Do you need global anycast?
   • Yes → GCP Global External HTTP(S) LB, Azure Front Door, or CloudFront + ALB.
   • No → regional LB is appropriate.
6. Do you need WAF, OAuth, or other HTTP-layer features?
   • Yes → L7 (ALB / Application Gateway / Front Door).
   • No → either layer.

Health checks: the most-misconfigured load balancer feature

Every cloud LB performs periodic health checks against its backend targets to decide which are healthy enough to receive traffic. Misconfigured health checks cause more LB outages than the LB itself:

• Path: Use a dedicated health endpoint (/healthz, /ping) that returns 200 immediately. Do NOT health-check / on a complex app — page-load issues will mark instances unhealthy.
• Method: GET, no body. Avoid HEAD if the backend handles HEAD differently.
• Success codes: Configure exact codes. Default 200-299 is usually correct.
• Interval: 10-30 seconds. Lower causes more LB→backend traffic; higher delays detection of failures.
• Timeout: 5 seconds typically. Higher tolerates slow backends but increases failover time.
• Healthy/unhealthy thresholds: 2-5 consecutive results to change state. Higher reduces flapping; lower detects faster.
• Deep health checks: The health endpoint should verify upstream dependencies. A backend with a dead database should be marked unhealthy.

Cross-zone load balancing: the cost dial

When a load balancer has targets in multiple AZs, "cross-zone" determines whether traffic from one AZ can reach targets in another. The trade-off is between target utilization and data transfer cost.

• Cross-zone ON (ALB default): Every target gets equal share of traffic regardless of AZ. Best target utilization. Generates inter-AZ data transfer charges between LB and target.
• Cross-zone OFF (NLB default): Each AZ's LB instance only routes to that AZ's targets. No inter-AZ data transfer. Requires equal target counts per AZ to avoid hotspots.

For high-traffic workloads, turning off cross-zone can save thousands of dollars per month. For low-traffic workloads where AZ balance is uncertain, leave it on.

Frequently Asked Questions

What is the difference between L4 and L7 load balancing?

L4 load balancers operate at the transport layer — they distribute TCP or UDP connections based on packet headers (source/destination IP and port) without looking at packet contents. L7 load balancers operate at the application layer — they understand HTTP and can route based on URL path, host header, cookies, request method, and other application-level data. L4 is faster and supports any protocol; L7 supports HTTP-aware features like path-based routing, content rewriting, and Layer 7 health checks at the cost of higher per-request CPU.

When should I use NLB instead of ALB?

Use NLB for non-HTTP protocols (raw TCP, UDP, gRPC at very high throughput, mTLS with passthrough), when you need static IPs for the load balancer, when you need extreme connection rates (millions per second), or when you need to preserve the client's source IP without proxy protocol. Use ALB for HTTP/HTTPS workloads that benefit from path-based routing, host-based routing, WebSocket support, HTTP/2, and integration with WAF and Cognito for authentication.

Does an ALB or NLB cost more?

ALB and NLB have similar pricing structures — a small hourly base charge plus a per-request unit charge. AWS ALB is approximately $0.0225/hour + $0.008 per LCU-hour; NLB is approximately $0.0225/hour + $0.006 per NLCU-hour. For most workloads the practical difference is small. The bigger cost driver is the LCU/NLCU unit calculation, which is based on connections, processed bytes, rule evaluations (ALB), and new connections (NLB). High-throughput, low-request workloads tend to be cheaper on NLB; high-request, low-bytes workloads tend to be similar.

Can a load balancer terminate TLS?

Both ALB and NLB can terminate TLS, with different trade-offs. ALB terminates TLS and re-encrypts to backend targets if configured; it can inspect HTTP traffic between the two TLS sessions. NLB can terminate TLS or pass it through untouched. TLS termination at the load balancer offloads the cryptographic work from backends and lets the LB handle certificate management — typically via AWS Certificate Manager. TLS passthrough preserves end-to-end encryption but means the LB cannot route based on path or host.

What is the difference between cross-zone load balancing being on or off?

With cross-zone load balancing enabled, the load balancer distributes traffic evenly across all healthy targets regardless of which AZ they are in. With it disabled, traffic is distributed evenly across AZs first, then across targets within the AZ — which means uneven target distribution across AZs leads to uneven per-target load. Cross-zone is on by default for ALB, off by default for NLB. Turning cross-zone off saves cross-AZ data transfer charges but requires balanced target counts per AZ to avoid hotspots.