Multi-AZ is High Availability, Not Disaster Recovery

AWS has officially announced that they cannot restore data exclusively stored in Baharain (me-south-1) region after the recent drone attacks.

Let’s be honest for a second: how many of us deploy an RDS instance across multiple Availability Zones, and mentally check the "Disaster Recovery" box and move on to the next ticket.

I've done it, you've probably done it, and our compliance checklists usually let us get away with it. We spin up our infrastructure in us-east-1a and us-east-1b, run a quick failover test, and tell our stakeholders that our data is safe from disaster.

But the recent permanent data loss in the AWS Middle East regions (Bahrain and UAE) was a harsh, unavoidable reality check. It shattered the comfortable illusion we’ve built around the cloud. It reminded us that "the cloud" isn't an ethereal, indestructible entity floating above the fray—it’s just a massive, very expensive building full of physical hardware sitting in a physical location.

When the dust settled, the incident exposed a massive blind spot in how we architect systems: High Availability (HA) is not Disaster Recovery (DR).

High Availability is your defense against component failure. It’s what keeps your application running when a hard drive dies, a top-of-rack switch fries, or a backhoe cuts a fiber line outside a data center. Multi-AZ deployments are brilliant for HA.

Disaster Recovery, on the other hand, is your defense against catastrophe. It’s your plan for when an entire region goes offline due to a massive power grid collapse, a Category 5 hurricane, or—as we saw recently—kinetic geopolitical events.

If your entire infrastructure and its backups live inside the same 60-mile radius, conflating HA with DR leaves your most critical assets exposed. Let’s break down exactly why Multi-AZ isn't the safety net you think it is, and what you actually need to survive a total regional failure.

The Geographic Proximity Trap#

In system architecture guides, the golden rule taught is always the same: deploy your workloads across multiple Availability Zones to ensure resilience. It is the most straightforward way to survive a localized data center failure, like a severed fiber line or a critical hardware fault.

An Availability Zone is a discrete, fully isolated data center (or a cluster of them) equipped with its own redundant power, networking, and cooling infrastructure. But here is the architectural catch that often gets ignored: to keep features like synchronous database replication working with single-digit millisecond latency, cloud providers must physically build these AZs close to one another. Generally, all AZs within a single AWS region are located within a 60-mile (100-kilometer) radius.

Sixty miles might feel like a long distance when you are driving, but on a geological, meteorological, or geopolitical scale, it is a single point of failure. A Category 5 storm system, a catastrophic regional power grid collapse, or extreme kinetic events—like those that compromised the Middle East regions—do not respect the logical subnets of your VPC. They have massive blast radii. If your primary and secondary data centers are physically close enough to be swallowed by the same weather system or conflict zone, they share a threat radius.

You cannot out-engineer physical proximity with more software or better code. In cloud computing, physical distance is the only true mitigation for regional threats. Architecting for actual disaster recovery means accepting that the hardware exists in the real world, and you must look beyond the borders of a single region to keep it safe.

Synchronous Replication Copies the Disaster#

When you architect a high availability solution using RDS Multi-AZ or Amazon Aurora, the primary mechanism protecting your data is synchronous replication. When your application writes to the primary database, the storage engine ensures that data is copied to the standby instance in the secondary AZ before acknowledging the transaction. If the primary instance experiences a hardware failure, the system automatically fails over to the standby with zero data loss. It is an incredibly powerful tool for maximizing uptime.

However, synchronous replication creates a dangerous blind spot when used as a Disaster Recovery strategy. While it protects against hardware failure, it offers zero protection against logical corruption.

If a rogue database migration accidentally drops a critical production table, or if a ransomware attack begins encrypting your volumes, that destruction is synchronously replicated to the standby AZ in milliseconds. Your standby instance becomes just as corrupted, just as quickly, as your primary.

True Disaster Recovery requires a structural break in this replication chain. It demands asynchronous, cross-region replication combined with immutable, point-in-time snapshots—like those managed through AWS Backup Vault Locks. When dealing with widespread logical corruption or a severe regional outage, you must have an uncorrupted, isolated state to roll back to, rather than relying on a standby that perfectly mirrors the disaster.

Control Plane Paralysis#

We spend hundreds of hours refining our Infrastructure as Code.

We meticulously write our IaC to be reusable. And we build a dangerous assumption: if a region goes dark, we believe we can simply point our CI/CD pipeline at a secondary region, hit deploy, and watch our automation rebuild our world in minutes.

But there is a catastrophic flaw in this assumption. When an AWS region experiences extreme physical duress, the regional control plane almost always degrades long before the data plane does.

The control plane consists of the APIs and administrative layers you use to manage your infrastructure—it’s the mechanism that responds when you run an Ansible playbook or apply a Terraform configuration. The data plane is the actual underlying hardware running your currently provisioned EC2 instances and network packets. During a severe regional event, your existing servers might still be churning away (the data plane), but the API required to interact with them, modify them, or read their state (the control plane) will likely be unresponsive.

This creates a terrifying scenario: the lockout. If your automated failover scripts or IaC pipelines rely on querying the failing region's API to determine the current resource state before initiating a failover, your pipeline will simply hang and time out. You will be locked out of your own escape hatch.

A common scenario is storing Terraform state of the pilot light in the same S3 bucket in the primary region along with the state of the primary.

Disaster recovery automation cannot rely on the health of the very system it is trying to escape. To survive control plane paralysis, your standby environments must be fully independent and pre-provisioned, and your failover triggers must execute without requiring a single successful API call to the dying region.

Designing for Total Regional Loss#

Stepping outside the 60-mile radius of a single region forces you to balance your Recovery Time Objective (RTO) against infrastructure costs. Architecting for total regional loss generally falls into two practical strategies for most engineering teams: Pilot Light and Warm Standby.

A Pilot Light approach keeps your most critical core—your data—continuously replicated to a secondary region using asynchronous replication and cross-region backups. The rest of your infrastructure, like your application servers and network daemons, is scaled down to zero. When disaster strikes, you "light" the surrounding infrastructure. A Warm Standby, on the other hand, maintains a scaled-down but fully functional version of your entire stack. It costs more to run, but it can absorb traffic almost instantly.

Regardless of the strategy you choose, succeeding in a secondary region requires two critical components:

#1: Infrastructure as Code (IaC) Portability#

Your Terraform or OpenTofu configurations must be completely region-agnostic. If your modules hardcode region-specific AMI IDs, VPC endpoints, or static IP allocations, your deployment will immediately fail when pointed at a new region. Your IaC must rely on dynamic data sources to look up AMIs and endpoints at runtime. The goal is a codebase that can be deployed to a completely empty AWS region and successfully provision an identical, functional environment without a single line of code changing.

#2: Global Traffic Management#

When a region dies, your users need to be routed around the crater. This requires decoupling your DNS from regional infrastructure using global services like Route 53 and implementing failover routing policies tied to aggressive, independent health checks to automatically divert traffic to your standby region.

Furthermore, your global entry points, like your CloudFront distributions, must be carefully configured to handle the origin shift smoothly. It is critical that your cache behaviors map correctly to the secondary origins, right down to the specific cache keys. For example, if you rely on managed cache policies like UseOriginCacheControlHeaders-QueryStrings, you must ensure your secondary region's application layer handles those query strings. And the cookies they evaluate in the cache key are exactly similar to that of your primary region.

The Physical Reality of the Cloud#

The permanent data loss in the Middle East regions was a wake-up call for the entire industry. It stripped away the seamless abstraction of "the cloud" and reminded us of a fundamental truth: our systems are built on physical hardware, sitting in physical buildings, subject to the exact same physical risks as a traditional on-premise data center.

Software-defined networking and synchronous database replication are incredible tools for keeping systems highly available, but they cannot out-engineer a localized catastrophe.

If you are managing production infrastructure, take a hard look at your architecture this week. Audit where your primary data lives, where your Terraform state files are stored, and where your backups are vaulted.

If your entire workload, your automated failover scripts, and your immutable snapshots all live inside the same 60-mile radius, you have High Availability. You do not have Disaster Recovery.

It is time to architect accordingly.

Frequently Asked Questions#

Q: What is the difference between High Availability (Multi-AZ) and Disaster Recovery in AWS?#

A: In AWS, High Availability (HA) protects against localized component failures by deploying workloads across multiple Availability Zones (AZs) within the same region—typically within a 60-mile radius. Disaster Recovery (DR) protects against catastrophic, region-wide events by isolating fully independent workloads, state files, and backups in a completely separate AWS region. Relying solely on Multi-AZ for DR leaves your architecture vulnerable to shared physical threats, such as extreme weather, power grid collapses, or geopolitical disruptions.

Q: Why is synchronous database replication dangerous for Disaster Recovery?#

A: Synchronous replication, such as Amazon RDS Multi-AZ, is designed strictly for hardware fault tolerance. It offers zero protection against logical data corruption. If a rogue database migration drops a critical table or a ransomware attack encrypts your volumes, that destruction is synchronously copied to the standby database in milliseconds. True Disaster Recovery requires asynchronous, cross-region replication combined with immutable point-in-time snapshots to ensure you have an uncorrupted state available for rollback.

Q: What is control plane paralysis during an AWS regional outage?#

A: Control plane paralysis occurs when a severe regional outage degrades the AWS APIs (the control plane) used to manage resources, even if the underlying hardware (the data plane) remains active. If your disaster recovery automation, such as a Terraform deployment or an Ansible failover playbook, relies on querying the failing region's API to read state files or retrieve resource ARNs, the pipeline will time out and fail. To survive control plane paralysis, standby DR environments must be pre-provisioned, and their state files must be physically decoupled from the primary region.