Learning Objectives
- Differentiate Application Load Balancer, Network Load Balancer, and Classic Load Balancer
- Choose the right load balancer for your workload
- Understand cross-zone balancing and connection draining
Cloud Load Balancing Basics
A load balancer distributes incoming traffic across multiple targets — EC2 instances, containers, Lambda functions, or IP addresses. Cloud providers offer three main types, each optimized for different protocols and use cases.
Application Load Balancer (ALB)
ALB operates at Layer 7 (HTTP/HTTPS). It understands the application protocol and can route based on URL path, host header, query string, or HTTP method. This makes it ideal for microservices architectures where a single ALB can route to multiple backend services.
Example: Route api.example.com/* to containerized API servers and app.example.com/* to web frontends — one ALB, two target groups.
Network Load Balancer (NLB)
NLB operates at Layer 4 (TCP/UDP/TLS). It handles millions of requests per second with extremely low latency by preserving the source IP and using a static IP per Availability Zone. NLB is the right choice for non-HTTP protocols, UDP-based applications, or when you need extreme performance.
Gateway Load Balancer (GWLB)
GWLB is the newest type — it sits inline in the network path and distributes traffic to third-party appliances like firewalls, intrusion detection systems, or packet inspection tools. It uses the GENEVE protocol on port 6081.
Match each load balancer type to its best-fit scenario.
Hints
- Think OSI layer — what protocol does each operate at?
- Some load balancers understand application content
- One type is designed for security appliances, not application servers
Load Balancer Comparison
| Feature | ALB | NLB | GWLB | |---------|-----|-----|------| | OSI Layer | 7 (Application) | 4 (Transport) | 3/4 (Network) | | Protocols | HTTP, HTTPS, gRPC | TCP, UDP, TLS | IP (GENEVE) | | Latency | Moderate | Ultra-low | Low | | Static IP | No (uses ALB DNS) | Yes (per AZ) | Yes | | Target types | Instances, IP, Lambda, ECS | Instances, IP, ALB | Instances, IP | | WebSocket | Native | Via target group | No |
Cross-Zone Load Balancing
When enabled, cross-zone balancing distributes traffic evenly across all targets in all enabled AZs, not just within the same AZ. This prevents uneven load distribution when targets are unbalanced across AZs.
Connection Draining
Connection draining (also called deregistration delay) lets in-flight requests complete before a target is removed from the pool. Set this high enough for long-lived requests — 300 seconds is a good default for web applications.
Which load balancer type supports routing based on HTTP request headers?
Why would you choose NLB over ALB?
Key Takeaways
- ALB for HTTP/HTTPS applications with content-based routing
- NLB for TCP/UDP, extreme performance, and static IP requirements
- GWLB for inline security appliance deployment
- Enable cross-zone load balancing for even traffic distribution
- Always configure connection draining to prevent dropped requests during deployments