AWS has said it plainly: there is customer data that will not be recovered. Not a long outage, not degraded service — the data is no longer there.
What happened
In an update to its Health Dashboard, AWS confirms that anything held exclusively in its Bahrain Region — me-south-1 — remains inaccessible and that, after assessing it, access cannot be restored. The official explanation is that the damage to the infrastructure hit several Availability Zones at once and, in their words,
exceeded what our regional and multi-AZ services are designed to withstand.
The sequence, as reported by The Register, matters more than the headline:
- March: the first Bahrain Availability Zone is damaged. AWS tells customers to move their workloads to other Regions.
- April: further attacks disrupt a second Zone and the whole Region goes unavailable.
- September: AWS declares the resources that lived only there unrecoverable.
In the UAE the conclusion is partial but just as hard: Zone mec1-az2, one of three in that Region, is also unrecoverable. Two facilities in the country were hit by drones in March. For the other two Zones — mec1-az1 and mec1-az3 — AWS says work continues. It adds that most customers have been able to restart elsewhere by restoring from backups or copying whatever data was still reachable. Asked for comment by The Register, the company declined to go beyond the dashboard.
Mind that wording: most. Inside it sits the minority who couldn't.
Why it matters
The blast radius you assumed wasn't the real one
AWS has always recommended it, and it's in its global infrastructure documentation: spread your application across several Availability Zones so it survives the loss of one location. That works, and works well, for what almost always happens — a fire, a power cut, flooding, a botched bit of building maintenance. It does not work when the event is region-wide.
What I keep seeing in audits is the two things being confused. A database with a replica in another AZ, a load balancer across three Zones, and the continuity document says "high availability: yes". That is not a disaster recovery plan. It's tolerance to losing one building. The plan starts when the answer to "and if the whole Region disappears?" isn't silence.
The warning came, and it lasted weeks
This is the most useful detail in the whole story. A month passed between the first damage and the loss of the Region. AWS warned people, and most moved. Those who waited to see whether service would come back lost everything.
Which gives you one concrete task, and it isn't a technical one: write the trigger before you need it. Who decides to evacuate a Region, on what signal, and how long you wait before calling the data lost. If that decision has to be improvised under pressure, with a client on the phone, it gets delayed. It always gets delayed.
Check where your backup actually lives
In AWS almost everything is regional by default, and that gets forgotten. Worth checking with the console in front of you:
- Backups. An S3 bucket lives in a Region; so does an EBS or RDS snapshot. With no explicit cross-Region copy, your backup dies with the original.
- Encryption keys. A KMS key doesn't leave its Region. An encrypted copy landing somewhere with no usable key is a pretty, useless file.
- Image registry. ECR is regional. If your containers only live there, you have nothing to boot with at the destination.
- Your infrastructure-as-code state. The classic: the
tfstatein a bucket in the dead Region. You can deploy everything with one command, but the command doesn't know what was there. - Your own CI/CD and secrets. If the pipeline that rebuilds lives inside what you've lost, you don't rebuild.
Data residency and resilience pull in opposite directions
This is the uncomfortable part. If your regulator requires data to stay in-country, your backup is also in-country, and the event that takes out the Region takes out the backup. There's no clean technical fix: you have to decide, in writing and with the client or the legal side in the room, what gets encrypted and shipped out, what stays in, and what you accept losing. Having that conversation on record is worth more than any diagram.
What doesn't change
This is not an argument against the cloud. Your own data centre in that same city would be just as destroyed, only with nobody to help you restore on another continent within hours. Anyone using this story to sell a return to on-premises is telling a different tale.
Multi-AZ is still worth it. It covers the frequent failure, which is the one that will actually happen to you. What you can't do is call it something it isn't.
Not every workload needs active-active multi-Region. It's expensive and it complicates a lot. For plenty of systems, a plan along the lines of "we restore in another Region from backups within two days" is perfectly valid — provided you've rehearsed it once, properly, with a stopwatch. A plan without a rehearsal is an intention.
And one detail the summaries drop: AWS has not said the UAE Region is lost. It has written off one of its three Zones and work continues on the other two. The doom reading isn't accurate either.
If you fancy it, we can look at this with your account open: an afternoon is enough to find out whether your backups are where you think they are. Any questions, tell me and we'll go through it.
All the best, Vicente.