2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB
Key Takeaways
- Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and supports path-based routing, host-based routing, and WebSocket.
- Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP) and handles millions of requests per second with ultra-low latency and static IP addresses.
- Gateway Load Balancer (GWLB) operates at Layer 3 and is used for deploying third-party virtual appliances (firewalls, IDS/IPS).
- ALB is the default choice for web applications; NLB is for extreme performance, static IPs, or non-HTTP protocols.
- Cross-zone load balancing distributes traffic evenly across all registered targets in all enabled AZs.
Elastic Load Balancing (ELB) — ALB, NLB, and GWLB
Quick Answer: Use ALB for HTTP/HTTPS web applications (Layer 7, content-based routing). Use NLB for extreme performance, static IPs, or non-HTTP protocols (Layer 4). Use GWLB for third-party virtual appliances. All ELBs support Multi-AZ for high availability.
ELB Overview
Elastic Load Balancing automatically distributes incoming traffic across multiple targets (EC2 instances, containers, IP addresses, Lambda functions) in one or more Availability Zones.
Why Load Balancers?
- High availability — Distribute traffic across multiple AZs
- Fault tolerance — Route traffic away from unhealthy targets
- Scalability — Handle varying traffic loads automatically
- Security — Terminate SSL/TLS at the load balancer
- Decoupling — Frontend does not need to know about backend instances
Application Load Balancer (ALB)
The ALB operates at Layer 7 (application layer) and is the best choice for HTTP/HTTPS traffic.
ALB Features
| Feature | Description |
|---|---|
| Layer | 7 (HTTP/HTTPS) |
| Routing | Path-based (/api/, /images/), host-based (api.example.com), HTTP header/method, query string |
| Targets | EC2 instances, IP addresses, Lambda functions, containers (ECS) |
| SSL/TLS | Terminate at ALB using ACM certificates |
| WebSocket | Native support |
| HTTP/2 | Native support |
| Sticky sessions | Duration-based or application-based cookies |
| Authentication | Built-in support for OIDC and Cognito |
| IP type | Dynamic IPs (use DNS name, not IP) |
ALB Routing Rules
| Routing Type | Example | Use Case |
|---|---|---|
| Path-based | /api/* → API target group | Microservices |
| Host-based | api.example.com → API TG; www.example.com → Web TG | Multi-domain hosting |
| HTTP header | Custom-Header: mobile → Mobile TG | A/B testing |
| Query string | ?platform=mobile → Mobile TG | Platform-specific routing |
| Source IP | 10.0.0.0/8 → Internal TG | Internal vs. external |
Network Load Balancer (NLB)
The NLB operates at Layer 4 (transport layer) and is designed for extreme performance.
NLB Features
| Feature | Description |
|---|---|
| Layer | 4 (TCP, UDP, TLS) |
| Performance | Millions of requests/second, ultra-low latency (~100ms vs ~400ms for ALB) |
| Static IP | One static IP per AZ (can assign Elastic IP) |
| Targets | EC2 instances, IP addresses, ALB (can front an ALB) |
| SSL/TLS | TLS termination supported |
| Source IP preservation | Preserves client source IP |
| Health checks | TCP, HTTP, HTTPS |
| Protocols | TCP, UDP, TLS, TCP_UDP |
When to Choose NLB
- Need static IP addresses or Elastic IPs
- Extreme performance (millions of requests/sec)
- Non-HTTP protocols (gaming, IoT, custom TCP)
- Need to preserve client source IP at the target
- Need to front an ALB with a static IP (NLB → ALB pattern)
Gateway Load Balancer (GWLB)
The GWLB operates at Layer 3 (network layer) and is designed for deploying third-party virtual appliances.
| Feature | Description |
|---|---|
| Layer | 3 (IP packets) |
| Use Case | Third-party firewalls, IDS/IPS, deep packet inspection |
| Protocol | GENEVE encapsulation on port 6081 |
| Deployment | Traffic flows through GWLB → appliance → back to GWLB |
| Scaling | Automatically scales appliance fleet |
ELB Comparison
| Feature | ALB | NLB | GWLB |
|---|---|---|---|
| Layer | 7 (HTTP/HTTPS) | 4 (TCP/UDP) | 3 (IP) |
| Static IP | No (use DNS) | Yes | Yes |
| Performance | Good | Extreme | Good |
| Routing | Content-based | Connection-based | N/A |
| WAF support | Yes | No | No |
| Lambda targets | Yes | No | No |
| Use case | Web apps, APIs | Extreme perf, static IP | Network appliances |
Cross-Zone Load Balancing
| Behavior | Without Cross-Zone | With Cross-Zone |
|---|---|---|
| Traffic distribution | Even across AZs (not across instances) | Even across ALL instances in all AZs |
| ALB default | Enabled (always on, free) | Enabled |
| NLB default | Disabled | Can enable (charges for inter-AZ data) |
Health Checks
All ELB types perform health checks on registered targets:
- Healthy threshold — Number of consecutive successes to mark healthy
- Unhealthy threshold — Number of consecutive failures to mark unhealthy
- Interval — Time between health checks
- Unhealthy targets receive no traffic until they pass health checks again
A company needs a load balancer with a static IP address to allow clients to whitelist the IP. The application uses HTTPS. Which load balancer should they use?
A web application requires routing requests to different target groups based on the URL path (e.g., /api/* to one group, /images/* to another). Which load balancer supports this?
A company needs to deploy third-party firewall virtual appliances to inspect all traffic entering their VPC. Which load balancer type should they use?