Why Load Balancing Matters
Elastic Load Balancing (ELB) distributes incoming traffic across multiple targets — EC2 instances, containers, or IP addresses — spread across multiple Availability Zones, so no single server becomes a bottleneck and the failure of one instance or an entire zone doesn't take the whole application down. Beyond distributing load, the load balancer acts as a single stable DNS entry point for clients, decoupling them from the constantly changing set of backend instances that an Auto Scaling group adds and removes, and it continuously runs health checks against each target so traffic is only routed to instances currently able to serve requests correctly.
Cricket analogy: A load balancer is like a bowling captain rotating overs fairly between the available bowlers based on who's fit and performing, rather than exhausting one bowler while others rest unused on the sidelines.
Application Load Balancer vs. Network Load Balancer
The Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS), so it can inspect request content and route based on URL path, hostname, HTTP header, or query string — enabling patterns like routing /api/* to one target group and /images/* to another from a single load balancer — and it natively supports WebSockets, HTTP/2, and integrates with AWS WAF for request-level filtering. The Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP/TLS), forwarding raw connections without inspecting application content, which gives it extreme throughput and ultra-low latency along with the ability to preserve the client's source IP and assign a static IP address per Availability Zone — making it the right choice for latency-sensitive workloads like gaming backends, IoT ingestion, or financial trading systems.
Cricket analogy: An ALB is like an umpire who reviews the actual content of a delivery (line, length, seam position) via DRS before making a decision, while an NLB is like a scorer who just records that a ball was bowled and where it went, without judging its content — fast, but content-blind.
# Create an Application Load Balancer
aws elbv2 create-load-balancer \
--name web-app-alb \
--subnets subnet-aaa111 subnet-bbb222 \
--security-groups sg-0123456789abcdef0 \
--type application
# Create a target group with HTTP health checks on /health
aws elbv2 create-target-group \
--name web-tg \
--protocol HTTP --port 80 \
--vpc-id vpc-0123456789abcdef0 \
--health-check-path /health \
--health-check-interval-seconds 15 \
--healthy-threshold-count 2 --unhealthy-threshold-count 3
# Add a path-based routing rule: send /api/* to a separate target group
aws elbv2 create-rule \
--listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/web-app-alb/abc/def \
--priority 10 \
--conditions Field=path-pattern,Values='/api/*' \
--actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/api-tg/xyz789Listeners, Target Groups, and Cross-Zone Balancing
A listener defines the protocol and port the load balancer accepts connections on (e.g., HTTPS on 443), and each listener has one or more rules that forward matching requests to a target group — a logical set of registered targets that share health check settings and a routing algorithm like round robin or least outstanding requests. Cross-zone load balancing, enabled by default on ALBs, distributes traffic evenly across all registered targets in all enabled Availability Zones regardless of which zone received the original connection, whereas on an NLB it must be explicitly enabled and can incur cross-AZ data transfer charges — an important cost and architecture consideration when you have an uneven number of targets per zone.
Cricket analogy: A target group is like a bowling attack roster grouped by role, the pace group and the spin group, each evaluated by different fitness criteria, health checks, before the captain decides who actually bowls the next over.
ALBs support content-based routing rules using host headers, path patterns, HTTP methods, query strings, and even source IP, letting a single ALB serve multiple microservices or even multiple domains (api.example.com and app.example.com) through one load balancer with rules directing each to the correct target group.
An NLB does not inspect HTTP content, so it cannot perform path-based or host-based routing, apply AWS WAF rules, or terminate TLS with the same content-aware flexibility as an ALB — choosing NLB for a workload that later needs Layer 7 routing logic typically forces an architecture rework, so pick the load balancer type based on actual protocol and latency requirements up front.
- ELB distributes traffic across healthy targets in multiple Availability Zones and provides a stable DNS entry point decoupled from changing backend instances.
- Application Load Balancers operate at Layer 7, enabling content-based routing by path, host, or header, plus WAF integration.
- Network Load Balancers operate at Layer 4, offering ultra-low latency, extreme throughput, static IPs, and client IP preservation.
- Listeners define the accepted protocol and port; rules on a listener forward matching requests to target groups.
- Target groups share health check settings and a routing algorithm like round robin or least outstanding requests.
- Cross-zone load balancing is on by default for ALBs but must be explicitly enabled (and may incur charges) on NLBs.
- Choosing the wrong load balancer type for future routing needs (NLB when Layer 7 logic is needed later) often forces a costly rework.
Practice what you learned
1. At which OSI layer does an Application Load Balancer operate, enabling content-based routing?
2. Why would you choose a Network Load Balancer over an Application Load Balancer?
3. What is a target group in the context of Elastic Load Balancing?
4. How does cross-zone load balancing behave differently between ALB and NLB by default?
Was this page helpful?
You May Also Like
Auto Scaling Groups
Learn how EC2 Auto Scaling Groups automatically add and remove instances based on demand, using launch templates, scaling policies, and health checks.
EC2 Fundamentals
Learn what Amazon EC2 is, how virtual server instances work in the cloud, and how to launch, connect to, and manage them safely.
AWS Lambda Basics
Learn how AWS Lambda's serverless compute model works, including function packaging, triggers, execution roles, and how billing differs from EC2.