Load Balancers in AWS
⚖️ What is an Elastic Load Balancer (ELB)?
Elastic Load Balancer automatically distributes incoming traffic across multiple EC2 instances, containers, IPs, or Lambda functions to ensure:
- High availability
- Fault tolerance
- Scalability
✅ ELB is fully managed by AWS and works across multiple Availability Zones (AZs).
🔧 Types of Load Balancers in AWS
| Type | Description | Best For |
|---|---|---|
| Application Load Balancer (ALB) | Layer 7 (HTTP/HTTPS), content-based routing | Web apps, microservices, path-based routing |
| Network Load Balancer (NLB) | Layer 4 (TCP/UDP), ultra-low latency, handles millions of requests | Gaming, real-time systems, IoT, TCP-heavy apps |
| Gateway Load Balancer (GWLB) | Deploys and manages third-party virtual appliances (firewalls, etc.) | Security and network inspection |
| Classic Load Balancer (CLB) | Legacy Layer 4/7 load balancing | Old generation apps, not recommended anymore |
🔄 How ELB Works (High-Level Flow)
- Client sends request to ELB DNS (e.g.,
myapp-123456.elb.amazonaws.com) - ELB receives and distributes the request to one of the healthy targets
- If a target fails, ELB automatically reroutes traffic to healthy ones
🧪 Example: Application Load Balancer (ALB)
- Supports host-based routing (
api.example.comvsadmin.example.com) - Supports path-based routing (
/images,/videos) - Integrates with AWS WAF, Cognito, Lambda, Auto Scaling
✅ Key Features
| Feature | Benefit |
|---|---|
| Health checks | Routes traffic only to healthy targets |
| Auto scaling support | Works seamlessly with EC2 Auto Scaling |
| Sticky sessions | Can bind users to specific targets (optional) |
| HTTPS termination | ELB handles SSL, keeps backend traffic HTTP |
| Logging | Access logs can be sent to S3 for auditing |
| Zonal isolation | Traffic routed only to healthy AZs |
📦 Pricing
- Charged per hour + per GB processed
- No charge for idle instances — only for the load balancer usage
✅ Summary Table
| Feature | Application LB | Network LB | Gateway LB |
|---|---|---|---|
| Layer | 7 (HTTP/HTTPS) | 4 (TCP/UDP) | N/A (Traffic Gateway) |
| Use Case | Web apps, APIs | High-throughput, low latency | Security appliances |
| Advanced Routing | ✅ Yes | ❌ No | ❌ No |
| SSL Termination | ✅ Yes | ✅ Yes | ❌ No |
| Health Checks | ✅ Layer 7 | ✅ Layer 4 | ✅ |
⚖️ 1. Application Load Balancer (ALB) – Layer 7 (HTTP/HTTPS)
✅ Best For:
- Web applications
- REST APIs
- Microservices
- HTTP/HTTPS traffic
📌 Features:
- Path-based routing (e.g.,
/login,/checkout) - Host-based routing (e.g.,
api.example.com) - Supports WebSocket and HTTP/2
- Native integration with AWS WAF and Cognito for authentication
- Target types: EC2, IPs, Lambda functions, ECS services
📦 Example Use Case:
Route example.com/api/* to backend API servers
and example.com/images/* to image-processing servers
⚡ 2. Network Load Balancer (NLB) – Layer 4 (TCP/UDP)
✅ Best For:
- High-performance, low-latency applications
- Gaming servers
- Real-time chat, streaming apps
- IoT devices and edge systems
📌 Features:
- Handles millions of requests per second
- Static IP support
- Preserves client IP
- Load balances TCP, UDP, and TLS traffic
- Supports TLS termination (for encrypted traffic)
📦 Example Use Case:
Distribute TCP traffic to backend servers for a multiplayer game.
🛡️ 3. Gateway Load Balancer (GWLB) – Transparent traffic inspection
✅ Best For:
- Deploying third-party network appliances (e.g., firewall, intrusion detection)
- Transparent traffic filtering and monitoring
📌 Features:
- Integrates with security appliances (Palo Alto, Fortinet, etc.)
- Deploy at scale across multiple AZs
- Works with VPC traffic mirroring
📦 Example Use Case:
Deploy a third-party firewall cluster that filters all VPC egress traffic.
📦 4. Classic Load Balancer (CLB) – Legacy Layer 4/7
✅ Best For:
- Legacy systems or apps built before 2016
- Still used in older architectures
📌 Features:
- Basic Layer 4 (TCP) and Layer 7 (HTTP/HTTPS) support
- Lacks modern features like host/path routing
- AWS recommends migrating to ALB or NLB
📦 Example Use Case:
Simple web application using a CLB to route traffic to EC2 instances.
📊 Comparison Table
| Feature | ALB | NLB | GWLB | CLB |
|---|---|---|---|---|
| OSI Layer | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | N/A (Traffic Gateway) | 4 & 7 (basic support) |
| Routing Capabilities | Host & path-based | Port/IP-based | Transparent traffic inspection | Basic layer 4/7 |
| Target Types | EC2, Lambda, IP | EC2, IP | Appliance VMs | EC2 |
| Preserves Client IP | Yes | Yes | No | No |
| TLS Termination | Yes | Yes | No | Yes |
| WebSocket Support | Yes | No | No | No |
| WAF Integration | Yes | No | No | No |
| Best For | Modern web/API apps | High-performance, real-time apps | Security filtering appliances | Legacy apps |
✅ Summary
| Load Balancer | Use Case |
|---|---|
| ALB | Web apps, APIs, microservices |
| NLB | High-speed, low-latency, TCP/UDP-based apps |
| GWLB | Third-party firewalls, security appliances |
| CLB | Legacy support (not recommended for new apps) |
🌐 What is Cross-Zone Load Balancing?
Cross-Zone Load Balancing is an AWS feature that allows load balancers to distribute traffic evenly across all targets in all Availability Zones (AZs) — regardless of which AZ the request came from.
✅ Without cross-zone enabled, traffic is only distributed within the same zone as the load balancer's node.
📦 How It Works (With & Without Cross-Zone)
🔁 With Cross-Zone Enabled:
- A request entering AZ-1 can be routed to targets in AZ-2 or AZ-3.
- Ensures balanced traffic across all available targets.
🚫 Without Cross-Zone Enabled:
- A request handled by a load balancer in AZ-1 will only go to targets in AZ-1.
- Can lead to uneven load if one AZ has fewer or weaker instances.
🔍 Example Scenario
| AZ | EC2 Instances | Load Balancer Node |
|---|---|---|
| AZ-1 | 1 | ✅ |
| AZ-2 | 3 | ✅ |
- Without cross-zone: AZ-1 node only uses its 1 instance.
-
With cross-zone: AZ-1 node can distribute load across all 4 instances, ensuring better balance.
⚙️ Supported Load Balancers
| Load Balancer | Cross-Zone Support | Default State |
|---|---|---|
| Application LB (ALB) | ✅ Supported | ✅ Enabled by default |
| Network LB (NLB) | ✅ Supported (added later) | ❌ Disabled by default |
| Classic LB (CLB) | ✅ Supported | ✅ Enabled by default |
💰 Cost Considerations
For NLB, enabling cross-zone load balancing may increase data transfer costs between zones (intra-region data transfer).
🧠 When to Use Cross-Zone Load Balancing
✅ Use it when:
- You want even distribution across all backend instances
- Your AZs have unequal number of targets
- You're building fault-tolerant, highly available apps
❌ Avoid it if:
- You're cost-sensitive to cross-AZ data transfer
- You have zone-aware architecture with balanced target groups
✅ Summary
| Feature | Cross-Zone Load Balancing |
|---|---|
| Goal | Evenly distribute traffic across all AZs |
| Load Balancer Support | ALB, NLB, CLB |
| Default (ALB/CLB) | ✅ Enabled |
| Default (NLB) | ❌ Disabled (must enable manually) |
| Cost Impact (NLB) | Cross-AZ data transfer charges may apply |