AWS Availability Zones vs Disaster Recovery: Why High Availability Is Not DR

Ok, I’m going to say it - I told you so! Availability Zones aren’t a complete disaster recovery solution.

In September 2026, AWS confirmed that, following the conflict in the Middle East, it couldn't restore access to damaged data centre infrastructure in the UAE and Bahrain, and it couldn't recover resources and data hosted exclusively in the affected zones. As stated in this article, the Bahrain situation was the starker of the two: the damage spanned multiple Availability Zones and "exceeded what our regional and multi-AZ services are designed to withstand." Data that lived only in that region is, for practical purposes, gone.

This isn't the place to relitigate the geopolitics, and it would be too easy and not especially useful. At Dbvisit, we've been consistent and open with customers and partners about one uncomfortable truth: high availability isn't disaster recovery, and out-of-region DR isn't a luxury; it's a vital part of the organisation's DR strategy. The AWS statement is simply the clearest public illustration of the principle we keep coming back to.

I think this event is another wake-up call to discuss Availability Zones. What are Availability Zones good for, where do they fall short as a disaster recovery strategy, and why does out-of-region DR matter in both cases?

What an Availability Zone actually is

An Availability Zone (AZ) is one or more discrete data centres within a single cloud region, each with independent power, cooling, and networking. The zones in a region are physically separated but connected by high-bandwidth, low-latency links, close enough that you can run synchronous replication between them, far enough apart that a localised problem in one building shouldn't take down another.

That design point matters because it defines both the model's strength and its limits. AZs are engineered to contain localised failure. They are not engineered to survive the loss of the region they sit in.

The benefits of Availability Zones

It's worth being fair here, because AZs are genuinely good at what they were built to do.

They protect against single-facility failure. A power event, a cooling failure, a fire, a hardware or local network fault in one data centre - an AZ architecture rides through these by shifting workload to another zone. For the most common causes of downtime, this works well.

They enable synchronous replication and near-instant failover. Because the zones are only tens of kilometres apart, latency is low enough to keep a second copy perfectly in step. For databases, managed multi-AZ options (or a synchronous standby in a second zone) mean automatic failover in seconds with no data loss for that class of failure.

They are simple and cost-effective. Multi-AZ is often a checkbox on a managed service. There are no cross-region data-egress charges to reason about, and the operational burden is light.

They keep data in one jurisdiction. For organisations with data sovereignty obligations, keeping everything in a single region is often a feature, not a bug.

In short, AZs are an excellent high-availability tool. The problem begins when people mistake them for a complete disaster recovery strategy.

The disadvantages of Availability Zones as a DR strategy

Every zone shares the region's fate. This is the core issue. AZs are close together by design, which means they share exposure to anything that operates at regional scale. A major natural disaster, a regional power-grid failure, and, as the Middle East event showed, a physical or geopolitical event large enough to damage several facilities at once. When the threat is bigger than a single building, geographic proximity stops being a safety margin and becomes a shared liability.

Multi-AZ is built to a tolerance, and tolerances can be exceeded. AWS's own wording is instructive: the damage went beyond what multi-AZ services were designed to withstand. Resilience engineering always assumes a failure envelope. A sufficiently large event simply falls outside it, and when it does, having three copies inside that envelope helps you little.

Correlated, region-wide failures are real. Physical destruction is the dramatic case, but region-scoped software problems are the more frequent one. Control-plane outages, propagating misconfigurations, and dependency failures have repeatedly degraded multiple AZs in the same region at the same time. Independence between zones is never absolute.

A single regional copy has no escape hatch. You can't recover data held exclusively in the region. If your only copy, including your only database copy, lives inside one region, then the region is your single point of failure, no matter how many zones you spread it across.

It often fails compliance and contractual DR requirements. Many regulatory frameworks and customer contracts explicitly require geographic separation between primary and recovery sites. Three AZs in one metro area rarely satisfy that test.

Why out-of-region DR matters

Out-of-region DR means maintaining a recoverable copy of your data in a geographically distant location. It can be another region, another cloud, or your own data centre. That distance is the whole point. A second site far away sits on a different power grid, in a different fault domain, often under a different jurisdiction, and, crucially, outside the blast radius of any single regional event.

Out-of-region DR doesn't compete with AZs; it complements them. You keep everything AZs give you: fast, automatic, zero-data-loss failover for everyday local faults. You simply add a further tier for the catastrophic scenario the zones were never meant to cover. The two are complementary, not alternatives. AZs handle the failure of a building; out-of-region handles the loss of the region.

Out-of-region DR is the direct mitigation for every weakness above. Shared regional fate, exceeded design tolerances, correlated control-plane failures, the single-regional-copy issues, and geographic-separation compliance requirements each of these is answered by having a live, recoverable copy somewhere the regional event cannot reach.

For databases specifically, this is where a continuously synchronised standby in a second region earns its keep. Rather than a nightly backup you then have to restore under pressure, a standby database is kept in step with the primary and can be brought online in minutes. Asynchronous replication over distance introduces a small recovery-point window, but with the right architecture and zero-data-loss techniques, that gap can be driven close to a better outcome than discovering your only copy was in a region that no longer exists.

The question worth asking

The AWS Middle East event is not an indictment of cloud, and it's certainly not an indictment of Availability Zones. AWS did roughly what the architecture promised: it contained localised failures and told customers, honestly, where the damage exceeded the design. The lesson isn't "distrust the region." The lesson is to be precise about what each resilience layer is for.

So the practical question for anyone responsible for data and for databases in particular is simple: If this entire region disappeared this afternoon, where is my second copy, how far away is it, and how quickly could I run production from it?

If the honest answer is "another zone in the same region," then you have excellent high availability and no disaster recovery. Those are not the same thing. They never have been, and a set of data centres in the Middle East has just reminded the whole industry why.

If your database is running in the cloud, make sure your disaster recovery strategy extends beyond a single region. Learn more about building resilient, out-of-region disaster recovery with Dbvisit StandbyMP.

And if you have any questions or would like some advice from our team of expert DBAs, you can book a call with our team today.