AWS admits permanent loss of customer data after Iranian strikes on its Bahrain data centers
On September 15, 2026 AWS acknowledged it cannot restore access to data hosted in availability zones hit in Bahrain and the United Arab Emirates. Replicate across regions and reread what your durability commitments actually guarantee.
March 1, 2026. Iranian drones strike AWS data centers in Bahrain and the United Arab Emirates. September 15, 2026. Six months later, AWS admits it will not be able to restore access to some customer data. September 2026. The durability of the public cloud has just met its physical limit. Why it matters: a hyperscaler has lost data permanently, and the admission contradicts the intuition that the cloud makes data indestructible.
What the admission contains
On September 15, 2026, an update to the AWS Health dashboard — first spotted by Reuters — acknowledged that the company is “unable to restore access to the resources and data” hosted in some war-damaged data centers. The wording is careful, but the meaning is plain: some customer data is irretrievably lost.
The detail is sharper than the statement. In the United Arab Emirates region, the loss is confined to one availability zone out of three — mec1-az2. The other two zones are being restored. In Bahrain, it is worse: AWS says it cannot restore access to resources and data across all three availability zones in the region.
AWS says it plainly: “The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand.” That sentence deserves a second read, because it is a rare admission from a hyperscaler.
The timeline of a physical disaster
The first strikes date to March 1, 2026, in the days after the US–Israel–Iran conflict opened. Drones targeted the data centers in Bahrain and the UAE. AWS urged customers to migrate to other regions and restore from remote backups.
A second strike, on April 1, 2026, focused on Bahrain. Then, on July 24, 2026, Iran’s Islamic Revolutionary Guard Corps claimed a missile strike against the last remaining structure in Bahrain, damage independently confirmed by satellite imagery.
In response, AWS suspended billing in the affected regions and issued roughly $150 million in customer credits, according to Forbes. Those gestures soften the bill, not the loss: a credit cannot restore data that no longer exists.
Multi-AZ is not multi-region
The technical lesson is direct. The durability the cloud sells rests on an implicit assumption: failures are partial and recoverable. A disk dies, you replace it. A zone goes down, you fail over. The multi-AZ model is built to survive the loss of a single zone, not the simultaneous destruction of several zones in one region by kinetic action.
That is exactly the boundary the AWS admission illuminates. “Exceeded what our multi-AZ services are designed to withstand” means that the durability guarantee — the famous 11 nines advertised for S3 — applies to objects replicated within a region, under conventional failure. It does not cover an entire region physically destroyed by war.
For an SRE, the translation is blunt: multi-AZ is not multi-region. Cross-region replication and out-of-region backups are not comfort features — they are the only real protection against an event that takes down a whole region. The lesson is not new, but it has just become a headline.
Shared responsibility, reread under fire
The incident also sharpens the shared responsibility model. AWS guarantees the resilience of the infrastructure; the customer remains responsible for the resilience of their data. But that split assumes both parties share the same definition of risk. When the infrastructure takes a missile strike, the line between “provider resilience” and “customer resilience” blurs — and it is the customer who, in the end, discovers their data no longer exists.
The operational takeaway is simple: read your durability commitments and don’t confuse them with all-risk insurance. If your recovery plan relies on intra-region replication, you are carrying a risk your own provider does not cover.
What to do
The first step is to map where your data lives. For every critical workload, ask yourself: which region does it run in, and where do its backups live?
# List the regions of your S3 buckets and EBS snapshots (AWS CLI example)
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].{Region:Region,Id:SnapshotId}' --output table
aws s3api list-buckets --query 'Buckets[].Name' --output tableNext, set up cross-region replication for the data you cannot afford to lose. For S3, cross-region replication (CRR) duplicates objects to a distant region; for databases, asynchronous replication to another region does the same job. The goal is not high availability — it is survival: a copy outside the danger zone.
Finally, test the restore. A backup that has never been restored is an assumption, not a backup. The scenario to rehearse is no longer “a disk fails” but “the region disappears”: how long to rebuild, and with how much data loss?
Verdict
The AWS admission of September 15, 2026 is a milestone: the public cloud has lost customer data permanently, and it was not a bug but a physical strike. If your critical data lives in a single region, replicate it elsewhere now — multi-region is the only boundary that survives physical destruction. If you are already multi-region, test your failover and measure your real RPO: it is that number, not the durability promises, that tells you what you lose when the region disappears. Cloud resilience has limits; those limits have just been drawn in rocket fire.