Elastic Load Balancing
A load balancer service that automatically distributes incoming traffic across multiple targets, available in four types: ALB, NLB, GLB, and CLB
Overview
Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets such as EC2 instances, containers, Lambda functions, and IP addresses. Four types are available: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GLB), and Classic Load Balancer (CLB), selected based on workload characteristics. ALB handles Layer 7 routing for HTTP/HTTPS traffic, supporting path-based and host-based routing, WebSocket, and gRPC. NLB specializes in Layer 4 processing for TCP/UDP/TLS traffic, delivering ultra-low latency and the ability to handle millions of requests per second. All types operate across multiple Availability Zones and automatically stop sending traffic to unhealthy targets through health checks.
ALB and NLB - Choosing by Layer
The choice between ALB and NLB depends on the protocol layer your application operates at. ALB is a Layer 7 load balancer that understands HTTP/HTTPS protocols, enabling routing based on URL paths and host headers, request authentication (Cognito and OIDC integration), and WAF integration for protection against SQL injection and XSS. It is ideal for routing multiple services through a single ALB in microservices architectures, or when using WebSocket or gRPC. A unique ALB capability not found in Azure Application Gateway is the ability to register Lambda functions directly as targets, enabling serverless backends without additional infrastructure. NLB operates at Layer 4, forwarding TCP/UDP packets as-is, achieving microsecond-level latency - lower than ALB. It supports static IP address assignment and can serve as a PrivateLink endpoint service. It is suited for game servers, IoT device connections, VoIP, and other scenarios requiring TCP/UDP-level control.
Health Checks and Target Group Design
Target groups define the set of destinations that receive traffic from a load balancer. Each target group is configured with a health check that periodically probes targets and automatically removes unhealthy ones from the routing pool. For ALB, health checks use HTTP/HTTPS requests to a specified path, and you can tune the interval, timeout, healthy/unhealthy thresholds, and expected status codes. Matching the health check path to a lightweight endpoint (rather than a heavy application page) prevents false positives caused by slow responses under load. NLB health checks operate at the TCP level by default, verifying that the port is reachable, but can also be configured for HTTP checks when more granular health assessment is needed. Weighted target groups enable canary deployments by gradually shifting traffic percentages to a new version. For a systematic study of Elastic Load Balancing, books (Amazon) are a great resource.
Access Logs and Troubleshooting
ALB access logs capture detailed information about every request, including client IP, target response time, request path, HTTP status code, and TLS cipher. Storing these logs in S3 and querying them with Athena enables powerful traffic pattern analysis - identifying slow endpoints, tracking error rate trends, and diagnosing intermittent failures. Connection logs, available separately, record TLS handshake details useful for debugging certificate and cipher issues. NLB flow logs integrate with VPC Flow Logs to capture Layer 4 connection metadata. For troubleshooting, HTTP 502 errors on ALB typically indicate that the target closed the connection before sending a response, while 503 errors signal that no healthy targets are available. Monitoring the TargetResponseTime and UnHealthyHostCount CloudWatch metrics provides early warning of backend degradation before users are affected.