This content was generated with the help of AI and published without prior human review. It may contain errors and is not professional advice. Report a problem: info@delionsoft.com.
Amazon Web Services has informed customers that data and resources held exclusively in the mec1-az2 availability zone in the UAE region, or exclusively in the Bahrain region, cannot be restored. According to the original report, the damage followed the conflict with Iran, and in Bahrain it spanned multiple availability zones — beyond what regional and multi-AZ services are designed to absorb. Work continues on regional resources and on the other affected UAE zones.
What happened
AWS published a status update covering Middle East (UAE) me-central-1 and Middle East (Bahrain) me-south-1. For the UAE, the unrecoverable scope is limited to one availability zone; recovery efforts continue for mec1-az1 and mec1-az3 and for regional resources. For Bahrain, the assessment covers the whole region.
The original report notes that InfoQ covered drone strikes on three AWS data centres across the two regions in March, that AWS then advised customers to replicate critical data elsewhere and later to move workloads out of the Middle East, and that a second attack on Bahrain was claimed in July. AWS says it is replacing infrastructure, has notified authorities, and will share more on Bahrain in early 2027.
The discussion that followed focused less on the strikes than on expectations. Multi-AZ designs spread a workload across facilities within roughly 100 kilometres — enough for power failures, storms or earthquakes, not for an adversary who can reach several sites the same night. S3's eleven-nines durability figure is a regional property, and AWS disaster recovery guidance has long said backups should be copied to a second region.
Why it matters
For a small or mid-sized company, the operative word in the AWS statement is "exclusively". If every copy of a dataset lives in one region, the provider's redundancy guarantees stop at that region's boundary. That is not a hidden term; it is in the shared responsibility model. But it is easy to lose in a procurement conversation where "we run on AWS" is treated as a resilience answer rather than a toolbox choice.
There is a harder case underneath. Some teams could not have replicated abroad, because data residency rules keep information inside national borders. Encrypted off-shore backups do not fully resolve this, since the keys would also need to sit outside the jurisdiction to be usable after a regional loss. Where the law forbids a copy leaving, the exposure is a constraint to record in the risk register, not a gap an architect can close.
What to do
- Produce a plain list of datasets and stateful services that exist in exactly one region today, including snapshots, object storage, managed database backups and anything created by engineers outside infrastructure-as-code.
- For each item, check whether a cross-region or off-provider copy is legally permitted. Record the answer and its source, not an assumption.
- Test a restore from a copy in another region at least once. An untested replica is a hypothesis.
- Where residency blocks replication, document the accepted loss scenario in writing and get it acknowledged by whoever owns the business risk — a decision recorded is better than a surprise discovered.
Geographic risk is not tied to a single provider. The question is narrower: what have you got with no second copy anywhere, and can you legally make one.