Load Balancer Types Deep Dive: ALB, NLB & Gateway LB
The operational depth behind AWS's three load balancer types — path/host-based routing on ALB, extreme throughput and static IPs on NLB, and transparent traffic inspection with Gateway Load Balancer — and how to choose correctly between them.
Want a visual for this topic?
Generate a diagram tailored to Load Balancer Types Deep Dive: ALB, NLB & Gateway LB — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Choose correctly between ALB, NLB, and Gateway Load Balancer for a given traffic pattern and protocol
- •Explain how ALB's path-based and host-based routing let one load balancer serve multiple backend services
- •Explain what Gateway Load Balancer inserts into the traffic path and why that's architecturally different from ALB/NLB
- •Explain cross-zone load balancing and its cost implication for NLB specifically
What is it?
This topic goes one level deeper than load balancing fundamentals into the specific operational differences between AWS's three Elastic Load Balancing types: Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS), understanding request content well enough to route based on URL path, hostname, or headers; Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP/TLS), built for extreme throughput, ultra-low latency, and static IP addresses; and Gateway Load Balancer (GWLB) is a specialized Layer 3/4 service for transparently inserting third-party virtual appliances (firewalls, intrusion detection systems) into a traffic path.
Why it exists
Different traffic patterns and architectural needs genuinely require different load balancing mechanics — a modern microservices web application needs content-aware routing decisions (ALB's specialty), a latency-critical gaming or financial trading backend needs raw Layer 4 throughput with a stable IP (NLB's specialty), and a security team wanting every packet inspected by a third-party firewall appliance before it reaches its destination needs a transparent insertion mechanism that neither ALB nor NLB was built for (GWLB's specific purpose).
Problem it solves
ALB solves routing many different backend services behind one load balancer based on the actual request content, letting a single ALB serve an entire microservices architecture instead of needing one load balancer per service. NLB solves extreme-throughput, ultra-low-latency, non-HTTP, or static-IP-requiring workloads that ALB's Layer 7 processing overhead isn't built for. Gateway Load Balancer solves inserting a fleet of third-party security appliances into a traffic path transparently, scaling that appliance fleet independently and automatically, without requiring every application team to individually integrate with the security tooling.
Intuition
ALB is like a receptionist who actually reads what you're asking for and directs you to the right department based on the content of your request (‘billing inquiries this way, technical support that way’). NLB is like a dedicated, high-speed conveyor belt that doesn't read anything, just moves whatever's on it as fast as physically possible to a fixed destination. Gateway Load Balancer is like a mandatory security checkpoint transparently inserted into a hallway that everyone has to pass through on the way to their actual destination, without needing to know or care that the checkpoint is there.
Analogy
Think of ALB as an airport's terminal directory reading your boarding pass's actual gate information and directing you precisely (content-aware routing); NLB as airport ground crew moving cargo containers as fast as possible with no need to open and inspect each one (raw throughput, protocol-agnostic); and Gateway Load Balancer as the mandatory security screening every passenger walks through regardless of their airline or gate, inserted into everyone's path in one shared, scalable checkpoint.
Technical explanation
ALB supports path-based routing (matching on URL path patterns), host-based routing (matching on the Host header, useful for serving multiple domains/subdomains from one ALB), and can route based on HTTP headers, query strings, or source IP, evaluated in listener rule priority order. NLB preserves the client's source IP by default (unlike ALB) and supports extremely high throughput with minimal added latency, since it doesn't decrypt/inspect Layer 7 content at all in most configurations — it's the right choice whenever a non-HTTP TCP/UDP protocol is involved, or a static IP is a hard requirement (some enterprise firewall allow-listing scenarios specifically require a fixed IP, which ALB, whose IPs can change, doesn't guarantee the same way). Gateway Load Balancer uses a dedicated GENEVE-based protocol (port 6081) to transparently forward traffic to a fleet of appliance instances, and requires VPC ingress routing configuration to actually insert it into a traffic path (typically at the Internet Gateway or Transit Gateway level) — a materially different setup than simply pointing DNS at ALB/NLB.
Architecture
A media streaming platform uses ALB to route /video/* requests to a video-serving fleet and /api/* to a separate API fleet, both behind one ALB endpoint and one TLS certificate via ACM. Their real-time bidding advertising backend, needing sub-millisecond added latency and UDP support, uses NLB instead. Separately, a security team inserts a fleet of third-party next-gen firewall appliances via Gateway Load Balancer between their VPC and the internet, so every application team's traffic is inspected without any individual application needing to integrate with the firewall vendor's product directly.
Workflow
- Default to ALB for HTTP/HTTPS web applications and microservices needing content-aware routing. 2) Choose NLB specifically when the protocol isn't HTTP, extreme throughput/low latency is required, or a static IP is a hard requirement. 3) Choose Gateway Load Balancer only when transparently inserting third-party network/security appliances into a traffic path is the actual goal — it's not a general-purpose load balancer choice for typical application traffic. 4) For NLB specifically, evaluate whether cross-zone load balancing is worth its data-transfer cost given your traffic distribution across AZs.
Example
An online gaming company runs its matchmaking API behind ALB (path-based routing to different game-mode services) but runs its actual real-time game server traffic (UDP) behind NLB, since ALB fundamentally cannot serve UDP traffic at all — this isn't a preference, it's a hard protocol constraint that decides the choice.
Real-world usage
ALB is the default load balancer choice for the overwhelming majority of modern AWS-hosted web applications and microservices architectures. NLB is standard for gaming backends, IoT ingestion, financial trading systems, and any scenario needing a static IP for firewall allow-listing. Gateway Load Balancer adoption is concentrated among security-conscious enterprises running third-party firewall/IDS appliances (from vendors like Palo Alto, Fortinet, Check Point) that support GWLB's GENEVE-based integration model.
Trade-offs
ALB versus NLB is fundamentally a routing-intelligence-versus-raw-performance tradeoff: ALB's Layer 7 awareness costs a small amount of latency and CPU versus NLB's near-pass-through performance, but unlocks content-based routing NLB simply cannot do. Gateway Load Balancer trades additional network configuration complexity for the ability to transparently insert appliances into a traffic path at scale — not a substitute for ALB/NLB, but a complementary tool solving a genuinely different problem.
Visual explanation
Picture ALB with listener rules: a request to /api/* is routed to one target group (a fleet of API servers), a request to /images/* to another (a fleet of image servers), and a request to admin.example.com is routed based on hostname to a completely different target group — all through the same ALB endpoint. Picture NLB with a static IP per AZ, directly forwarding TCP connections to targets with the client's original source IP preserved end to end (unlike ALB, which by default replaces the source IP with its own, requiring the X-Forwarded-For header to recover the original client IP). Picture Gateway Load Balancer sitting inline between a VPC's traffic and the internet via VPC ingress routing, silently directing all matching traffic through a fleet of third-party appliance instances before it continues to its actual destination.
Advantages
- —
ALB's content-aware routing lets one load balancer serve an entire microservices architecture, reducing operational overhead versus one load balancer per service
- —
NLB's raw Layer 4 performance and static IPs fit latency-critical and IP-allowlisting scenarios ALB can't serve
- —
Gateway Load Balancer scales a third-party appliance fleet independently and automatically, without every application team integrating with it directly
- —
All three integrate natively with Auto Scaling Groups, health checks, and multi-AZ target registration
Disadvantages
- —
ALB cannot serve non-HTTP(S) protocols at all — a hard limitation, not a configuration choice
- —
NLB's lack of Layer 7 awareness means no path/host-based routing — it only forwards at the connection level
- —
Gateway Load Balancer requires more complex network setup (VPC ingress routing) than simply attaching ALB/NLB to a target group
- —
Cross-zone load balancing on NLB incurs data transfer charges between AZs that ALB does not, a cost detail easy to overlook
Common mistakes
- —
Trying to use ALB for a UDP-based protocol and discovering it's fundamentally unsupported, not just harder to configure
- —
Assuming NLB automatically load-balances evenly across AZs without realizing cross-zone load balancing is a separate, explicitly-configured (and for NLB, cost-incurring) setting
- —
Forgetting that ALB replaces the client's source IP by default, breaking application logic that assumed the connecting IP was the original client's — the X-Forwarded-For header must be read instead
- —
Choosing Gateway Load Balancer as a general-purpose load balancer when the actual need was simply ALB or NLB — GWLB solves a specific appliance-insertion problem, not general traffic distribution
In the AWS Console
- 1
EC2 → Load Balancers → Create load balancer → Application Load Balancer
Configure listeners and add routing rules under 'Actions' matching path patterns or host headers to different target groups.
Rule priority order matters — the first matching rule wins, so more specific path patterns should generally be given higher priority than catch-all rules.
- 2
EC2 → Load Balancers → Create load balancer → Network Load Balancer
Choose whether to assign static Elastic IPs per AZ, and configure cross-zone load balancing under load balancer attributes if even AZ-to-AZ distribution is required.
Cross-zone load balancing is off by default for NLB (unlike ALB, where it's always on) and incurs inter-AZ data transfer charges when enabled.
🎤 Interview questions
Why can't Application Load Balancer serve a UDP-based game server protocol? (Listen for: ALB operates at Layer 7, HTTP/HTTPS only by design — it has no mechanism for non-HTTP protocols like UDP at all, unlike NLB which operates at Layer 4.)
How does ALB's path-based routing let a single load balancer serve a microservices architecture? (Listen for: listener rules match URL path patterns or host headers and route matching requests to different target groups, letting one ALB endpoint front many independently-scaled backend services.)
Why would a scenario requiring a static IP for a partner's firewall allow-list point toward NLB instead of ALB? (Listen for: NLB supports static Elastic IPs per AZ; ALB's IP addresses can change over time and aren't guaranteed static, making it unsuitable for strict IP allow-listing.)
What does Gateway Load Balancer actually insert into a network path, and why is that architecturally different from ALB/NLB? (Listen for: it transparently forwards traffic through a scalable fleet of third-party appliances via GENEVE encapsulation and VPC ingress routing, rather than terminating/distributing traffic to application targets like ALB/NLB do.)
What's the cost implication of enabling cross-zone load balancing on an NLB? (Listen for: unlike ALB where cross-zone is always on at no extra charge, NLB's cross-zone load balancing is opt-in and incurs inter-AZ data transfer charges.)
📂 Subtopics
ALB Path-Based vs Host-Based Routing
The two core ALB routing patterns, and how they combine to serve complex multi-service architectures from one load balancer.
~10 min
How Gateway Load Balancer Actually Inserts Into a Traffic Path
The VPC ingress routing mechanics that make GWLB's transparent appliance insertion work.
~8 min