Skip to main content
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 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.
A slide titled "Why Do We Need Load Balancer?" showing an AWS architecture diagram with three t2.large EC2 instances (with IPs) behind a load balancer that forwards traffic to a website (www.mywebsite.com) and users via an ELB endpoint.
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.
A diagram showing how an AWS load balancer routes HTTPS (port 443) traffic from a user to target groups/EC2 instances across multiple public subnets. The user visits https://www.mywebsite.com which is forwarded through the load balancer to backend servers.

​
Target group resources and supported protocols

Target groups support multiple target types and protocols: 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.
A slide titled "Target Group Characteristics" showing target types (Instances, IP Address, Lambda, Application Load Balancer) and icons, alongside boxes listing supported protocols, port range and protocol versions. A separate green box notes health checks use HTTP and HTTPS.

​
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.
An AWS architecture diagram titled "Load Balancer Health Check" showing a load balancer receiving client requests and routing to EC2 instances across multiple public subnets. Some instances are marked unhealthy with heartbeat lines and red Xs indicating failed health checks.

​
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.
A diagram titled "Public and Private Load Balancer" showing an AWS cloud architecture with public and private subnets connected to public and private load balancers. Traffic flows from users to a website (www.mywebsite.com) through the public LB into the subnets.

​
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.
A network diagram illustrating AWS cross-zone load balancing: multiple public subnets with instances send/receive traffic via a central load balancer, with dotted arrows showing distribution across availability zones. On the right a user and Route 53 are shown, and the diagram indicates Cross-Zone Load Balancing is On.

​
AWS load balancer types

AWS provides several load balancer types for different use cases. The two primary ones are:
A slide titled "Types of LB Supported by AWS" showing the OSI layers and two highlighted options: Application Load Balancer (ALB) at Layer 7 and Network Load Balancer (NLB) at Layer 4. The slide notes ALB supports HTTP/HTTPS and advanced routing, while NLB supports TCP/UDP/TLS, millions of requests per second, and static IPs per AZ.

​
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.
A diagram titled "Feature of ALB" showing an AWS Cloud box with a Listener (port 80) and rule blocks for Host Header, Path, HTTP Request Method, Source IP, HTTP Header, and Query String. Icons on the right depict actions such as Forward, Redirect, and Fixed Response.

​
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.
A diagram of an AWS Application Load Balancer listener (port 80) using host header rules. Requests for blog.mywebsite.com are routed to the "Blog" target group, while other traffic is forwarded to the default target group.

​
Path-based routing

Match on URL paths to forward traffic to different backends.
A diagram of an AWS Application Load Balancer showing a listener on port 80 with a path rule for "/blog" forwarded to a Blog target group and a default rule forwarded to a Default target group. It maps requests from mywebsite.com/blog and mywebsite.com to their respective target groups.

​
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:

​
Source IP, header, and query-string routing

Match client IP ranges (CIDR) to route corporate traffic differently from public traffic:
A diagram of an AWS Application Load Balancer showing a listener on port 80 with a source-IP rule that matches 202.166.140.80/32 and forwards that traffic to an "Office" target group. The default rule forwards all other traffic (0.0.0.0/0) to the Default target group.
Header-based example:
Query-string example:

​
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:

​
Integrations and ecosystem

Elastic Load Balancing integrates with many AWS services:
  • EC2 & Auto Scaling — instances register/deregister automatically as group scales.
  • Amazon ECS — ALB/NLB route to container tasks.
  • AWS Lambda — ALB can invoke Lambda functions as targets.
  • AWS WAF — attach a Web Application Firewall to protect apps from common exploits.
  • Amazon Route 53 — use DNS to point custom domains to the load balancer endpoint.
  • AWS CloudWatch & 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.

Watch Video

Practice Lab