AWS Load Balancers Explained
Load balancers are one of the most important building blocks in AWS networking. They distribute incoming traffic across backend targets, improve availability, simplify scaling, and help applications handle production workloads more reliably.
In AWS, the main types are Application Load Balancer (ALB), Network Load Balancer (NLB), and the older Classic Load Balancer (CLB). Each one is designed for a different traffic pattern and networking requirement.
Watch this video to understand AWS load balancer types, traffic flow, and when to use ALB or NLB.
What is load balancing?
Load balancing is the process of distributing incoming network or application traffic across multiple backend resources, such as EC2 instances, containers, pods, or services. Instead of sending every request to a single server, a load balancer spreads requests more intelligently.
This improves availability, fault tolerance, scalability, and performance. If one backend becomes unhealthy, the load balancer can stop sending traffic to it and continue using healthy targets.
Stable front-end endpoint for users
Backend instances or services behind it
Traffic sent only to healthy targets
Why load balancing matters in AWS
In AWS, applications are often spread across multiple Availability Zones, auto scaling groups, ECS services, or Kubernetes workloads. A load balancer helps present all of that backend complexity as a single stable access point.
High availability
Traffic can continue flowing to healthy instances even if one backend fails.
Scalability
As new instances or targets are added, the load balancer can begin routing traffic to them automatically.
Operational simplicity
Clients connect to one front-end endpoint instead of tracking multiple backend servers.
Smarter routing
Some load balancers can route based on URL path, host name, or protocol-level behaviour.
AWS load balancer types
AWS provides different load balancer types because not all traffic behaves the same way. Some applications need Layer 7 routing, while others need very high-performance Layer 4 forwarding.
Application Load Balancer
ALB works at Layer 7. It understands HTTP and HTTPS traffic and can route requests based on hostnames, URL paths, headers, and more.
Network Load Balancer
NLB works at Layer 4. It is designed for TCP, UDP, and TLS traffic and is typically chosen for high-performance, low-latency use cases.
Classic Load Balancer
CLB is the older generation option. It can handle basic Layer 4 and Layer 7 workloads, but for most new architectures AWS users typically prefer ALB or NLB.
ALB vs NLB vs CLB
| Feature | ALB | NLB | CLB |
|---|---|---|---|
| OSI Layer | Layer 7 | Layer 4 | Layer 4 / Layer 7 (legacy) |
| Protocols | HTTP, HTTPS | TCP, UDP, TLS | HTTP, HTTPS, TCP |
| Path-based routing | Yes | No | Limited / legacy |
| Host-based routing | Yes | No | Limited / legacy |
| Static IP support | No | Yes | Limited / legacy design |
| Best for | Web apps and APIs | High-performance network traffic | Older workloads |
| Recommended for new designs | Yes | Yes | Usually no |
When to use which load balancer
Use ALB when
- You are running web applications or APIs over HTTP or HTTPS.
- You need path-based routing such as
/api,/admin, or/billing. - You want host-based routing such as
api.example.comandapp.example.com. - You are integrating with container platforms such as ECS or EKS.
Use NLB when
- You need very high performance and low latency Layer 4 routing.
- You are working with TCP, UDP, or TLS traffic.
- You need static IP support at the load balancer level.
- Your workload is not based on application-layer routing logic.
Use CLB only when
- You are maintaining older architectures that already depend on it.
- You have a legacy environment that has not yet been modernised to ALB or NLB.
Typical ALB pattern
Public website, microservices, REST APIs, Kubernetes ingress, path-based routing, TLS offload.
Typical NLB pattern
Protocol-heavy services, TCP-based systems, low-latency workloads, static IP expectations, Layer 4 handling.
Real-world traffic flow example
A typical internet-facing AWS application may look like this:
User
|
v
Route 53
|
v
CloudFront
|
v
Load Balancer
|
v
Target Group / Backend Targets
|
v
EC2 / ECS / EKS ApplicationIf the workload is an API or website, that load balancer is often an ALB. If the workload is protocol-heavy or requires faster Layer 4 routing, it may be an NLB.
Application Load Balancer and Network Load Balancer guides
This page is the overview hub. For deeper explanations, architecture patterns, troubleshooting, and implementation details, go to the child pages below.
Application Load Balancer (ALB)
Learn how ALB works, including Layer 7 routing, host-based routing, path-based routing, listeners, target groups, and real-world web application use cases.
Network Load Balancer (NLB)
Learn how NLB handles Layer 4 traffic, supports TCP and UDP workloads, provides static IP options, and fits high-performance or protocol-specific architectures.
Common load balancer mistakes
- Choosing ALB when the application really needs Layer 4 behaviour.
- Choosing NLB when the use case actually requires path-based or host-based routing.
- Not planning security groups, health checks, listeners, and target group design properly.
- Leaving the hub page empty and only creating child pages, which weakens internal site structure.
- Using inconsistent URLs such as
/alb/in one place and/aws/load-balancers/alb/in another.