AWS Compute Services: Elastic Load Balancing (ELB)
Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions. It handles the varying load of your application traffic in a single Availability Zone or across multiple Availability Zones.
The Analogy: The Restaurant Host
Imagine a popular restaurant. If every customer tried to sit at the first table they saw, that waiter would be overwhelmed while others stood idle. The Load Balancer is the Host/Hostess at the front door. They look at the capacity of every section (Target Groups) and direct guests (Traffic) to the waiter who has the most availability, ensuring no one is overworked and every guest gets fast service.
Core ELB Types for SAA-C03
1. Application Load Balancer (ALB) – Layer 7
Best suited for HTTP and HTTPS traffic. Operates at the Request level. It is “content-aware,” meaning it can route traffic based on the content of the request (URL Path, Hostname, HTTP Headers).
- Routing: Path-based (/images vs /orders) and Host-based (api.example.com vs mobile.example.com).
- Features: Supports WebSockets, HTTP/2, and integration with AWS WAF.
- Targets: EC2, Containers (ECS), Lambda, and IP addresses.
2. Network Load Balancer (NLB) – Layer 4
Best suited for TCP, UDP, and TLS traffic where ultra-high performance and low latency are required. Operates at the Connection level.
- Performance: Capable of handling millions of requests per second while maintaining ultra-low latencies.
- Static IP: Provides a Static IP per Availability Zone, which is crucial for whitelisting in firewalls.
- Use Case: Gaming applications, financial platforms, and non-HTTP protocols.
3. Gateway Load Balancer (GLB) – Layer 3
Used to deploy, scale, and manage third-party virtual appliances (like Firewalls, Intrusion Detection Systems, or Deep Packet Inspection tools).
- Operation: Listens for all IP packets and transparently forwards traffic to the healthy appliance.
- GENEVE Protocol: Uses GENEVE encapsulation on port 6081.
Comparison Table: ALB vs. NLB vs. GLB
| Feature | ALB | NLB | GLB |
|---|---|---|---|
| OSI Layer | Layer 7 (Application) | Layer 4 (Transport) | Layer 3 (Network) |
| Protocols | HTTP, HTTPS, gRPC | TCP, UDP, TLS | IP (GENEVE) |
| Static IP | No (DNS Name only) | Yes (EIP per AZ) | No |
| Latency | ~100ms | <10ms (Ultra-low) | Low |
| Security | Security Groups + WAF | Security Groups | 3rd Party Appliances |
Exam Tips and Gotchas
- Cross-Zone Load Balancing: For ALB, it is always enabled (free). For NLB, it is disabled by default (costs money for inter-AZ data transfer if enabled).
- 504 Gateway Timeout: This means the application failed to respond within the idle timeout period. It is an application issue, not necessarily a load balancer issue.
- X-Forwarded-For: Because the ELB intercepts traffic, the target sees the ELB’s IP. Use the
X-Forwarded-Forheader to see the actual Client IP. - Sticky Sessions (Session Affinity): Used to ensure a user is routed to the same target for the duration of their session. Supported by ALB (via cookies).
- SNI (Server Name Indication): Allows you to host multiple SSL-protected websites (different domains) on a single ALB using multiple certificates.
Decision Matrix / If–Then Guide
- IF you need path-based or host-based routing THEN choose ALB.
- IF you need a static IP for your load balancer THEN choose NLB.
- IF the application is non-HTTP (e.g., SMTP or custom TCP) THEN choose NLB.
- IF you need to scale a fleet of 3rd party firewalls THEN choose GLB.
- IF you see “Extreme Performance” or “Millions of requests” THEN choose NLB.
Topics covered:
Summary of key subtopics covered in this guide:
- Difference between Layer 4 (NLB) and Layer 7 (ALB) load balancing.
- Advanced routing capabilities of the Application Load Balancer.
- High-performance requirements and Static IP needs with Network Load Balancers.
- Centralized security appliance management with Gateway Load Balancers.
- Health checks, Target Groups, and Sticky Sessions.
- Troubleshooting common ELB errors (504, 502).
ELB Architectural Ecosystem
Integrations:
- ACM: SSL/TLS certificate management.
- WAF: Protect ALB from SQLi and XSS.
- IAM: Control who can manage ELB.
- CloudWatch: Monitor 4xx/5xx errors and healthy host counts.
Scaling Mechanics:
- ELB scales automatically to handle traffic.
- Pre-warming: For sudden spikes, contact AWS support to pre-warm the ELB (rarely needed for NLB).
- Health Checks: ELB stops sending traffic to “Unhealthy” instances automatically.
Billing (LCU):
- Charged per hour + Load Balancer Capacity Units (LCU).
- LCU measures: New connections, Active connections, Processed bytes, and Rule evaluations.
- Consolidate multiple sites on one ALB using SNI to save costs.
Production Use Case: A microservices architecture where the /api path goes to an ECS cluster, /static goes to an S3 bucket (via CloudFront), and the root / goes to a fleet of EC2 instances. Solution: Use an Application Load Balancer with Path-based routing rules.