> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Elastic Load Balancing
> Overview of AWS Elastic Load Balancing covering ALB and NLB features, listeners, target groups, routing rules, health checks, cross zone balancing, and integrations for scalable high availability
In this lesson we'll cover Elastic Load Balancers (ELB) and why they are essential for scaling, availability, and protecting web applications on AWS. You'll learn core ELB concepts, differences between load balancer types, routing options provided by Application Load Balancers (ALBs), and how Network Load Balancers (NLBs) operate at high scale.
## Why use a load balancer?
Consider a website hosted on a single [EC2](https://learn.kodekloud.com/user/courses/amazon-elastic-compute-cloud-ec2) instance. Initially this may be fine, but as traffic grows a single server becomes a bottleneck. Two common scaling approaches:
* Vertical scaling — increase the instance size (CPU, RAM).
* Horizontal scaling — add more instances and distribute traffic across them.
Horizontal scaling requires a single entry point that can route requests across multiple backend instances. If the domain points to one EC2 IP, adding more instances won't help because traffic still targets that one IP. A load balancer becomes that single entry point and distributes requests according to configurable rules.
Clients interact only with the load balancer; the load balancer forwards requests to backend targets (EC2, IPs, Lambda, or containers) based on the configured listeners and target groups.
## Core ELB concepts: Listeners and Target Groups
Two primary configuration elements used by AWS load balancers:
* Listener — a process on the load balancer that checks for connection requests on a specific protocol and port. ALB and NLB listeners can include rules that define how matching traffic is routed and what actions to take.
* Target group — a logical grouping of endpoints (EC2 instances, IP addresses, Lambda functions, or other load balancers) that receive traffic forwarded by the load balancer. Each target group has health check settings and a protocol/port configuration.
For example, create an HTTP (port 80) listener and forward incoming requests to a target group of EC2 instances listening on port 80. A separate HTTPS (port 443) listener can forward to a different target group.
## Target group resources and supported protocols
Target groups support multiple target types and protocols:
| Target type | Use case |
| - | - |
| EC2 instances | Classic targets for VM-backed workloads |
| IP addresses | On-prem or cross-VPC targets reachable by IP |
| AWS Lambda functions | ALB integration for serverless handlers |
| Application Load Balancer | Chaining between load balancers or advanced architectures |
Supported protocols: TCP, UDP, TLS, HTTP, HTTPS. Target groups can forward to any port and support HTTP/1.1, HTTP/2, and gRPC. Health checks run periodically (HTTP/HTTPS or TCP) to determine target availability.
## Health checks
Load balancer nodes continuously perform health checks on registered targets using configured intervals and thresholds. When a target fails health checks it is removed from routing until it passes health checks again. Health checks apply to instance and IP targets; Lambda targets are invoked and monitored differently by the ALB integration.
## Public vs Private load balancers
* Public (internet-facing) load balancer — accessible from the internet; suitable for public web apps and APIs.
* Private (internal) load balancer — accessible only from within the VPC; suitable for internal services, microservices, and internal APIs.
Private load balancers provide an additional security boundary since they are not reachable from the internet.
## Cross-zone load balancing
When you create a load balancer you choose subnets in specific Availability Zones (AZs); AWS deploys load balancer nodes into those subnets. Cross-zone load balancing affects how nodes forward traffic across AZs:
* ALB — automatically distributes traffic evenly across all registered targets in enabled AZs (no explicit toggle required).
* NLB — cross-zone load balancing is optional. When enabled, nodes can forward traffic to targets in any AZ; when disabled, a node only forwards to targets in its own AZ (which can cause uneven utilization).
Example: Cross-zone load balancing ON distributes requests across all targets in every AZ, improving distribution and avoiding hotspots.
## AWS load balancer types
AWS provides several load balancer types for different use cases. The two primary ones are:
| Load balancer | OSI layer | Typical protocols | Best for |
| - | - | - | - |
| Application Load Balancer (ALB) | Layer 7 (Application) | HTTP, HTTPS (HTTP/1.1, HTTP/2, gRPC) | Web apps, microservices, host/path-based routing, advanced request-level routing |
| Network Load Balancer (NLB) | Layer 4 (Transport) | TCP, UDP, TLS | High throughput, ultra-low latency, static IPs, non-HTTP workloads |
### How Network Load Balancer (NLB) works
* AWS creates a network interface in each AZ where the NLB is enabled; each interface provides a static IP for that AZ.
* For internet-facing NLBs you can associate Elastic IPs per subnet.
* NLBs operate at Layer 4: listeners match on ports (e.g., 80, 443, 8080) and forward based on port and protocol rather than HTTP content.
* NLBs can forward to IP-based targets outside the VPC (e.g., on-premises data center).
Listeners on an NLB match ports and forward traffic to the appropriate target group (instances, IPs, or ALBs).
## Application Load Balancer (ALB) features and routing rules
ALBs are HTTP-aware and allow powerful request-level routing. ALB rules can match on one or more of the following conditions:
* Host header (domain)
* URL path
* HTTP request method (GET, POST, PATCH, DELETE, etc.)
* Source IP (CIDR ranges)
* Specific HTTP headers
* Query string parameters
Rules are evaluated in priority order; the first match wins. If no rule matches, the default rule forwards to the default target group.
### Host header routing
Route traffic for different hostnames to different target groups. Example: `blog.mywebsite.com` -> Blog target group; all other traffic -> Default target group.
### Path-based routing
Match on URL paths to forward traffic to different backends.
### Method-based routing
Route based on HTTP methods. For example, POST might go to a write-optimized target group while GET goes to a read-optimized group.
Example curl commands to test method- and header-based routing:
```bash theme={null}
# POST with JSON body and content-type (matches a rule for POST)
curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' https://mywebsite.com/api
# Header-based routing examples
curl -H "x-environment: staging" https://mywebsite.com/api
curl -H "x-client: premium" https://mywebsite.com/api
curl -H "x-client: medium" https://mywebsite.com/api
# Default (no special headers or method)
curl https://mywebsite.com/api
```
### Source IP, header, and query-string routing
Match client IP ranges (CIDR) to route corporate traffic differently from public traffic:
Header-based example:
```bash theme={null}
curl -H "x-environment: staging" https://mywebsite.com/api
```
Query-string example:
```bash theme={null}
curl "https://mywebsite.com/api?category=books"
```
### Mixing conditions
Combine host, path, header, method, source IP, and query string conditions to build precise routing logic. Rules are processed by priority; the first matching rule applies. If no rule matches, the default target group handles the request.
Example: route by `X-Client` header to different instance types:
```bash theme={null}
# Premium clients
curl -H "x-client: premium" https://mywebsite.com/api
# Medium clients
curl -H "x-client: medium" https://mywebsite.com/api
# Default
curl https://mywebsite.com/api
```
## Integrations and ecosystem
Elastic Load Balancing integrates with many AWS services:
* [EC2](https://learn.kodekloud.com/user/courses/amazon-elastic-compute-cloud-ec2) & Auto Scaling — instances register/deregister automatically as group scales.
* [Amazon ECS](https://learn.kodekloud.com/user/courses/amazon-elastic-container-service-aws-ecs) — ALB/NLB route to container tasks.
* [AWS Lambda](https://learn.kodekloud.com/user/courses/aws-lambda) — ALB can invoke Lambda functions as targets.
* [AWS WAF](https://aws.amazon.com/waf/) — attach a Web Application Firewall to protect apps from common exploits.
* [Amazon Route 53](https://aws.amazon.com/route53/) — use DNS to point custom domains to the load balancer endpoint.
* [AWS CloudWatch](https://learn.kodekloud.com/user/courses/aws-cloudwatch) & [CloudTrail](https://aws.amazon.com/cloudtrail/) — monitoring and logging for metrics and audit trails.
Auto Scaling groups typically register instances with a load balancer so new instances immediately receive traffic and terminated instances are deregistered automatically.
Plan listener rules and target groups to map traffic patterns (host, path, headers, methods) to the correct backends. Use health checks to ensure only healthy targets receive traffic and leverage ALB rules to keep routing logic efficient and maintainable.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.