Elastic Load Balancing (ELB)
Elastic Load Balancing distributes incoming traffic across targets in one or more Availability Zones, and stops sending traffic to a target when its health check fails.
There are four types.
- Application Load Balancer (ALB) — layer 7, application-aware. For HTTP and HTTPS, with routing on host, path, header, method, query string and source IP.
- Network Load Balancer (NLB) — layer 4. For TCP, UDP and TLS, at very high connection rates and very low latency.
- Gateway Load Balancer (GWLB) — layer 3. For inserting third-party virtual appliances, such as firewalls and intrusion detection, transparently into a traffic path.
- Classic Load Balancer (CLB) — the original, spanning layers 4 and 7. Retained for existing deployments only.
Comparison
Section titled “Comparison”| Feature | Application (ALB) | Network (NLB) | Gateway (GWLB) | Classic (CLB) |
|---|---|---|---|---|
| OSI layer | 7 (application) | 4 (transport) | 3 (network) | 4 and 7 |
| Protocols | HTTP, HTTPS, gRPC, WebSocket | TCP, UDP, TLS | IP, with GENEVE to the appliances | TCP, SSL/TLS, HTTP, HTTPS |
| Latency added | Sub-millisecond | Sub-millisecond, and the lowest of the four | Low | Sub-millisecond |
| Throughput | High | Highest; millions of requests per second | High | Moderate |
| Static IP | No | Yes, one per Availability Zone | Yes | No |
| Elastic IP | No | Yes | No | No |
| Path and host-based routing | Yes | No | No | No |
| Redirects and fixed responses | Yes | No | No | No |
| HTTP/2 and gRPC | Yes | No | Not applicable | No |
| WebSocket | Yes | Yes | Not applicable | Limited |
| TLS termination | Yes | Yes | Not applicable | Yes |
| Server Name Indication | Yes | Yes | Not applicable | No |
| User authentication (OIDC, Cognito) | Yes | No | No | No |
| AWS WAF integration | Yes | No | No | No |
| Sticky sessions | Yes | Yes, per target group | Not applicable | Yes |
| Connection draining | Yes (deregistration delay) | Yes (deregistration delay) | Not applicable | Yes |
| Health checks | HTTP, HTTPS, gRPC, TCP | TCP, HTTP, HTTPS | TCP, HTTP, HTTPS | TCP, HTTP, HTTPS, SSL |
| Cross-zone load balancing | On at the load balancer; can be turned off per target group | Off by default | Off by default | Off by default via API/CLI, on by default via the console |
| Target types | instance, ip, lambda | instance, ip, alb | instance, ip | EC2 instances |
| Transparent network gateway | No | No | Yes | No |
| Use for | HTTP and HTTPS applications, microservices, containers | TCP and UDP workloads, extreme performance, static IP requirements | Third-party firewalls, IDS/IPS, deep packet inspection | Existing deployments only — use ALB or NLB for anything new |
Target types
Section titled “Target types”ALB and NLB register targets in target groups, and a target group has a type:
instance— an EC2 instance ID; the load balancer reaches it on its primary private address.ip— a private IPv4 or IPv6 address. This is what reaches targets in a peered VPC, on-premises over Direct Connect or VPN, or in a container with its own address. Registering10.0.1.23directly is normal and supported; a fully qualified domain name is not required.lambda— an ALB can invoke a Lambda function as a target.alb— an NLB can forward to an Application Load Balancer, which is how you put a static IP address in front of an ALB.
Cross-zone load balancing
Section titled “Cross-zone load balancing”With cross-zone load balancing on, every load balancer node distributes across targets in all enabled Availability Zones. With it off, each node distributes only to targets in its own zone.
The difference matters when zones hold different numbers of targets. Two zones, one with two targets and one with eight: with cross-zone on, each of the ten targets receives 10% of traffic; with it off, the two targets in the first zone take 25% each and the eight in the second take 6.25% each.
Defaults differ by type, and ALB’s changed: cross-zone is always on at the ALB level but can be turned off per target group. NLB and GWLB default to off and can be turned on. Turning it off keeps traffic zonal, which reduces cross-zone data transfer charges and contains the blast radius of a zone failure — at the cost of needing balanced capacity in every zone.
Scaling and IP addresses
Section titled “Scaling and IP addresses”Load balancer nodes scale with traffic and consume private addresses from the subnets they are placed in. Leave headroom: a subnet that is nearly full prevents the load balancer scaling up, and the symptom is a capacity failure rather than an address error.
An ALB requires at least two Availability Zones. All four types require the target’s Availability Zone to be enabled on the load balancer, or registered targets there receive nothing.
Sticky sessions
Section titled “Sticky sessions”Sticky sessions bind a client to one target for the life of a session, using a cookie on an ALB or CLB and source-IP affinity on an NLB. They are necessary for applications that keep session state in memory — a shopping basket, a login session — and they undermine even distribution, complicate deployments and make a target failure user-visible.
Where you can, keep session state outside the instance in ElastiCache or DynamoDB and leave stickiness off.
Choosing
Section titled “Choosing”- HTTP or HTTPS with any routing requirement, WAF, or authentication → ALB
- TCP or UDP, millions of connections, or a static IP address → NLB
- Traffic that must pass through a third-party appliance → GWLB
- Nothing new → CLB
An ALB behind an NLB is a common pairing when an HTTP application needs both layer 7 routing and a static IP.
Related pages
Section titled “Related pages”- Gateway Load Balancer
- CloudFront SSL/TLS and SNI configuration — how SNI works on a load balancer