Load Balancing

TL;DR

• Three AWS load balancer types operate at different OSI layers and solve different problems — not a good/better/best hierarchy.
• ALB (Layer 7): HTTP/HTTPS-aware routing, header inspection, WebSocket, WAF integration.
• NLB (Layer 4): raw TCP/UDP, extreme throughput, ultra-low latency, static IP per AZ, source IP preservation.
• GWLB: transparent inline insertion of third-party security appliances via GENEVE encapsulation — a distinct use case, not a general-purpose LB choice.
• Biggest gotcha: ALB has no native static IP; the correct pattern for “HTTP routing + static IP” is Global Accelerator in front of ALB, not forcing NLB to do HTTP routing.

Core Concepts

Application Load Balancer (ALB)

Operates at Layer 7 and understands HTTP/HTTPS semantics natively: path-based routing, host-based routing, header/query-string inspection, native WebSocket support, and direct WAF integration. Terminates the client connection and re-establishes a new one to the target, which enables content inspection but adds a hop compared to a pass-through model. Correct choice whenever traffic is genuinely HTTP-shaped and routing decisions depend on application-layer information. Wrong choice for raw TCP/UDP workloads or anything requiring the original client source IP with minimal handling overhead.

Network Load Balancer (NLB)

Operates at Layer 4. Characteristics: extreme throughput (millions of packets per second), ultra-low and consistent latency, native preservation of client source IP (no re-terminate/re-establish step), and a static IP address per Availability Zone. The static IP matters operationally — enterprise clients and partner firewalls frequently require IP allow-listing rather than trusting DNS resolution, and NLB is the only one of the three that exposes this natively. Fits raw TCP/UDP traffic, gaming backends, IoT ingestion, or any workload where packet throughput and predictable latency dominate over HTTP-layer routing intelligence. ALB does not expose a static IP; the combination for “HTTP routing plus a static IP” is Global Accelerator fronting the ALB, not forcing NLB into an HTTP-routing role it was never built for.

Gateway Load Balancer (GWLB)

Solves a problem the other two do not touch: transparent inline insertion of third-party virtual appliances — firewalls, intrusion detection/prevention systems — into the traffic path. Uses GENEVE encapsulation to distribute traffic across a fleet of appliances without either the client or the destination needing awareness that inspection is occurring in between. This is a network-security architecture primitive for centralized traffic inspection at scale, not a general-purpose load-balancing decision. The appliance fleet behind GWLB still requires independent health checking and capacity planning — GWLB distributes load across the fleet, it does not manage the fleet’s own scaling.

Traffic distribution patterns

Classify traffic before selecting a load balancer: HTTP-shaped with routing/header requirements maps to ALB; raw TCP/UDP requiring throughput, latency, or source-IP fidelity maps to NLB; inline third-party appliance inspection maps to GWLB. A “one load balancer for everything” design that forces non-HTTP protocols through an ALB for perceived simplicity typically costs more in protocol fidelity and performance than it saves operationally. Target group health check configuration must match the actual failure mode to detect, independent of which load balancer type is in use.

ALB vs NLB vs GWLB

Common Pitfalls

• Pitfall: Defaulting to ALB for raw TCP workloads. Why: Familiarity bias — ALB is the most commonly used type, so teams reach for it regardless of traffic shape. Fix: Classify traffic by protocol and performance requirement first; use NLB for raw TCP/UDP needing throughput or source-IP preservation.
• Pitfall: Building a workaround to get a static IP on an HTTP-routed workload. Why: ALB doesn’t expose a static IP natively, and teams don’t know the correct combination pattern. Fix: Front the ALB with Global Accelerator when both HTTP routing and a static IP are required.
• Pitfall: Treating GWLB as a generic load balancing option. Why: The name suggests it belongs in the same category as ALB/NLB. Fix: Recognize GWLB as purpose-built for inline third-party appliance insertion, not general traffic distribution.
• Pitfall: Routing every protocol through a single ALB “to keep the architecture simple.” Why: Perceived operational simplicity is prioritized over protocol fidelity and performance. Fix: Use protocol-appropriate load balancers per workload; the added operational surface is smaller than the performance cost of forcing traffic through the wrong layer.

Interview Questions

• A partner requires IP allow-listing for an API that also needs path-based routing. Design the load balancer setup. — tests whether Global Accelerator + ALB is understood as the correct combination, not a compromise.
• Explain why GWLB would be chosen over a custom traffic-mirroring solution for inline firewall inspection. — tests understanding of what GWLB specifically solves versus a general load balancer.
• A gaming backend needs to handle millions of UDP packets per second at the lowest possible latency. Which load balancer, and why do the alternatives fall short? — tests whether NLB’s Layer 4 characteristics are understood mechanically, not just recited.
• Why doesn’t ALB expose a static IP the way NLB does, and what design pattern compensates for that? — tests whether the connection-termination model behind ALB is understood, not just the workaround.