AWS Elastic Load Balancing — what it is and how it works

What is Elastic Load Balancing?

Elastic Load Balancing (ELB) is a managed Amazon Web Services service that accepts incoming traffic from clients and distributes it across registered targets — EC2 instances, containers, Lambda functions and IP addresses — in one or more Availability Zones.

According to AWS documentation, the service monitors target health and routes traffic only to the healthy ones, scaling its own capacity automatically as traffic changes.

It's important to be clear about what ELB is not: it is not an application server and does not run your business logic. It is a managed traffic-distribution layer placed between clients and the resources that actually serve the application.

A client connects to a single entry point. How many machines sit behind it, and which of them are currently alive, stays invisible to the client.

ELB is also the name of a whole family of services, not a single product — more on that shortly. The original load balancer (today the Classic Load Balancer) shipped in 2009, with specialised types added over time. The history is secondary here — what matters is choosing the right type for the job.

Why do we need a load balancer?

A single server has two fundamental weaknesses: finite capacity and being a single point of failure. When it goes down, the whole application goes down.

A load balancer solves both at once — it spreads load across many resources and, thanks to health checks, automatically bypasses those that stop responding.

In AWS architecture, the load balancer is usually the gateway between the public internet and your fleet of servers. It lets you keep machines in private subnets, add and remove them without disrupting the flow of requests, and take on the expensive work of TLS termination^?TLS termination: decrypting HTTPS traffic at the load balancer so application servers receive already-decrypted HTTP and never handle cryptography. It is the invisible layer that decides whether a service works at all under load.

The ELB family: ALB, NLB, GWLB and Classic

This is the single most important distinction in the whole topic: Elastic Load Balancing is the name of the service/family, within which you have four load balancer types, differing mainly in the OSI layer they operate at. Per the AWS feature comparison:

The difference between ALB and NLB is not a nuance — it's a different operating model.

ALB understands the content of an HTTP request and selects a target using round robin^?round robin: distributes requests to available targets in turn, evenly (default) or least outstanding requests^?least outstanding requests: sends each new request to the target with the fewest in-flight requests.

NLB works at Layer 4: for each connection it selects a target with a flow hash^?flow hash: picks a target from fixed connection attributes, so an entire connection always lands on the same target algorithm (based on protocol, source and destination IP and port, and TCP sequence number) and keeps that connection on a single target for its entire lifetime.

GWLB doesn't terminate traffic — it passes it through to third-party security appliances using GENEVE^?GENEVE: a tunneling protocol that wraps packets for security appliances without modifying them encapsulation on port 6081.

Because ALB is the most common choice for HTTP/HTTPS applications, the following example uses ALB to explain listeners, rules and target groups.

How ALB works: from listener to target

This is the key mental model for ALB. Traffic passes through a chain of elements:

A listener watches for connections on a chosen protocol and port. To a listener you attach rules, each with a priority, a condition and an action; every listener must have a default rule.

A target group routes requests to registered targets, and it is at the target-group level that health checks are configured. When a request arrives, the ALB evaluates the rules in priority order and picks a target from the relevant group.

ALB routing: host, path, header, query

Content-based routing is exactly what makes ALB a Layer 7 service and a natural microservices front-end. A single load balancer can route different paths to different groups:

Rules match requests by:

• URL path
• Host header (many domains behind one balancer)
• HTTP headers
• method
• query parameters
• source IP address

ALB can additionally:

• redirect traffic
• return fixed responses
• authenticate users
• integrate with AWS WAF

Health checks — ELB detects, it doesn't repair

A health check is a periodic probe at the target-group level, verifying that a target responds correctly. Per the docs: when the load balancer detects an unhealthy target, it stops routing traffic to it, and resumes only once the target becomes healthy again.

This mechanism separates a load balancer from a naive traffic splitter — routing decisions are continuously corrected against the real state of the machines.

The crucial distinction: ELB repairs nothing. It detects a problem and bypasses the target, but it is the Auto Scaling Group^?Auto Scaling Group: an AWS service that maintains a desired number of EC2 instances — adding and removing machines on its own that can replace a broken instance.

Availability Zones and cross-zone load balancing

When you enable an Availability Zone, ELB creates a load balancer node in it. High availability comes from spanning multiple zones — but the requirements differ per type. An ALB requires at least two Availability Zones. An NLB can even run in a single zone, though multiple zones are recommended for fault tolerance.

Cross-zone load balancing decides whether a node in one zone may route traffic to targets in other zones. Without it, a node serves only the targets in its own zone — which, with unequal machine counts, leads to uneven traffic distribution.

Internet-facing vs internal

When creating a load balancer you choose one of two schemes:

• Internet-facing — nodes have public IP addresses and accept traffic from the internet; the DNS name resolves to public addresses.
• Internal — has only private addresses and serves only clients with access to the VPC^?VPC: Virtual Private Cloud — a user's isolated, private virtual network in AWS.

An important detail: both schemes route traffic to targets using private IP addresses, so your servers don't need public IPs. A typical multi-tier architecture combines the two: an internet-facing ALB with web servers at the front, and behind them an internal ALB with application servers.

Security Groups — the backend need not be public

A security group acts as the load balancer's firewall. The canonical, secure pattern looks like this:

TLS termination

For an HTTPS listener, the load balancer terminates encryption using a certificate from AWS Certificate Manager. Decryption happens at the edge, offloading the application servers.

One consequence to remember: an ALB acts as a proxy, so the application doesn't see the client's address directly — the source IP is read from the X-Forwarded-For^?X-Forwarded-For: an HTTP header in which a proxy records the client's original IP address header, which the ALB adds automatically.

ELB + Auto Scaling

This is one of the most important pairings in AWS. Together, the load balancer and an Auto Scaling Group give you a self-healing, elastic fleet:

ELB handles traffic distribution and failure detection; the ASG maintains the right number of instances. New instances are automatically registered with the target group, and removed ones are deregistered, allowing time for in-flight connections to finish.

ELB + API Gateway

Amazon API Gateway is a managed API gateway, not a load balancer — and that's the crux of the difference. It operates a layer above ELB: it authenticates requests, throttles their rate, validates input, and handles API keys and versioning. ELB spreads traffic across a fleet of machines; API Gateway manages the API itself. In practice, the two often sit together.

When the backend runs in a private VPC — with no public IP address — API Gateway can't reach it directly over the internet. A VPC link bridges the gap: API Gateway provisions elastic network interfaces^?elastic network interfaces: ENIs — virtual network cards in the VPC that let resources talk to the rest of the network inside your VPC and manages them itself, creating a private path from the gateway into the network so traffic never leaves AWS. The integration itself is an HTTP proxy: it points at the load balancer's listener ARN (ALB or NLB) and forwards requests unchanged. Traffic flows over HTTP by default — HTTPS requires configuring TLS on the listener.

Which load balancer the VPC link connects to depends on the API type:

Which load balancer you can put in front of the API depends on the VPC link version. The older one was narrow — a REST API could only sit behind an NLB. The newer version (V2) supports both ALB and NLB (and, for HTTP APIs, services registered in AWS Cloud Map), so today the load balancer type rarely constrains your architecture.

You don't have to choose one over the other. API Gateway gives you control over the API itself — limits, authorization, keys — while ELB gives you scalable traffic distribution across a fleet. Together they form a common pattern: a public API with a private, scalable backend.

DNS and IP addressing

Does a load balancer have an IP address? Not a fixed one — it gets a DNS name like my-lb-1234567890.elb.eu-central-1.amazonaws.com. The client resolves this name, and AWS may update the underlying IP addresses as the balancer scales.

Hence a practical rule: reference an ALB by its DNS name, because its IP addresses can change. NLB is different — it creates one network interface per zone and provides one static IP address per zone, and for the internet-facing^?internet-facing: a load balancer with public IP addresses, reachable from the internet (as opposed to internal, reachable only inside the VPC) variant you can attach your own Elastic IP^?Elastic IP: a static public AWS IP address that can be permanently assigned to a resource.

Sticky sessions and deregistration delay

Sticky sessions make successive requests from the same client go to the same target. In ALB this is done via a load-balancer-generated cookie (or an application cookie) — useful for apps that hold session state locally, though stateless servers are the better pattern.

Deregistration delay (also called connection draining) is the time the load balancer gives in-flight connections to finish before a deregistered target is detached. This ensures that shutting instances down during scale-in doesn’t sever requests currently being served.

When to choose ALB, NLB or GWLB

Rule of thumb^?Rule of thumb: a practical, simplified guideline based on experience — not a strict rule; gives a good choice in most cases but allows exceptions. — match the type to the job:

• ALB — HTTP/HTTPS applications and content-based routing (path, host, headers).
• NLB — extreme throughput, low latency, TCP/UDP protocols or static IP addresses.
• GWLB — inserting third-party security appliances into the traffic path (firewalls, IDS/IPS).

With NLB, think in terms of very high-performance, low-latency connections and flows rather than HTTP requests alone — the “millions of requests per second” line can be misleading.

Common SAA scenarios

Key things to remember

ELB is a traffic-distribution layer, not an application server — it sits at the boundary of the internet and your fleet and is the first thing to absorb every traffic spike and every single-machine failure.

Three things are worth cementing above the rest:

• ELB is a family (ALB/NLB/GWLB/CLB), and choosing the type is one of the first and hardest-to-reverse architectural decisions.
• Cross-zone behaviour and the minimum number of zones differ between ALB and NLB.
• ELB only detects failures and bypasses targets, while replacing instances is the job of Auto Scaling.

The same pattern — stateless servers behind a load balancer, health checks as the source of truth about fleet condition, Auto Scaling reacting to metrics, TLS terminated at the edge — recurs in Google Cloud, Azure and Kubernetes. Mastering it on AWS therefore transfers almost directly to other platforms. This isn't a flashy technology but a foundational one: the difference is often that between the wiring and the chandelier.

Sources

• AWS — How Elastic Load Balancing works (documentation) — link
• AWS — Elastic Load Balancing features — link
• AWS — What is an Application Load Balancer? (documentation) — link
• AWS — Network Load Balancers (documentation) — link
• AWS — Application Load Balancers (documentation) — link
• AWS — Elastic Load Balancing pricing — link
• AWS — API Gateway: private integrations for HTTP APIs (documentation) — link
• AWS — API Gateway: set up VPC links V2 (documentation) — link