Load Balancing and Multi AZ Design

What it is

A highly available design keeps working when a component fails. In AWS the first building block is the Availability Zone (AZ): one or more data centers in a Region with separate power and networking. Placing resources in at least two AZs means one failure does not stop the service.

Elastic Load Balancing (ELB) spreads incoming traffic across targets in several AZs and stops sending traffic to targets that fail health checks.

How it works

Choosing a load balancer

An ALB can route by URL path, host name, header or query string, and can authenticate users. An NLB can have an Elastic IP address in each AZ, which helps when clients must allow list fixed addresses. Targets can be instances, IP addresses and, for an ALB, Lambda functions.

Health checks and draining

Each target group defines a health check, with a protocol, path, interval and thresholds for healthy and unhealthy. A target is used only while it passes.

Deregistration delay lets in flight requests finish before a target is removed. Sticky sessions send a client to the same target, but they weaken even spreading, so store session data outside the instance when you can.

Cross zone load balancing

With cross zone load balancing, each load balancer node sends traffic to targets in all enabled AZs. Without it, each node sends only to targets in its own zone, so uneven target counts give uneven load. For an ALB it is always on at the load balancer level, and for an NLB it is off by default and can be turned on.

Subnets and placement

Create at least one subnet per AZ and enable those subnets on the load balancer. Put the load balancer in public subnets if it faces the internet, or in private subnets for an internal one. Targets usually sit in private subnets.

# AWS CLI: register a health check path on a target group
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:111122223333:targetgroup/web/abc123 \
  --health-check-path /health

Design patterns for AZ failure

• Run Auto Scaling groups in two or more AZs, with enough spare capacity that the remaining zones can carry the load.
• Use Multi AZ for databases, covered on the next page.
• Use EFS or S3 for shared data, since both store data across AZs (except the One Zone classes).
• Keep session and state outside the instances.
• Use one NAT gateway per AZ, so private subnets keep their internet path if a zone fails.

Securing the pair

Allow the load balancer's security group as the source in the target security group, so only the load balancer can reach the instances. TLS certificates for HTTPS listeners come from AWS Certificate Manager (ACM), and the load balancer can end TLS on behalf of the targets.