Elastic Load Balancing (ALB, NLB, CLB)

Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple EC2 instances, containers, or IP addresses. Load balancers are essential for high availability, fault tolerance, and horizontal scaling. This lesson covers the three main types: Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB).

---

Why Load Balancers?

Without a load balancer, clients connect directly to individual instances. This creates several problems:

• Single point of failure — if the instance goes down, the service is unavailable
• Uneven load — some instances may be overwhelmed while others are idle
• No health checking — unhealthy instances continue receiving traffic
• Manual scaling — you must update DNS or client configuration when adding/removing instances

A load balancer solves all of these:

Benefit	Description
High availability	Traffic is routed only to healthy instances
Scalability	Add or remove instances without client changes
Health checking	Automatically detect and route around failures
SSL termination	Offload TLS decryption from backend instances
Sticky sessions	Route requests from the same client to the same target
Cross-zone balancing	Distribute traffic evenly across all AZs

---

Load Balancer Types at a Glance

Feature	ALB	NLB	CLB
Layer	7 (HTTP/HTTPS)	4 (TCP/UDP/TLS)	4 + 7 (limited)
Target types	Instance, IP, Lambda	Instance, IP, ALB	Instance
Protocols	HTTP, HTTPS, gRPC	TCP, UDP, TLS	TCP, SSL, HTTP, HTTPS
WebSockets	Yes	Yes	No
Static IP	No (use Global Accelerator)	Yes (per AZ)	No
Performance	Millions of requests/sec	Millions of connections/sec	Limited
Content-based routing	Yes (host, path, headers, query string)	No	No
Use case	Web apps, microservices, REST APIs	Ultra-low latency, TCP workloads, IoT	Legacy (avoid for new deployments)

---

Application Load Balancer (ALB)

The ALB operates at Layer 7 (HTTP/HTTPS) and is the best choice for most web applications.

Key Features

Content-Based Routing

ALB can route requests based on the content of the HTTP request:

Condition	Description	Example
Host header	Route by domain name	api.example.com → API target group
Path	Route by URL path	/images/* → image-service target group
HTTP headers	Route by any header value	Custom-Region: eu → EU target group
Query string	Route by query parameters	?platform=mobile → mobile target group
HTTP method	Route by method	POST → write-service target group
Source IP	Route by client IP range	10.0.0.0/8 → internal target group

Listener (port 443)
├── Rule 1: Host = api.example.com → Target Group: api-servers
├── Rule 2: Path = /images/* → Target Group: image-servers
├── Rule 3: Path = /api/v2/* → Target Group: api-v2-servers
└── Default action → Target Group: web-servers

Target Groups

A target group is a collection of targets (instances, IPs, or Lambda functions) that the ALB routes traffic to.

# Create a target group
aws elbv2 create-target-group \
  --name my-web-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-0123456789abcdef0 \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 3 \
  --unhealthy-threshold-count 3 \
  --target-type instance

# Register instances
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/my-web-targets/abc123 \
  --targets Id=i-0123456789abcdef0 Id=i-0987654321fedcba0

Health Checks

ALB health checks send HTTP requests to your targets and evaluate the response:

Setting	Description	Default
Path	URL path to check	/
Protocol	HTTP or HTTPS	HTTP
Port	Port to check	Traffic port
Interval	Time between checks	30 seconds
Timeout	Time to wait for response	5 seconds
Healthy threshold	Consecutive successes to mark healthy	5
Unhealthy threshold	Consecutive failures to mark unhealthy	2
Success codes	HTTP codes considered healthy	200

SSL/TLS Termination