Elastic Load Balancing
ELB is the traffic-distribution layer that places multiple servers or tasks behind one endpoint and spreads incoming requests across them. It helps keep only healthy targets in rotation and gives the service front door high availability.
▶Architecture Diagram
🔍 StructureDashed line animations indicate the flow direction of data or requests
You may run several EC2 instances or containers, but users should still know only one address and unhealthy targets should disappear automatically. Once each application starts carrying its own traffic-splitting rules, operations become less stable as deployments grow.
In the past, web servers had to run their own proxies or load balancers and handle failure detection and scaling themselves. This is why ELB, which provides distribution and health checks as a service, became the default ingress layer.
ELB uses listeners and target groups to distribute requests to EC2 instances, ECS tasks, Fargate tasks, or IP targets. Health checks exclude unhealthy targets, and you can choose ALB for HTTP and HTTPS traffic, NLB for ultra-low-latency TCP traffic, or GWLB for network appliances.
ELB and API Gateway both sit in front of requests, but for different purposes. ELB is strong at distributing traffic across healthy servers or tasks and maintaining availability, while API Gateway is strong at authentication, throttling, and API policy management. If the main problem is stable traffic distribution to a service fleet, look at ELB; if the main problem is running a public API as a product, look at API Gateway.
Well-suited for web apps, container services, multi-instance APIs, ingress with path-based routing, and low-latency TCP traffic distribution. Not a good fit when API-level authentication, throttling, and usage control are the primary concerns.