Elastic Load Balancing
ELB
You need to distribute incoming web traffic across a pool of servers to prevent overload and ensure high availability.
Reach for it when
- Exposing a pool of EC2 or ECS application containers to the public internet under a single domain.
- Implementing path-based or host-based routing to direct traffic to different backend microservices.
- Terminating SSL/TLS certificates at the network edge to offload cryptographic overhead from application servers.
Do not reach for it when
- Distributing traffic to simple static web pages hosted on object storage — use CloudFront instead.
- Routing traffic based on geographic user proximity or database health queries — use Route 53 latency routing instead.
- Managing traffic routing between serverless functions running on demand — use API Gateway instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| API Gateway | Choose it when exposing serverless workloads or requiring advanced API rate limiting and key management. |
| Route 53 | Choose it when distributing traffic at the DNS level across different physical regions. |
How you pay
- The model
- Pay an hourly fee per balancer plus a Load Balancer Capacity Unit fee based on active connections.
- The line item that surprises people
- Sudden traffic spikes can trigger high capacity unit charges, especially if connections are held open for long periods.
What trips people up
- ELB requires backend instances to pass active health checks; a misconfigured path causes the balancer to drop all backend targets.
- Cross-zone load balancing is enabled by default but can incur inter-AZ data transfer fees if not carefully configured.
- The Application Load Balancer does not have a static IP; you must use a Network Load Balancer if static IPs are required.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.