Elastic Load Balancing in a VPC

Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple targets — EC2 instances, containers, IP addresses, or Lambda functions — within your VPC. It improves availability by spreading load across Availability Zones and ensures that no single resource becomes a bottleneck. Understanding how ELB integrates with VPC networking is essential for any production architecture.

---

Why Load Balancing?

Without a load balancer:

• Users connect directly to a single server — if it fails, they get an error.
• You cannot scale horizontally; adding servers means changing DNS or client configuration.
• SSL termination, health checks, and request routing must be handled by the application.

With a load balancer:

• Traffic is distributed across multiple healthy targets.
• Unhealthy targets are automatically removed from rotation.
• You can scale in and out by adding or removing targets — the load balancer adapts.
• SSL termination can be offloaded to the load balancer.

---

Types of Elastic Load Balancers

AWS offers three types of load balancers, each designed for different use cases:

Type	Layer	Protocol	Best For
Application Load Balancer (ALB)	Layer 7 (HTTP/HTTPS)	HTTP, HTTPS, gRPC	Web applications, microservices, API routing
Network Load Balancer (NLB)	Layer 4 (TCP/UDP)	TCP, UDP, TLS	Ultra-low latency, millions of requests/sec
Gateway Load Balancer (GWLB)	Layer 3 (IP)	GENEVE	Third-party virtual appliances (firewalls, IDS)

The Classic Load Balancer (CLB) is the original ELB. It is legacy and not recommended for new workloads.

---

Application Load Balancer (ALB) — Deep Dive

The ALB is the most commonly used load balancer for web applications.

Key Features

Feature	Detail
Content-based routing	Route by host header, URL path, query string, HTTP method, headers
Target types	EC2 instances, IP addresses, Lambda functions, containers (ECS/EKS)
SSL termination	Terminates HTTPS at the ALB; forward HTTP to targets
WebSocket support	Native support for persistent connections
HTTP/2	Supported by default
Sticky sessions	Route a user's requests to the same target
Authentication	Integrates with Cognito or any OIDC provider

How ALB Routing Works

An ALB has one or more listeners (e.g., port 443). Each listener has rules that evaluate conditions and forward traffic to a target group.

Client → ALB (HTTPS:443)
          │
          ├── Rule: Host = api.example.com   → Target Group: API servers
          ├── Rule: Path = /images/*          → Target Group: Image service
          └── Default                         → Target Group: Web servers

Target Groups

A target group is a collection of targets that receive traffic from the ALB:

Setting	Description
Health check path	e.g., /health — ALB checks this endpoint periodically
Health check interval	Default 30 seconds
Healthy threshold	Number of consecutive successes before a target is considered healthy
Unhealthy threshold	Number of consecutive failures before a target is removed
Deregistration delay	Time to wait before removing a draining target (default 300 seconds)

---

Network Load Balancer (NLB) — Deep Dive

The NLB operates at Layer 4 and is designed for extreme performance.

Key Features

Feature	Detail
Performance	Millions of requests per second, ultra-low latency
Static IP	One static IP per AZ (or bring your own Elastic IP)
Preserve source IP	Client IP is visible to the target
TLS termination	Optional — can terminate TLS at the NLB
Long-lived connections	Ideal for TCP-based protocols
PrivateLink	Used to expose services via AWS PrivateLink

When to Choose NLB over ALB

• You need static IPs for firewall whitelisting
• Your protocol is not HTTP (e.g., raw TCP, UDP, MQTT, gaming)
• You need extreme performance and the lowest possible latency
• You are building an AWS PrivateLink service

---

Load Balancer Placement in a VPC