Cloud Fundamentals
Advanced 17 min read Cloud Fundamentals

Multi-Region & High Availability

High availability means surviving hardware and facility failures. Learn availability zones, replication strategies, failover patterns, and how RTO and RPO define your recovery targets and drive architecture choices.

availability zonehigh availabilityfailoverreplicationRTORPOmulti-regiondisaster recovery
Prerequisites: Cloud Computing Fundamentals Virtual Networks: VPCs & Subnets
Introduction

What is this?

A region is a geographic cluster of facilities; availability zones (AZs) are isolated data centers inside it with independent power, cooling and networking. High availability spreads workloads across AZs so one facility failing does not take the app down. Multi-region architecture extends that across geography for disaster recovery, with RTO and RPO defining how fast you must recover and how much data you can lose.

Motivation

Why do you need it?

  • Single-AZ deployments guarantee downtime: every provider has had AZ incidents, and your SLA math should assume they happen.
  • RTO and RPO are the numbers every stakeholder asks about after an outage — they drive all architecture decisions.
  • Replication strategy (sync vs async) is a direct trade-off between data safety and request latency.
  • Failover is only as good as the DNS, load-balancer and health-check automation behind it.
  • Multi-region design is the difference between 'the cloud had an outage' and 'we stayed up'.
Think about it

Mental model

Imagine

A bank branch and a backup branch

Think of

High availability and disaster recovery

Two tellers in one branch handle a busy day (HA within a region), but if the branch floods you need the backup branch (DR in another region). RPO is how much money you accept losing if the vault burns — one day of deposits or one hour? RTO is how long customers wait before the backup branch opens.

Mechanics

How it works

  • Within a region you deploy identical copies of the workload into at least two AZs, each with its own subnets and resources.
  • A load balancer (or the orchestrator) spreads traffic across the AZs and health-checks every instance, removing failures automatically.
  • State is the hard part: databases replicate to a standby — synchronous within a region for zero data loss, asynchronous across regions for speed.
  • For cross-region failover, a DNS-level router with health checks shifts traffic from the primary region to the standby when the primary is unhealthy.
  • RTO and RPO quantify the plan: RTO is the maximum time to restore service, RPO is the maximum age of data you may lose.

Failover flow from a primary region to a standby region.

Clients
Primary region
Health check
Primary healthy
Primary unhealthy
Standby region
Reference

Key commands

ping -c 4 api.example.com

Check reachability and latency to the primary endpoint.

nslookup api.example.com

See which IP the DNS endpoint resolves to — the active region.

dig api.example.com A

Query the DNS record that routes traffic to the active region.

date -u

Correlate timestamps across regions — UTC keeps logs comparable.

cat /etc/resolv.conf

Inspect which DNS resolvers this host uses for failover lookups.

Hands-on

Examples

Deploy a workload across two availability zones in Terraform

Deploy a workload across two availability zones in Terraform
resource "aws_subnet" "a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = true
}
 
resource "aws_subnet" "b" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = "us-east-1b"
  map_public_ip_on_launch = true
}
 
resource "aws_autoscaling_group" "app" {
  min_size         = 2
  max_size         = 6
  desired_capacity = 2
  vpc_zone_identifier = [
    aws_subnet.a.id,
    aws_subnet.b.id,
  ]
  target_group_arns = [aws_lb_target_group.app.arn]
  tag {
    key                 = "Name"
    value               = "app-asg"
    propagate_at_launch = true
  }
}

The autoscaling group spans two subnets in two AZs, so capacity runs in at least two failure domains simultaneously. If an AZ fails, the remaining AZ keeps serving and the ASG replaces instances. The load balancer terminates clients and distributes across the surviving nodes.

Real world

In production

  • Two-AZ deployments satisfy most high-availability SLAs without the cost of a second region.
  • Active-passive DR keeps a warm standby region that you promote only when the primary fails.
  • Active-active setups serve traffic from multiple regions simultaneously for global latency and resilience.
  • Read replicas in other regions shorten latency for global users while the primary region owns writes.
Guidelines

Best practices

  • Decide RTO and RPO before building: they determine replication mode, backup cadence and failover automation.
  • Automate failover and run chaos drills — a playbook nobody has practiced will fail under pressure.
  • Keep a multi-AZ baseline everywhere, and reserve multi-region for workloads that truly need it.
  • Test failover by actually cutting traffic, not by trusting the config.
  • Replicate data synchronously within a region and asynchronously across regions, and document the RPO gap.
Watch out

Common mistakes

  • Treating 'two AZs' as resilience when both copies share one misconfigured subnet or dependency.
  • Forgetting that RPO means real data loss — async replication means the standby may lag the primary.
  • Designing multi-region for reads but ignoring that writes must be reconciled after a failback.
  • Never testing failover until the real incident, then discovering the runbook is stale.
Root cause analysis

Common issues

Error
Failover takes 20 minutes instead of seconds
Root cause

DNS TTL is long and cached at clients, or promotion is a manual runbook step.

Fix

Lower TTLs on failover records, automate promotion, and let health checks trigger DNS changes.

Error
Standby promoted but data is hours old
Root cause

Asynchronous replication lag exceeded the expected RPO.

Fix

Switch to synchronous replication or tighten the re-replication path; monitor lag as an alert.

Error
Traffic returns to a still-broken primary after failover
Root cause

DNS failback fired on a flapping health check or premature re-enable.

Fix

Require a sustained healthy window before failback, and verify the primary fully drains before serving traffic.

When things break

Debugging tips

  • Confirm which region a host is actually in via the metadata service before blaming replication.
  • Compare clock-skewed logs across regions using UTC timestamps.
  • Trace DNS: nslookup then curl -I to the resolved IP to verify traffic lands where you expect.
  • Watch the replication lag metric — it is your true RPO under load.
Interviews

Interview checkpoint

Practice

Hands-on lab

Measure Latency and Simulate Failover
30 min · advanced
In progress
Objectives
  • Resolve and measure the primary endpoint's latency
  • Inspect DNS records behind the endpoint
  • Simulate a failover by switching endpoint configuration
  • Verify the standby serves traffic after the switch

Measure Latency and Simulate Failover

30 min · advanced

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

Quick quiz

0/3
1

An availability zone is best described as:

2

Which metric defines the maximum acceptable time before systems must be recovered after an outage?

3

Synchronous replication across regions provides the lowest possible RPO.

Quick reference

Cheat sheet

Availability vocabulary
RegionGeographic cluster of facilities
Availability zoneIsolated facility, independent power/network
RPOMax data you accept losing (replication cadence)
RTOMax downtime you accept (failover speed)
FailoverShifting traffic to a healthy copy
Verify from the shell
ping -c 4 api.example.comReachability + latency to the active endpoint
nslookup api.example.comWhich IP the record resolves to
dig api.example.com ADNS record behind the failover
date -uUTC logs line up across regions
Go deeper

Official documentation

AWS: Global Infrastructure — Regions & AZs
docs
Azure: Availability Zones Overview
docs
Google Cloud: Regions and Zones
docs
Google Cloud: Disaster Recovery Planning Guide
docs