beginnerintermediateadvanced

AWS · Load Balancing

Load Balancing

From an internet-facing listener to a healthy, stateless, privately-placed target

ALB = Layer 7, NLB = Layer 4HTTP-aware routing vs raw throughput and static IPs
Listener → rules → target groupeach target group tracks its own health independently
Statelessness makes scaling freeany target can serve any request
LB public, app privatetwo independent layers, not one

1.Application Load Balancer vs Network Load Balancer

An ALB understands HTTP — it can route by URL path or hostname. An NLB operates purely at the connection level, handling extreme throughput and static IPs but with no visibility into the HTTP request at all.

Key features

ALB operates at Layer 7 (application/HTTP) — can route by path, host, headers
NLB operates at Layer 4 (transport/TCP-UDP) — extremely high throughput, low latency
NLB supports static IP addresses and Elastic IPs per AZ; ALB does not
ALB is the default choice for HTTP/HTTPS web applications and microservices
NLB fits extreme performance needs, non-HTTP protocols, or when a fixed IP is required

When each load balancer type fits

When each load balancer type fits
Need	Choice
Path/host-based routing for a web app	ALB
Millions of requests/sec, ultra-low latency	NLB
A fixed IP address for allowlisting	NLB (supports static/Elastic IPs)
Non-HTTP TCP/UDP protocols	NLB
User authentication at the load balancer	ALB (integrates with Cognito/OIDC)

ALB (Layer 7) vs NLB (Layer 4)

ALB

Reads the HTTP request — path, host, headers
Routes by URL structure
Integrates with Cognito/OIDC auth

NLB

Forwards by IP/port alone — no HTTP visibility
Extreme throughput, ultra-low latency
Supports static/Elastic IPs

Command

text

ALB: Layer 7 (HTTP) — path/host routing, content-aware
NLB: Layer 4 (TCP/UDP) — extreme throughput, static IP, protocol-agnostic

ALB is Layer 7 (HTTP-aware, path/host routing) — the default for web apps. NLB is Layer 4 (TCP/UDP, no HTTP visibility) — for extreme throughput, static IPs, or non-HTTP protocols.

2.Listeners, rules, and target groups

A listener checks incoming connections on a port; its rules decide which target group handles each one; a target group is the actual pool of instances/IPs/Lambdas the traffic goes to, each with its own health check.

Key features

A listener checks for connections on a specific protocol and port
A listener needs a default rule and can have additional priority-ordered rules
A target group specifies protocol, port, and health check settings for its own targets
TLS termination at the ALB means the ALB decrypts, forwarding plain HTTP to targets by default
Sticky sessions bind a client to the same target for the session's duration, via a cookie

The pieces and what each one is responsible for

The pieces and what each one is responsible for
Piece	Responsible for
Listener	Checking for connections on a protocol/port
Listener rule	Deciding which target group handles a given request
Target group	The pool of targets and their own health check settings
Health check	Per target group — determines which targets receive traffic
Sticky sessions	Cookie-based binding of a client to one target

From an incoming request to a healthy target

requestfirstmatching ruleonly healthytargets

Listener :443

TLS termination happens here

Listener rules

path/host match, priority order

Target group

own health check settings

Healthy target

Command

text

Listener (port 443, TLS) → Rules (priority order) → Target group → Targets (health-checked)

A listener catches connections, its rules pick a target group, and each target group tracks its own targets' health independently — TLS termination at the ALB means the ALB-to-target hop is plain HTTP by default.

3.Why statelessness makes scaling behind a load balancer easy

If any target can correctly answer any request — because nothing needed for that request lives only in one target's memory — then adding, removing, or replacing targets never breaks anything mid-flight. That is what "stateless" buys you.

Key features

Stateless: any target can serve any request correctly, with no per-target memory required
Session data, if needed, lives in a shared store (ElastiCache, DynamoDB) reachable by every target
A stateless app scales horizontally by simply adding targets — no data to migrate or synchronize
A stateless app tolerates target replacement (Auto Scaling, deployments) with zero client-visible impact
Statelessness is what makes a load balancer's routing algorithm (round robin, least outstanding requests) safe to use freely

Command

text

Stateless: any target serves any request  →  add/remove targets freely
Stateful (local memory): request must return to the SAME target  →  scaling breaks things

A stateless application has no data that lives in only one target's memory — that single property is what makes Auto Scaling, rolling deployments, and load balancer routing all safe without special-casing.

4.Cross-zone balancing and health-check failures

With cross-zone load balancing on, every load balancer node distributes evenly across ALL targets in ALL enabled AZs, not just the targets in its own AZ — without it, an AZ with fewer targets gets disproportionately less traffic per target.

Key features

ALB: cross-zone load balancing is always on, cannot be disabled
NLB: cross-zone load balancing is off by default, can be enabled per load balancer
Without it, each AZ's targets only receive traffic from that AZ's load balancer nodes
An unevenly distributed target count across AZs makes this imbalance worse without cross-zone balancing
A target failing its health check is removed from rotation until it passes again

Without cross-zone: uneven targets, uneven load per target

AZ-a — 1 target

gets 100% of AZ-a traffic alone

runs hot

AZ-b — 4 targets

splits AZ-b traffic 4 ways

each target runs light

Command

text

Without cross-zone: AZ-a node → only AZ-a targets
With cross-zone:    AZ-a node → targets in ANY enabled AZ

ALB always cross-zone balances; NLB defaults to off — check target counts per AZ, and make sure health-check timing matches real application startup, not an assumed instant-ready state.

5.Designing internet → load balancer → private targets

The standard web architecture: the load balancer sits in public subnets (reachable from the internet), while the actual application instances sit in private subnets, reachable only from the load balancer's security group — never directly from the internet.

Key features

Load balancer: public subnets, internet-facing, has a route to an internet gateway
Application targets: private subnets, no direct internet route
Target security group: only allows inbound traffic from the load balancer's security group
This design means even a leaked application IP is not directly reachable from outside
Outbound-only needs from the app (calling an external API) still go through a NAT gateway

The standard public-to-private web architecture

0.0.0.0/0: 443sg source =ALB's sg only

Internet

Load balancer

public subnet

App targets

private subnet

Command

text

Internet → ALB (public subnet, sg: 0.0.0.0/0:443)
         → App targets (private subnet, sg: source = ALB's security group only)

Load balancer in public subnets, application in private subnets, target security group scoped to the load balancer's security group as its only source — this layering holds even if any one piece is later misconfigured.

Spotted a mistake on this page? Tell us.

Read Sheet