Skip to main content
In this lesson we’ll cover AWS Elastic Load Balancing (ELB) — why you need load balancers, how AWS implements them, and which type to choose for common architectures. Imagine a web application running on a single Amazon EC2 instance with public IP 1.1.1.1. If that instance fails, the application becomes unavailable. To add redundancy you deploy the app across multiple EC2 instances in different Availability Zones (AZs). Each instance has its own IP (for example 3.3.3.3, 1.1.1.1, 2.2.2.2), so exposing or asking users to choose among multiple IPs is a poor design. Instead, you place a load balancer in front of the instances. The load balancer provides a single IP/DNS name for clients and distributes requests to the backend instances.
A diagram of an AWS Elastic Load Balancer receiving a client's request and asking "Which IP do I send it to?". The load balancer (5.5.5.5) forwards traffic to three EC2 instances in different availability zones with IPs 3.3.3.3, 1.1.1.1, and 2.2.2.2.
AWS Elastic Load Balancing is a managed service and provides three load balancer types. The table below shows when to use each: Classic Load Balancer was the original offering but lacks features of newer load balancers and is generally not recommended for new deployments.
A presentation slide titled "Classic Load Balancer (CLB)" noting it was the first AWS load balancer but is not recommended to use. A simple diagram shows the CLB distributing traffic to two apps (App 1 and App 2).
Classic Load Balancer (CLB) is considered legacy. For new applications use ALB or NLB depending on protocol and requirements.

​
Application Load Balancer (ALB)

Application Load Balancer (ALB) operates at the application layer (Layer 7). It is optimized for HTTP/HTTPS and WebSocket traffic and can route requests using content from the HTTP request:
  • Host-based routing (virtual hosts, e.g., app1.example.com)
  • Path-based routing (e.g., /auth, /cart)
  • Header, query string and method-based rules
  • HTTP redirects and custom responses
  • Application-specific health checks
ALB typically terminates TLS (HTTPS) at the load balancer — the ALB holds the SSL certificate and decrypts inbound traffic. From ALB to backend targets you can use either HTTP (unencrypted) or HTTPS (encrypted). For true end-to-end encryption, enable HTTPS between the ALB and your targets and manage certificates on those targets.
A simple network diagram showing an Application Load Balancer (ALB) that terminates SSL/TLS connections from a user and holds the SSL certificates. The ALB then forwards traffic to backend compute instances, with an indication the connection to the backend can be unencrypted.
If you need ALB to forward encrypted traffic to backends, configure the backend targets with HTTPS and provide certificates on the targets. By default, ALB decrypts inbound HTTPS.

​
Network Load Balancer (NLB)

Network Load Balancer (NLB) works at Layer 4 (transport) and forwards TCP/UDP connections without interpreting HTTP. Use NLB when you need:
  • Support for non-HTTP/HTTPS protocols or TCP/UDP-based applications
  • Ultra-low latency and very high throughput
  • Large numbers of concurrent connections
  • Static IPs (you can assign Elastic IPs per AZ)
NLB preserves client TCP/TLS sessions by default (pass-through), so backends handle TLS termination unless you configure TLS listeners on the NLB to offload TLS at the load balancer. Health checks for NLB are typically at the transport level (TCP/UDP).
A presentation slide titled "Network Load Balancer (NLB)" that lists key points about NLBs. It notes NLBs load-balance TCP/UDP at layer 4, are for non-HTTP/HTTPS apps, are faster than application load balancers, use basic ICMP/TCP health checks, and forward TCP connections to instances.
When using an NLB, the client opens the TCP/UDP connection and the NLB forwards it to a target. Depending on configuration the NLB can either pass the transport session through to the target or terminate TLS if TLS listeners are configured.

​
How ELB is deployed inside a VPC

When you create a load balancer you select subnets (usually one per Availability Zone). AWS deploys load balancer nodes into those subnets. A DNS name is created for the load balancer; DNS queries are distributed across the load balancer nodes, and each node forwards traffic to registered targets in its AZ (or to other AZs if cross-zone load balancing is enabled).
A diagram titled "Elastic Load Balancers" showing a VPC split into two availability zones. Each zone has a public subnet with a load balancer node routing traffic to private subnets with application instances, and a DNS record is created for the ELB.

​
Cross-zone load balancing

By default each load balancer node forwards traffic only to targets in the same AZ. This can cause uneven distribution when AZs have unequal numbers of targets. For example, if AZ A has one instance and AZ B has two instances, and DNS splits client traffic 50/50 across AZs, the single instance in AZ A gets 50% of traffic while each instance in AZ B gets 25% each. Cross-zone load balancing lets nodes route traffic across AZ boundaries to distribute load evenly across all targets.
A diagram titled "Cross-Zone Load Balancing" showing a Virtual Private Cloud with two availability zones and load balancer nodes. It shows user traffic split 50/50 between AZ A and AZ B, with AZ A sending to one instance (50%) and AZ B splitting its share across two instances (25% each).

​
Public vs Private load balancers

Load balancers can be internet-facing (public) or internal (private):
  • Public (internet-facing) — deployed in public subnets and reachable from the internet; use for frontend web or API tiers.
  • Internal (private) — deployed in private subnets and reachable only from within the VPC or connected networks; use for internal services, databases, or microservices to avoid direct internet exposure.
A simple AWS diagram comparing private vs public subnets: the left side shows a private subnet inside an AWS cloud with a red X indicating it's not accessible from the internet, and the right side shows a public subnet with a check mark indicating internet accessibility.

​
Example architecture

A common and secure pattern is:
  1. Expose a public ALB for the web/API tier.
  2. Place API servers in private subnets behind the public ALB.
  3. Use an internal (private) load balancer or service mesh between API servers and backend databases/services.
This separation protects private subnets and backend services behind additional security boundaries.
A slide titled "ELB Architecture" showing a VPC diagram where load balancers in public subnets forward requests to API and backend resources in private subnets. It includes icons for a user, load balancers, and server instances.

​
Listeners and Target Groups

Two core ELB concepts to configure are listeners and target groups:
  • Listener: Monitors for connection requests on a specified protocol and port (for ALB: HTTP/HTTPS; for NLB: TCP/UDP). Listeners evaluate rules (host/path/header for ALB) and forward traffic accordingly.
  • Target Group: A logical group of targets (EC2 instances, IP addresses, AWS ECS services, or Lambda functions) that receive traffic from the load balancer. Each target group has its own health check configuration; unhealthy targets are automatically removed from rotation.
You define listener rules to map incoming traffic to specific target groups. Health checks run per target group so routing only occurs to healthy targets.
A diagram titled "Listeners and Target Groups" showing a load balancer listener routing requests for app1.com, app2.com/auth, and app2.com/cart to three target groups. The target groups contain icons for EC2/ECS and AWS Lambda, with a note that load balancers can forward requests to ECS and Lambda.

​
Summary

  • Elastic Load Balancers distribute incoming traffic across multiple targets and AZs, increasing availability and fault tolerance.
  • ELB can route to EC2 instances, IP addresses, ECS services, and Lambda functions.
  • Choose the right type:
    • Classic Load Balancer (legacy — avoid for new deployments)
    • Application Load Balancer (Layer 7 — HTTP/HTTPS/WebSockets; advanced routing and TLS termination)
    • Network Load Balancer (Layer 4 — TCP/UDP; high performance; supports static IPs and TLS offload)
  • ALB terminates HTTP/HTTPS by default; NLB forwards transport-layer connections by default but can also terminate TLS via TLS listeners.
  • Cross-zone load balancing evens traffic across all instances in all AZs.
  • Listeners accept client connections and forward to target groups; target groups contain registered targets and health checks.
A presentation slide titled "Summary" showing four numbered points about AWS Elastic Load Balancers. It notes ELBs auto-distribute traffic across Availability Zones, route to EC2 instances/IPs/Lambda functions, come in three types (Classic, Application, Network), and that CLBs are outdated.
A presentation slide titled "Summary" with a teal sidebar. It lists numbered points comparing ALB and NLB, noting ALB handles application-layer HTTP/HTTPS traffic while NLB can forward non-HTTP traffic and is faster.
A presentation slide titled "Summary" with a blue gradient panel on the left and three colorful numbered points on the right. The points briefly describe AWS load-balancing concepts: cross-zone load balancing, listeners, and target groups routing requests to EC2 instances.

Watch Video