High Availability
Intermediate 15 min read High Availability

Multi-AZ Architecture

The basic unit of regional resilience

Inside one region, spread compute and data across ≥2 AZs (each a real independent facility: power, network, HVACC). LB + stateless fleet + AZ-redundant data is the canonical pattern; multi-AZ DBs and instance seeding/ASG round out the design.

AZmulti-AZRDSASGALBzoneredundancy
Prerequisites: HA Fundamentals Availability Zones
Before we start

What you will learn

  • Design the LB × ASG × multi-AZ compute stack
  • Configure multi-AZ managed DBs (RDS / Azure SQL / Cloud SQL)
  • Verify failover paths and failure blast radius
In 60 seconds

AZ = isolated data center(s) cluster with independent power/net/HVAC. Pattern: ALB/LB spanning 3 AZs, target groups co-located, ASG replicates across them, DB in multi-AZ (sync standby, auto-failover). Lose any one AZ → fleet shrinks to remaining AZs only—brief LB drain, then recovery.

Introduction

What is this?

AZ overview per provider: AWS (us-east-1 has 6 AZs), Azure availability zones (>=3, in paired regions), GCP zones grouped under regions. Mechanics: instances+disks are zone-affiliated; attach multi-AZ traffic via ALB cross-zone, autoscaling across zones via ASG (spread), DB multi-AZ (RDS writes sync to standby in another AZ, DNS/failover flips in ~1min; Azure SQL HA uses AlwaysOn AG replicas; Cloud SQL high-availability has sync replication + automatic failover). Storage: EBS volumes per-instance (sync from app replication instead), object storage (S3/GCS/AzBlob) already 3+ AZ. Queues: SQS/AzQueue (zone-redundant by default), Kafka requires brokers ≥2 AZ + quorum. Stateful caches: ElastiCache multi-AZ + replication group; Redis replicas cross-AZ. app seeding: base images/ECS/eks node groups per AZ.

Motivation

Why do you need it?

  • One AZ failure is a theoretical certainty you can engineer around cheaply.
  • Data tier is the crown jewel — multi-AZ DBs auto-fail over those worst 1-minute gaps.
  • Comparing 'I'm HA' vs 'I'm protected if an AZ dies' is the reframe that saves the weekend.
  • ASG instance churn keeps fleet count steady, whatever AZs are healthy.
Think about it

Mental model

Imagine

A data center building with power + cooling on one floor vs. an office with two fully separated floors

Think of

AZs

Power loss in one floor (AZ) doesn't touch the other; traffic shifts over. You pay for the floor you don't use — redundancy is insurance with good odds.

Mechanics

How it works

  • Compute released: >2 replicas spread via ASG availability-zone distribution.
  • ALB routes traffic to healthy targets across zones with cross-zone distribut.
  • DB runs primary in AZ-A + sync standby in AZ-B; query failover flips on health loss.
  • Health outage in AZ-A → ALB drains + ASG launches elsewhere; DB fails over in seconds.
  • Time to serve: minutes if the fleet was seeded; the data never loses its recent commits.

Multi-AZ web + data stack.

Client / Domain
ALB
Web fleet
RDS Multi-AZ
Queue / cache
Hands-on

Examples

Multi-AZ RDS failover story

Multi-AZ RDS failover story
CREATE DATABASE NOT_REQUIRED;
-- RDS Multi-AZ in AWS: sync stand-by across AZ.
-- Failover: DNS flips in ~60s, no manual DB change.
-- Azure SQL: AG replicas, auto-failover in seconds.
-- Cloud SQL: sync replication + automatic failover, IP stable.

The failover is a managed behavior — but test it quarterly so the DNS flip and app reconnects are actually exercised.

Real world

In production

  • EKS: node groups spanning AZs + HPA; stateless pods with readiness probes.
  • Web tier behind ALB; static assets from S3 (already 3-AZ).
  • Redis cluster replicas across AZs for the session layer.
Guidelines

Best practices

  • Spread >2 AZs so losing one leaves a working minority (3 is the classic minimum).
  • Use provider-managed multi-AZ for the DB; hand-rolled replication is a second job.
  • Seed instance images so failover launches don't bake slowly; keep warm ASGs where latency hurts.
  • Make each AZ's failure testable: quarterly AZ-drain drills, chaos-ish but scheduled.
  • Confirm the LB's health can tolerate my-Zone-Down gracefully (no crash-loop switch-a-roos).
Watch out

Common mistakes

  • Instances across AZs but a single-AZ database the whole fleet depends on.
  • False certainty: 'we have 2 AZs' but both replicas of one service sit in the same zone.
  • Cross-zone dollar surprise on ALB/NLB data transfer bills.
  • Failover fan: app code with hard-coded IPs / no reconnect → DB fails over but app stays wedged.
When things break

Debugging tips

  • Traffic all over one AZ — check ASG mixed-zone max/marketing zone defaults.
  • DB failover happened but app errored — look at the SDK retry/reconnect settings and read-from-standby.
  • AZ-down drills produce long cutover — warm up DNS TTLs + seed ASGs.
  • Replicas in same AZ despite config — enumerate your scaling group's availability-zone list.
Interviews

Interview checkpoint

Practice

Hands-on lab

Deliver an AZ-Failover Drill for a Web Tier
35 min · intermediate
In progress
Objectives
  • Model an AZ-redundant web tier with 2 healthy zones
  • Simulate an AZ outage and observe drain+relaunch
  • Verify DB tier failover path (managed) is reachable

Deliver an AZ-Failover Drill for a Web Tier

35 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The core multi-AZ data trick is:

2

Most multi-AZ outages end up caused by:

Go deeper

Official documentation

AWS Availability Zones
docs
AWS RDS Multi-AZ
docs
Azure SQL HA
docs