ALB vs NLB vs GWLB
~10 min read
Three load balancer types operating at different layers, for different traffic shapes.
Application Load Balancer (ALB) operates at Layer 7 (the HTTP/HTTPS application layer), which means it can inspect the actual request content — routing /api/* to one target group and /static/* to another, routing based on hostname for multi-tenant applications, and terminating SSL/TLS on behalf of your instances. This content-awareness is why ALB is the default choice for modern web applications, REST APIs, and microservices.
Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP), with no visibility into request content — it simply forwards connections extremely fast, at very high throughput (millions of requests per second), and critically preserves the original client's source IP address (ALB, by contrast, replaces the source IP with its own, requiring the X-Forwarded-For header to recover the real client IP). NLB is the right choice for latency-sensitive workloads, non-HTTP protocols (raw TCP services, gaming servers, IoT), or when you need a static IP address for the load balancer itself (NLB supports this; ALB does not).
Gateway Load Balancer (GWLB) is a specialized option for transparently routing traffic through third-party virtual network appliances — firewalls, intrusion detection/prevention systems — inserting them into the traffic path without the application itself needing to know they're there. This is a more niche, security/networking-team use case rather than a typical application architecture decision.
💬 Deep Dive with AI
Key points
- •ALB (Layer 7): content-aware routing by path/host, the default for HTTP web apps and APIs
- •NLB (Layer 4): extreme throughput, preserves client source IP, supports static IPs, for TCP/UDP/non-HTTP
- •GWLB: transparently inserts third-party network appliances into a traffic path
- •ALB replaces the client's source IP; recover it via the X-Forwarded-For header if your app needs it