High availability

In large-scale cloud environments, hardware failures, localized power outages, network cuts, and software regressions are statistical certainties. Solid-state drives fail, physical host hypervisors reboot during security patches, and localized municipal disruptions can take an entire data center offline.

(HA) is the engineering practice of designing a system so that the failure of any individual component, server, or physical facility does not interrupt business operations. While cloud platforms make redundant infrastructure far simpler to provision than private data centers, achieving high availability requires deliberate trade-offs among network latency, architectural complexity, data synchronization mechanics, and financial cost.

Resilience is evaluated through the concept of a —the largest physical or logical boundary that can fail simultaneously. A resilient system is measured by its capacity to absorb the total loss of an entire failure domain while continuing to serve client traffic without degradation.

The resilience ladder

Each step on the resilience ladder protects against a broader failure domain than the one below it, carrying corresponding increases in architectural complexity and operating expense:

Resilience tier	Survives failure of	Vulnerable to failure of	Architectural requirements & cost profile
Single instance	Nothing; zero hardware redundancy	Host reboot, hypervisor crash, local disk corruption	Baseline compute cost; suitable only for non-critical dev/test
Multi-instance, single-zone	Single machine or process crash	Physical data center failure, power loss, cooling failure	Multiple compute instances behind a local load balancer
Multi-zone, single-region	Entire data center outage, local fiber cut	Full geographic region outage, regional control plane disruption	Instances distributed across 2-3 zones; synchronous replication; cross-zone network fees
Multi-region active-passive	Regional disaster or complete network partition	Global provider-wide control plane or DNS failure	Duplicated infrastructure in secondary region; asynchronous replication; automated DNS failover
Multi-region active-active	Regional failure with near-zero RTO	Systemic application bugs deployed globally	Active compute and data ingestion in multiple regions; distributed conflict resolution; highest engineering cost

The vast majority of production enterprise systems target the multi-zone tier within a single region. Multi-region deployments are reserved for mission-critical core systems where prolonged regional downtime produces catastrophic financial or regulatory fallout.

Multi-zone: the production baseline

A cloud region contains multiple distinct availability zones, each representing physically isolated data centers with independent utility feeds. Spreading infrastructure across two or three availability zones represents the standard baseline for production workloads.

Stateless application tiers deploy in an configuration: every instance across all zones serves live traffic simultaneously. A managed load balancer monitors backend health and automatically stops routing traffic to any instance that fails health checks. If an entire availability zone suffers a power or network cut, the load balancer removes the affected instances from service within seconds. Because instances in the surviving zones are already processing traffic, the failure results only in a temporary reduction in compute capacity, which an autoscaling group rapidly replenishes.

Stateful database tiers typically operate in an topology. A primary database instance in Zone A processes all read and write traffic while continuously streaming write operations via to a passive in Zone B. Because replication is synchronous, the primary does not acknowledge a committed transaction until the write is safely recorded in the standby replica's transaction log.

When the primary instance degrades, the managed database platform initiates an automated : promoting the standby replica to primary status and redirecting the internal database endpoint. This failover typically completes within 60 to 120 seconds, presenting application callers with transient connection retries rather than catastrophic data loss.

Making a system multi-zone

Eliminate single points of failure by distributing every infrastructure layer across multiple zones.

1. Deploy a managed load balancer that distributes traffic across at least two availability zones.
2. Maintain at least two healthy instances or container replicas per service tier in distinct zones.
3. Enable multi-zone high availability for managed databases to maintain an active synchronous standby replica.
4. Select zone-redundant tiers for caching layers, message queues, and shared network filesystems.
5. Validate resilience by periodically simulating the loss of an availability zone in a staging environment.

Multi-region: surviving geographic outages

While availability zones protect against local facility incidents, major geographic natural disasters, optical backbone severed across transit corridors, or widespread regional control plane outages can disable an entire region. Surviving a regional failure requires implementing (DR) infrastructure in a secondary geographic region.

Multi-region architecture introduces three fundamental engineering challenges:

1. Network latency and asynchronous replication: Because regions are separated by hundreds or thousands of kilometers, speed-of-light propagation delays make synchronous replication across regions impractical for interactive applications. Cross-region data replication must use , where the primary region acknowledges transactions locally before streaming changes to the replica. Consequently, the secondary region always lags slightly behind. If the primary region suffers a sudden total outage, un-replicated transactions in flight are lost. The maximum duration of un-replicated data an organization accepts losing is its (RPO).
2. Traffic redirection: Steering user traffic from a degraded region to a standby region requires automated DNS health check failover or anycast-routed global load balancing. The time required to detect regional failure, promote replica databases, and redirect traffic is the (RTO).
3. Operational drift: A standby region that sits idle without receiving production traffic inevitably suffers from configuration drift: forgotten environment variables, missing secrets, out-of-sync database schemas, or insufficient cloud resource quotas. Multi-region infrastructure is only dependable if organizations conduct regular, scheduled failover drills under realistic operational conditions.

Active-passive versus active-active across regions

Multi-region architectures follow two distinct patterns:

Operational dimension	Active-Passive Architecture	Active-Active Architecture
Write traffic routing	Directs all writes to a single designated primary region	Accepts writes concurrently across multiple active regions
Failover complexity	Requires explicit promotion of standby replica and DNS reroute	Zero failover required; traffic routes dynamically away from failed region
Data conflict handling	Eliminated by design; single authoritative source of truth	Requires deterministic conflict resolution rules (e.g. CRDTs or last-write-wins)
Standby cost overhead	Lower; secondary region can run as a scaled-down pilot light	High; all regions must run provisioned compute and storage at full scale
Best suited for	Systems requiring strict transactional consistency and ACID guarantees	Globally distributed read-heavy services, content platforms, or conflict-tolerant domains

For most enterprise applications requiring strong relational consistency, combining active-active stateless compute with active-passive database replication provides the most reliable balance between operational safety and disaster recovery resilience.

Global platform services

Certain cloud foundation services operate natively across a global control plane, abstracting multi-region resilience entirely:

• Global load balancers and Anycast IPs: Announce a single virtual IP address globally via BGP Anycast, automatically terminating client traffic at the nearest cloud edge and routing requests across internal optical backbones to healthy regional backends.
• Managed DNS networks: Resolve queries across hundreds of globally distributed edge locations simultaneously, surviving regional outages without intervention.
• Content Delivery Networks (CDNs): Cache static web assets, media, and API responses across global edge points of presence, shielding origin regional backends from traffic spikes.

Relying on global platform services for ingress routing provides the fault-tolerant foundation required to execute seamless regional failovers.

Measuring availability and SLAs

System availability is quoted as a percentage of total uptime over a calendar year, colloquially referred to as "nines":

Availability target	Allowable annual downtime	Typical architectural tier
99.0% (Two nines)	~3 days, 15 hours	Single virtual machine with basic monitoring and manual recovery
99.9% (Three nines)	~8 hours, 45 minutes	Multi-instance deployment with automated health checks
99.99% (Four nines)	~52 minutes	Multi-zone architecture with automated database failover
99.999% (Five nines)	~5 minutes	Multi-region active-active with automated traffic steering and chaos testing

Each additional "nine" demands roughly an order of magnitude increase in architectural complexity, operational testing, and infrastructure expenditure.

A cloud provider's (SLA) defines the availability commitments guaranteed for specific cloud services, alongside financial service credits issued if availability drops below those thresholds. Critically, provider SLAs govern individual cloud primitives rather than your composite application, and almost all provider database and compute SLAs explicitly require deploying across multiple availability zones to qualify for coverage.

Before choosing a rung

Align infrastructure resilience directly with business impact and recovery metrics.

1. Establish the maximum allowable downtime before business operations suffer critical impact; this is your Recovery Time Objective (RTO).
2. Determine the maximum allowable data loss tolerable during an unrecoverable failure; this is your Recovery Point Objective (RPO).
3. Select the most economical resilience tier that satisfies both RTO and RPO thresholds.
4. Schedule regular, automated disaster recovery drills to verify that failover mechanics function as expected.

Terms introduced

• High availability: arranging a system so that no single failure takes the service down.
• Failure domain: the largest thing that can fail at once: a machine, a zone, a region, or the provider.
• Active-active: every copy serves traffic, so a failure removes capacity rather than the service.
• Active-passive: one copy serves and another waits to be promoted.
• Failover: promoting the passive copy and moving traffic to it.
• Synchronous replication: copying a write before acknowledging it, so the copy is never behind. Practical within a region.
• Asynchronous replication: acknowledging a write and copying it afterwards, so the copy lags. The only option across regions.
• Recovery point objective: how much data the business accepts losing in a failover, measured in time.
• Recovery time objective: how long the business accepts being down, from failure to serving again.
• Disaster recovery: the multi-region rung, from backups in a second region through a warm standby to two live regions.
• Service level agreement: a provider's promise of credits if a service falls below a stated availability, applying to its service rather than your system.

---

How providers do it

High availability and disaster recovery patterns are supported across AWS, Azure, and Google Cloud, spanning intra-data-center hardware isolation, multi-zone clustering, and multi-region failover. The primary architectural distinction lies in how each provider implements global traffic steering during regional outages.

Concept	AWS	Azure	Google Cloud
Physical rack anti-affinity	Spread placement groups	Availability Sets	Spread placement policy
Multi-zone stateless compute	EC2 Auto Scaling group spanning zones	Virtual Machine Scale Sets across zones	Regional Managed Instance Groups (MIGs)
Multi-zone stateful database	Amazon RDS Multi-AZ deployment	Zone-redundant high availability	Cloud SQL high availability configuration
Zone-redundant storage	S3 (standard); zonal EBS volumes	Zone-redundant storage (ZRS) accounts	Regional Storage buckets, regional Persistent Disks
Multi-region database replication	Aurora Global Database, DynamoDB Global Tables	Azure SQL failover groups, Cosmos DB multi-region	Cloud Spanner multi-region, Firestore multi-region
Multi-region object storage	S3 Cross-Region Replication (CRR)	Geo-redundant storage (GRS / GZRS)	Dual-region and Multi-region storage buckets
Global regional failover routing	Route 53 health-checked DNS, AWS Global Accelerator	Azure Front Door, Azure Traffic Manager	Cloud Load Balancing (single global anycast IP)
Full-instance disaster replication	AWS Elastic Disaster Recovery (DRS)	Azure Site Recovery (ASR)	Asynchronous disk snapshot and image replication

Every product name and technical mapping above is confirmed against provider documentation. Specific service availability commitments, cross-region recovery point metrics, and specialized disaster recovery tooling are marked unconfirmed in the provider tabs below.

A fundamental difference exists in regional traffic management:

• Google Cloud routes external traffic through a single global virtual IP address announced worldwide via BGP Anycast. The global load balancer continuously evaluates backend health across all regions; if an entire region fails, traffic automatically reroutes to healthy backends in other regions within seconds without changing DNS records.
• AWS and Azure primarily handle multi-region traffic routing at the DNS layer (Amazon Route 53 or Azure Traffic Manager) or through dedicated application proxies (AWS Global Accelerator or Azure Front Door). DNS-based failover is subject to client-side caching and TTL propagation delays, requiring deliberate health check thresholds and automated traffic steering policies.

AWS

What this maps to: AWS's building blocks are all zonal or regional. Nearly every managed service has a multi-AZ setting. Multi-region is something you assemble yourself, from each service's replication feature plus Route 53 or Global Accelerator at the front.

Concept	On AWS	Status
Multi-zone compute	An Auto Scaling group spanning several AZs, behind an ALB or NLB that is multi-AZ by default	confirmed
Multi-zone database	RDS Multi-AZ (synchronous standby, automatic failover); Aurora keeps storage across three AZs regardless	confirmed
Zone-redundant services	S3, SQS, SNS, DynamoDB, EFS, and Lambda are regional and span AZs without configuration. EBS and ElastiCache are zonal unless configured otherwise	confirmed
Multi-region database	Aurora Global Database (one writer region, asynchronous replicas elsewhere); DynamoDB global tables (multi-region writes, last-writer-wins); RDS cross-region read replicas	confirmed
Multi-region storage	S3 Cross-Region Replication per bucket; S3 Multi-Region Access Points for one endpoint over several buckets	confirmed
Traffic switching	Route 53 failover routing with health checks; Global Accelerator for a static anycast address that steers to the healthy region in seconds	confirmed
Failover control	Application Recovery Controller holds routing controls and readiness checks so a failover is a deliberate switch rather than a DNS edit	confirmed
Disaster recovery for VMs	AWS Elastic Disaster Recovery replicates machines to another region and launches them on demand	confirmed
Availability promises	Published per service; EC2's applies to instances across more than one AZ	unconfirmed; check the current SLA page per service
Measured recovery point	Aurora Global Database typically lags under a second; DynamoDB global tables similar	unconfirmed; check current docs

Their vocabulary

Standard term	Their term
Availability zone	AZ
Multi-zone database	Multi-AZ
Active-active data across regions	Global tables (DynamoDB), write forwarding (Aurora Global Database)
Failover switch	Route 53 health check plus failover record, or a routing control in ARC

Where to look

Route 53 health check status, and the CloudWatch alarms on them. Every failover is recorded on the RDS Events tab. If a regional event is in progress, AWS Health shows it.

Last verified: never.

Azure

What this maps to: Azure distinguishes availability sets, which spread VMs across racks in one data centre, from availability zones. It also pairs regions for disaster recovery. Many services offer a zone-redundant tier as a setting.

Concept	On Azure	Status
Multi-rack, single zone	Availability set: fault domains and update domains within one data centre. Below the multi-zone rung, and the only option in regions with no zones	confirmed
Multi-zone compute	A Virtual Machine Scale Set spread across zones; a zone-redundant Standard Load Balancer or Application Gateway v2 in front; AKS node pools across zones	confirmed
Multi-zone database	Zone-redundant configuration on Azure SQL Database and on PostgreSQL and MySQL Flexible Server high availability	confirmed
Zone-redundant services	ZRS storage accounts, Service Bus Premium, Event Hubs, Key Vault, and Cosmos DB with zone redundancy enabled	confirmed
Region pairs	Each region has a paired region for platform replication and sequenced updates; GRS storage replicates to the pair	confirmed
Multi-region database	Azure SQL Database failover groups (asynchronous geo-replication with a listener endpoint that moves); Cosmos DB multi-region reads and optional multi-region writes	confirmed
Multi-region storage	GRS and GZRS redundancy, with read-access variants that let the secondary be read before a failover	confirmed
Traffic switching	Azure Front Door (anycast, layer 7, health-probed origins across regions) or Traffic Manager (DNS-based, with priority and performance routing)	confirmed
Disaster recovery for VMs	Azure Site Recovery replicates VMs to another region and orchestrates failover with recovery plans	confirmed
Availability promises	Published per service; the VM SLA differs for a single VM, an availability set, and zones	unconfirmed; check the current SLA page per service

Their vocabulary

Standard term	Their term
Multi-zone	Zone-redundant
Second region	Paired region
Global load balancer	Front Door
DNS failover	Traffic Manager
Failover of a database	Failover group

Where to look

Front Door's origin health in Azure Monitor. The failover group's blade shows the current primary. Azure Service Health shows a regional event and its affected services.

Last verified: never.

Google Cloud

What this maps to: Google Cloud sells many resources as regional (spread across a region's zones by the service) or global (one resource for every region). Several rungs of the ladder end up in a single setting as a result.

Concept	On Google Cloud	Status
Multi-zone compute	A regional managed instance group places instances across zones. A regional GKE cluster spreads the control plane and nodes	confirmed
Multi-zone database	Cloud SQL high availability (synchronous standby in another zone); AlloyDB is regional by design	confirmed
Zone-redundant services	Regional Persistent Disk replicates a block volume across two zones. Pub/Sub, Cloud Storage regional buckets, Firestore, and Cloud Run are regional and span zones	confirmed
Multi-region database	Spanner multi-region configurations take writes with strong consistency across regions; Firestore multi-region locations; Cloud SQL cross-region read replicas	confirmed
Multi-region storage	Cloud Storage dual-region and multi-region buckets, with turbo replication for a dual-region recovery point measured in minutes	unconfirmed; check current replication targets
Traffic switching	The global external Application Load Balancer has one anycast address and routes each request to the nearest healthy backend region, so region failover is automatic and needs no DNS change	confirmed
DNS-based failover	Cloud DNS routing policies with health checks	confirmed
Failover control	No separate recovery-controller product; failover is the global load balancer's health checks or a Cloud DNS policy	unconfirmed
Disaster recovery for VMs	Custom images and snapshots replicated across regions; no first-party equivalent to AWS Elastic Disaster Recovery	unconfirmed; check current offerings
Availability promises	Published per service; Compute Engine's applies to instances across more than one zone	unconfirmed; check the current SLA page per service

Their vocabulary

Standard term	Their term
Multi-zone	Regional
Multi-region, provider-managed	Global (load balancer, DNS), multi-region (Storage, Spanner, Firestore)
Standby database	Cloud SQL HA standby

Where to look

The load balancer's backend health in Cloud Load Balancing. Cloud SQL's Operations log for failovers. The Google Cloud Service Health dashboard for a regional event.

Last verified: never.

---

Check your understanding

0 of 4 answered

1. A service runs on three machines in one availability zone behind a load balancer. What is the largest failure it survives?

   One machine failing.The zone failing.The region failing.Any failure, because there are three copies.
2. Why do stateless services run active-active across zones while databases usually run active-passive?

   Stateless copies can all serve at once with nothing to reconcile. A database needs one place that takes writes, so a second copy waits to be promoted.Databases cannot be copied to another zone.Active-active is more expensive, and databases are already the most expensive tier.Load balancers cannot route to databases.
3. A product owner asks for five nines. What should you ask before agreeing?

   How long the service can be down and how much data it can lose, because five nines is about five minutes a year and needs multi-region active-active that most systems do not need.Which provider has the best SLA, since the provider's promise sets your availability.Whether the load balancer supports it.Nothing. Five nines is the default for managed services.
4. Why is a cross-region database copy asynchronous, and what does that cost you?

   Waiting for a copy hundreds of kilometres away would slow every write, so the copy lags, and the writes in flight are lost on failover.Providers do not allow synchronous copies between regions.Asynchronous copies are cheaper per gigabyte.Nothing. The copy is always up to date.