
AWS Bahrain region unrecoverable: what the 15 September notice actually says, what multi-AZ was designed to withstand, and the cross-region backup clause a Pakistani software house writes next
The headlines on 15 and 16 September said AWS "cannot restore" its Bahrain region and "will not reopen" its Gulf data centres. The second claim is not in the notice. The first is, and it is narrower and worse than the headline: AWS cannot restore the resources and data hosted exclusively in this Region. A Pakistani software house with "hosted on AWS, multi-AZ" in a client's disaster-recovery annex should read it the way a compliance officer reads a regulation: for what it promises, and for what it never promised.
What the two notices say
Two updates on the AWS Health Dashboard, five minutes apart on Tuesday (15:22 and 15:27 PKT). The Bahrain one, for me-south-1, says the damage "spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand", and that AWS "exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable". A further update is promised for early 2027.
The UAE one, for me-central-1, is different, and the difference matters. AWS cannot restore what was "hosted exclusively in the mec1-az2 Availability Zone". It is still "working on recovering regional resources" and the other two zones, and it is "replacing the affected infrastructure", with an update "in the coming months". One region's data is declared unrecoverable. One zone of the other is. That is the whole of what AWS has said. When Data Center Dynamics put the "will not be reopening" reading to an Amazon spokesperson, the answer was that it contradicted the updates, then a refusal to say whether the sites reopen with new hardware.
The cause, in AWS's words on 2 March: "physical impacts to infrastructure as a result of drone strikes". That is the only sentence this article needs on it.
What "multi-AZ" was designed to withstand
AWS wrote the definition itself on 2 March, while the second UAE zone was going down: "Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone." One. The 1 March notice that reported "objects that struck the data center, creating sparks and fire" also said customers "running their applications redundantly across the AZs are not impacted by this event". That held for a day. By 2 March two of the three UAE zones were impaired; by 30 April Bahrain was "currently unavailable".
So the three words in a hosting agreement mean three different things. Zonal, an EC2 instance or an EBS volume, is one building. Regional, S3 or DynamoDB or RDS multi-AZ, survives one building. Cross-region is the only tier that survives what happened in Bahrain, and nothing is cross-region unless someone configured a copy and pays for it monthly. AWS's own Back to Basics episode and its re:Invent session with Fidelity both treat a second region as something the customer builds and tests.
Whose responsibility the copy was
AWS's shared-responsibility page says it in two sentences: AWS "is responsible for protecting the infrastructure that runs all of the services", and "customers are responsible for managing their data". Durability of the service is AWS's; the existence of a second copy is the customer's. The 15 September notice is that page applied. "Using backups where available" is the phrase for the customers who had one; "exhausted every option" is the phrase for the ones who did not.
AWS also gave six months of notice: restore in another region on 1 March, replicate S3 elsewhere on 2 and 3 March, "recover your resources in other Regions from remote backups" on 30 April. "Most did so", the Bahrain notice says. This article is for the rest, and for every integrator whose client annex still reads "AWS handles availability".
The clause and the checklist
For a Karachi or Lahore software house that would rather not answer a client's data-residency question with "India", the two Gulf regions were the near choices. One is unrecoverable; the other has "the coming months" as its only date. The next contract, in order:
- Name the second region in the contract. Not "AWS", not "multi-AZ". A region, chosen with the client.
- S3 Cross-Region Replication on every bucket that holds client data, with S3 Batch Replication to copy what already exists. AWS's pricing page bills it as destination storage plus replication PUT requests plus inter-region transfer; its worked example uses $0.02 per GB for the transfer, and rates vary by source region. At that rate a 2 TB estate is about $41 to move once (my arithmetic) and a second 2 TB storage bill every month after. Price it; do not call it "cheap".
- AWS Backup with a cross-region copy rule for EBS, RDS and DynamoDB, or an RDS cross-region read replica where the client needs a warm database.
- Route 53 health checks that fail over, and one restore test with a date on it, in the annex, on a schedule. A backup that has never been restored is a hope.
- One copy outside AWS entirely. The 3-2-1 rule predates the cloud, and the cloud has not repealed it.
Two predictions, mine and not AWS's. First: the early-2027 Bahrain update will describe new infrastructure or a further delay, not a restoration of the old region; the UAE notice already says "replacing", and a spokesperson who will not answer the hardware question is not describing a repair. Second: before the end of Q1 2027 a client of yours will send a vendor questionnaire with a named-second-region and dated-restore-test line in it, citing this incident. If the first is wrong, the dashboard will say so in January. If the second is wrong, you had a quiet quarter, and you should still have done the list.
Sources
- AWS Health Dashboard: the me-south-1 and me-central-1 notices of 15 September 2026 and the history back to 1 March, Amazon Web Services
- Shared Responsibility Model, Amazon Web Services
- Replicating objects within and across Regions, AWS documentation, and Amazon S3 pricing (replication section)
- AWS unable to restore access to data centers, Data Center Dynamics, 16 September 2026
- Back to Basics: How to Implement a Multi-Region Disaster Recovery Strategy Using AWS DRS, Amazon Web Services
- AWS re:Invent 2025 - Multi-Region disaster recovery & resilience testing (feat. Fidelity) (COP358), AWS Events
- What Is Multi-AZ Versus Multi-Region?, Cloud Stack Studio
- RDS Multi-AZ Explained: Automatic Failover & High Availability for AWS Databases, CodeLucky
- Multi-AZ vs Multi-Region: AWS Disaster Recovery (SAA-C03) | Ep. 14, Cram Exam