AWS Networking & CDN
Elastic Load Balancing
Distribute incoming traffic across multiple targets for fault tolerance and scaling
Elastic Load Balancing automatically distributes incoming application traffic across multiple targets - EC2 instances, containers, Lambda functions, or IP addresses - across one or more Availability Zones. It is the primary mechanism for building fault-tolerant, horizontally scalable applications on AWS and comes in three distinct types optimized for different use cases.
Load Balancer Types Compared
AWS offers three load balancer types under the ELB umbrella. Each operates at a different OSI layer and has different capabilities.
| Feature | Application LB (ALB) | Network LB (NLB) | Gateway LB (GWLB) |
|---|---|---|---|
| OSI Layer | Layer 7 (HTTP/HTTPS) | Layer 4 (TCP/UDP/TLS) | Layer 3+4 (IP packets) |
| Protocols | HTTP, HTTPS, gRPC, WebSocket | TCP, UDP, TLS, TCP_UDP | GENEVE (6081) |
| Use case | Web apps, microservices, API routing | Low latency, static IP, non-HTTP | Inline network security appliances |
| Target types | Instance, IP, Lambda | Instance, IP, ALB | Instance, IP |
| Content-based routing | Host, path, header, query string, source IP | None (port-based only) | None |
| Sticky sessions | Yes (app cookie or LB cookie) | Yes (source IP) | N/A |
| Static IP / Elastic IP | No (use Global Accelerator) | Yes (one per AZ) | N/A |
| Preserve source IP | Via X-Forwarded-For header | Native (no proxy headers needed) | Native |
| Price per LCU/NLCU | $0.008/LCU-hr | $0.006/NLCU-hr | $0.004/GLCU-hr |
Classic Load Balancer (CLB) is the legacy type and should not be used for new architectures. It lacks content-based routing and is being deprecated. Migrate all CLBs to ALB or NLB.
ALB Listener Rules and Advanced Routing
ALB listeners evaluate rules in priority order (lowest number wins). Each rule has conditions and an action. This enables hosting multiple services behind a single load balancer.
| Condition Type | Example | Use Case |
|---|---|---|
| Host header | api.example.com vs app.example.com | Route to different target groups per subdomain |
| Path pattern | /api/* vs /admin/* | Microservices routing based on URL path |
| HTTP method | GET, POST, DELETE | Read/write routing to different backends |
| HTTP header | X-Version: v2 | API version routing; feature flags |
| Query string | ?env=canary | A/B testing based on query parameter |
| Source IP | 10.0.0.0/8 | Internal vs external traffic routing |
ALB supports weighted target groups for blue/green or canary deployments. You can send 90% to the current version and 10% to the new version directly at the load balancer level without DNS changes.
# Create an ALB listener rule for path-based routing
aws elbv2 create-rule \
--listener-arn arn:aws:elasticloadbalancing:us-east-1:123:listener/app/my-alb/abc/def \
--priority 10 \
--conditions '[{"Field":"path-pattern","Values":["/api/*"]}]' \
--actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/api-tg/xyz"}]'Target Groups and Health Checks
Target groups route requests to registered targets and perform health checks. Only healthy targets receive traffic.
| Setting | Description | Recommendation |
|---|---|---|
| Protocol | HTTP/HTTPS/TCP/TLS depending on LB type | Use HTTP for ALB (TLS terminated at LB) |
| Health check path | URL path for health ping (ALB) | /health or /ping returning 200 |
| Healthy threshold | Consecutive checks before marking healthy | 2 (faster recovery) |
| Unhealthy threshold | Consecutive failures before marking unhealthy | 2-3 (balance speed vs flapping) |
| Health check interval | Seconds between checks (5-300) | 10-30s depending on sensitivity needed |
| Deregistration delay | Seconds to drain connections before removing target | 30-300s; reduce for Lambda/containers |
| Slow start duration | Warmup period before target gets full traffic | Use for apps with JVM or cold start warmup needs |
The deregistration delay (connection draining) defaults to 300 seconds. For containerized workloads or Lambda, this means a deployment takes 5+ minutes to drain. Lower it to 30-60 seconds for faster deployments on stateless services.
SSL Termination, Sticky Sessions, and Access Logs
ALB and NLB handle TLS termination, though with different capabilities. Sticky sessions and access logs round out the operational features.
| Feature | ALB | NLB |
|---|---|---|
| TLS termination | Yes; ACM or imported cert | Yes; or TLS passthrough to targets |
| SNI support | Yes (multiple certs per listener) | Yes (multiple certs per listener) |
| TLS passthrough | No | Yes (TCP listener, target handles TLS) |
| Sticky sessions | App-based or duration-based cookie | Source IP 5-tuple hash |
| Access logs | S3; includes request details, target response | S3; connection-level logs |
| Cross-zone load balancing | Enabled by default (no charge) | Disabled by default (charge if enabled) |
Cross-zone load balancing on NLB incurs data transfer charges when enabled. ALB has it on by default at no extra cost. This is an important interview distinction - NLB cross-zone is not free.
Interview Focus Points
- 1What are the key differences between ALB and NLB? When would you choose NLB over ALB?
- 2How does ALB path-based routing work? Walk through a multi-service routing configuration.
- 3Explain connection draining (deregistration delay) and why it matters for zero-downtime deployments.
- 4How would you implement blue/green deployment using ALB weighted target groups?
- 5What is the X-Forwarded-For header and why does it matter for NLB vs ALB?
- 6How do sticky sessions work in ALB? What are the consistency trade-offs?
- 7A target group shows targets as unhealthy even though the instances are running. How do you debug this?
- 8Explain cross-zone load balancing and the pricing difference between ALB and NLB.
- 9How does Gateway Load Balancer work for inline security appliances?