3.1.1.8. Configuring Load Balancing to Support Cross-AZ Services
3.1.1.8. Configuring Load Balancing to Support Cross-AZ Services
Load balancers distribute traffic across healthy targets in multiple AZs — they're the first line of defense against AZ failures for your compute tier.
ALB vs. NLB selection:
| Feature | ALB (Application) | NLB (Network) |
|---|---|---|
| Layer | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) |
| Routing | Path, host, header, query string | Port-based |
| Targets | Instances, IPs, Lambda | Instances, IPs, ALBs |
| Performance | Moderate latency | Ultra-low latency, millions of RPS |
| Use case | Web apps, microservices, API routing | Real-time gaming, IoT, TCP services |
Cross-zone load balancing: By default, ALB distributes traffic evenly across all registered targets in all enabled AZs. NLB distributes per-AZ by default — enable cross-zone load balancing if target counts are uneven across AZs.
Health checks determine target availability:
# ALB health check configuration
HealthCheckProtocol: HTTP
HealthCheckPath: /health # Custom endpoint, not just /
HealthCheckIntervalSeconds: 15
HealthyThresholdCount: 2 # 2 consecutive passes = healthy
UnhealthyThresholdCount: 3 # 3 consecutive fails = unhealthy
Connection draining (deregistration delay) allows in-flight requests to complete before removing a target. Default is 300 seconds — reduce for stateless APIs to speed up deployments.
Exam Trap: ALB health checks and Auto Scaling health checks are independent systems. If an instance fails the ALB health check, ALB stops routing traffic — but Auto Scaling won't replace it unless you set the ASG health check type to ELB (default is EC2, which only checks instance status). For proper self-healing, always configure ASG health check type as ELB when using a load balancer.
