Eleven Nines Is a Promise About Disks, Not About Geography

On 15 September, Amazon Web Services told its customers something no hyperscaler has ever had to say. Not that a region was degraded, or that recovery was taking longer than hoped, but that the data is gone and is not coming back.

Here it is verbatim from the AWS Health Dashboard update on the Middle East (Bahrain) region, me-south-1: “The damage to our infrastructure spanned multiple availability zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this region.”

TL;DR

• AWS has confirmed permanent, unrecoverable customer data loss in me-south-1 (Bahrain) and in one availability zone of me-central-1 (UAE), six months after drone strikes in March 2026.
• S3’s eleven nines of durability is designed to survive the loss of one availability zone, and AWS places all zones in a region within 100 km of each other. It is a promise about hardware failure, not about geography.
• There is no S3 durability SLA. The SLA covers availability, its sole remedy is service credits, and it explicitly excludes force majeure.
• AWS reported the loss as mec1-az2, an AZ ID. Your Terraform says me-central-1b. Nothing in your codebase connects the two.
• S3 does not replicate KMS-encrypted objects across regions by default, and a replication rule pointing at an invalid key returns 200 OK and silently copies nothing.

What actually happened

In early March 2026, at the outbreak of the conflict, Iranian drones struck targets across the Gulf. Two AWS data centres in the UAE were hit directly and a facility in Bahrain was damaged by a nearby strike.

On 30 April, AWS warned that restoration would take months. On 15 September it stopped saying “months”. For the UAE region the statement reads: “After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in the mec1-az2 availability zone. We continue to work on recovering regional resources, as well as zonal resources hosted in the other affected Availability Zones (mec1-az1 and mec1-az3).”

Amazon has not said how much data was lost, or how many customers lost it.

Notice the load-bearing word in both statements: exclusively. AWS is not telling you whether your data survived. It is telling you that whether your data survived is a function of a decision you made, possibly years ago, and probably never wrote down.

Eleven nines was never the promise you thought it was

Every architecture review we have ever sat in reaches for the same number. S3 is designed for 99.999999999% durability. Eleven nines. It does not mean what most teams think it means, and AWS’s own documentation says so plainly.

From the S3 data protection docs: S3 Standard and the Glacier classes “are all designed to sustain data in the event of the loss of an entire Amazon S3 Availability Zone”. Singular. One zone. Bahrain lost multiple, which is exactly what AWS said when it used the phrase “exceeded what our regional and multi-AZ services are designed to withstand”. That is not an admission of failure. It is the published specification being met at its boundary.

The same page also says that availability zones “are physically separated by a meaningful distance, many kilometers, from any other Availability Zone, although all are within 100 km (60 miles) of each other.”

Eleven nines is a statistical model of uncorrelated component failure. Disks die independently, so redundancy multiplies. A regional threat is the opposite of independent: it is perfectly correlated across everything inside its radius. Drones, floods, grid collapse and national-scale conflict do not respect a 100 km boundary. Multi-AZ is a superb answer to a failing rack and no answer at all to a failing geography, and the separation AWS engineers for is smaller than the blast radius of the events that actually destroy regions.

Your contract does not cover this, and it never did

There is no durability SLA for S3. The eleven nines figure appears in documentation as a design target, not in any contract as a warranty. What exists is an availability SLA, under which “your sole and exclusive remedy for any unavailability, non-performance, or other failure by us to provide Amazon S3 is the receipt of a Service Credit”. Not damages. Not your data. A credit against next month’s bill.

The exclusions then remove even that: the service commitment does not apply to issues “caused by factors outside of our reasonable control, including any force majeure event”. A missile strike is the textbook case. Every major cloud provider’s terms read the same way, and the shared responsibility model has always put backups on your side of the line.

The dead zone has a name your codebase has never used

AWS reported the loss as mec1-az2. That is an AZ ID, not an availability zone name. Your infrastructure code does not contain that string. It contains me-central-1a, me-central-1b, me-central-1c: subnet definitions, RDS placements, autoscaling group settings, all written in a vocabulary AWS does not use when it tells you a facility is gone.

AWS keeps two naming systems because it has to. In its own words: “the us-east-1a for your AWS account might not be the same physical location as the us-east-1a for another AWS account.” The letter suffix was randomised per account to stop everyone crowding into the first zone. The AZ ID is the account-independent identifier, and use1-az1 “has the same physical location in every AWS account”.

There is an Irish wrinkle that matters to anyone reading this from Dublin. AWS has moved most regions to uniform mapping, but nine regions still map zones independently for accounts created before November 2025, and Europe (Ireland) is on that list. If your company opened its AWS account before last November and runs in eu-west-1, your eu-west-1a is genuinely not your supplier’s eu-west-1a, your auditor’s, or your disaster recovery partner’s.

The fix takes a minute:

aws ec2 describe-availability-zones \
  --query "AvailabilityZones[].{Name:ZoneName,ID:ZoneId}" \
  --output table

Record the ID beside the name in your infrastructure inventory, and capture it at runtime from instance metadata at /latest/meta-data/placement/availability-zone-id.

The cross-region backup that returns 200 OK and copies nothing

If the lesson is “keep a copy in another region”, the implementation has two traps that both fail quietly.

The first is keys. AWS KMS documentation states it directly: “AWS KMS keys aren’t shared outside the AWS Region in which they were created.” For S3 replication the destination “KMS key must have been created in the same AWS Region as the destination bucket”. A cross-region copy encrypted under a key that lived only in the dead region is ciphertext you cannot open. You would have satisfied your auditor, passed your own tabletop exercise, and kept nothing.

The second is worse, because it looks like success. Per the S3 docs: “By default, Amazon S3 doesn’t replicate objects that are encrypted with SSE-KMS or DSSE-KMS.” You must explicitly opt in with a SourceSelectionCriteria block. Since January 2023 every new S3 upload is encrypted by default, so this is the normal case rather than the edge case, and the console still shows a replication rule that looks configured.

Then this, verbatim: “The PutBucketReplication API operation doesn’t check the validity of KMS keys. If you use a KMS key that isn’t valid, you will receive the HTTP 200 OK status code in response, but replication fails.” Your disaster recovery control can be misconfigured, report success, and copy nothing at all.

What to do this week

1. Build an exclusivity register. One list: every dataset that exists in exactly one region. Single-AZ RDS, EBS volumes and their snapshots, S3 One Zone-IA buckets, DynamoDB tables without global tables, Secrets Manager entries, KMS keys. If you cannot produce this list, you cannot answer the question AWS just asked its Bahrain customers.
2. Map names to AZ IDs and store both, especially on pre-November-2025 accounts in eu-west-1.
3. Verify replication is moving bytes, not that the rule exists. Compare object counts and check replication status metrics. A 200 OK from PutBucketReplication proves nothing.
4. Test a restore. Every six months, from the copy furthest away, with the clock running. As one engineer put it on Hacker News this week, none of it is worth anything if you do not actually test restores.
5. Write down your accepted risk. Sometimes single-region is the right call on cost. That is a defensible business decision when it is a decision, and an accident when it is a default.

REPTILEHAUS builds and runs cloud infrastructure for clients across Ireland and Europe, and resilience reviews are a large part of what our DevOps practice does. If you cannot currently produce your exclusivity register, or you are not certain your cross-region replication is copying anything, that is a short and worthwhile engagement. Get in touch and we will go through it with you.

📷 Photo by Chris Linnett on Unsplash