Skip to content
Multi-AZ is not a backup: the AWS Bahrain lesson
Back to Blog
#AWS Bahrain region#me-south-1#multi-AZ vs multi-region#cross-region replication#disaster recovery#shared responsibility model#reshaped-v3

Multi-AZ is not a backup: the AWS Bahrain lesson

Zohaib Masood

Multi-AZ is not a backup. It is designed to survive the loss of one data centre inside a region, and nothing more. On 15 September AWS told customers it is "unable to restore access to the resources and data hosted exclusively in" its Bahrain region — not degraded, not delayed, gone. If your client's data lives in one AWS region and nowhere else, "multi-AZ" in the annex is a description of the building, not a backup.

The notice is worth reading for what it says rather than what the headlines said. For Bahrain (me-south-1), AWS says the damage "spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand", and that after a thorough assessment it cannot restore what was held only there. A further update is promised for early 2027. For the UAE region (me-central-1), the loss is narrower: data held exclusively in one zone, mec1-az2, is unrecoverable, while AWS continues to recover regional resources and the other two zones and is "working on replacing the affected infrastructure". Headlines said AWS "will not reopen" its Gulf data centres; that phrase is in neither notice. When Data Center Dynamics put that reading to an Amazon spokesperson, the company said it contradicted the updates, then declined to say whether the sites reopen with new hardware.

What multi-AZ was designed to withstand

One zone. AWS wrote the definition itself on the same dashboard, in March, while the second UAE zone was failing:

"Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone while maintaining S3's durability and availability."

— AWS Health Dashboard, 2 March 2026

That held for a day. One zone went down on 1 March and S3 kept working; when a second became impaired, error rates climbed and ingest and egress began failing. So the three words in a hosting agreement describe three different things. Zonal — an EC2 instance, an EBS volume — is one building. Regional — S3, DynamoDB, RDS multi-AZ — survives one building. Cross-region is the only tier that survives what happened in Bahrain, and nothing is cross-region unless somebody configured a copy and pays for it every month.

Whose job that copy was is not ambiguous. AWS's shared responsibility model says it owns "protecting the infrastructure that runs all of the services", while customers "are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions". Durability of the service is AWS's. The existence of a second copy is yours. The September notice is that page applied: "using backups where available" is the sentence for customers who had one, and "exhausted every option" is the sentence for those who did not.

What goes into the next contract

Five lines, and none of them are expensive compared with the conversation you would otherwise have with a client.

  1. Name the second region. Not "AWS", not "multi-AZ" — a named region, chosen with the client, so data residency is agreed rather than assumed.
  2. Replicate the buckets. S3 Cross-Region Replication on everything holding client data, with Batch Replication to copy what is already there. AWS prices it as destination storage plus replication requests plus inter-region transfer, so it is a recurring second storage bill. Quote it; do not call it cheap.
  3. Copy the databases. AWS Backup with a cross-region copy rule for EBS, RDS and DynamoDB, or a cross-region read replica where the client needs a warm database rather than a restorable one.
  4. Put a date on a restore test. In the annex, on a schedule, with a named owner. A backup nobody has restored is a hope.
  5. Keep one copy outside AWS. The 3-2-1 rule predates the cloud and the cloud has not repealed it.

AWS gave six months of warning before the September notice, recommending from 1 March that customers migrate and restore in other regions. Most did. The work above is what separated them from the ones who could not.

If you want that reviewed against a client contract you have already signed rather than the next one, Vesprr Software does the architecture work and the annex that goes with it.

Sources