"We take backups" is an easy answer, but "Are those backups somewhere other than production?" is often harder to answer right away, because they may sit with the same provider, in the same region, in the building next door.
On September 15, 2026, AWS announced in an update to its service health page (AWS Health Dashboard) that it cannot restore access to data and resources stored only within parts of the Middle East. The affected scope is the entire Bahrain Region and one of the three Availability Zones in the UAE Region (mec1-az2).
After six months, judged unrecoverable
It began with drone strikes in the Middle East in March 2026. According to AWS, two facilities in the UAE were directly struck, while in Bahrain a strike close to one facility caused physical damage to its infrastructure. AWS says there was structural damage and disrupted power, as well as water damage from fire suppression. After about six months of recovery work, the conclusion for part of it is that it cannot be restored.
According to AWS, the damage in Bahrain spanned multiple Availability Zones and exceeded what its regional and multi-AZ services were designed to withstand. AWS says it began recommending migration to other regions when the first zone was damaged in March, and that most customers had migrated before a second zone was disrupted in April and the whole region became unavailable. For the UAE, AWS says it is continuing to recover regional resources and those in the other two zones. The April 30 updates announced that relevant billing operations in both regions were suspended.
What weighs most is where the line is drawn: what will not come back is data and resources that were "stored only in that scope." Whether you also had copies in another region or zone translates directly into the difference in outcome.
What "spread across multiple zones" protects
When describing cloud architectures, people often say you're safe if you spread across multiple Availability Zones. That design assumes a failure on the scale of one zone (a group of one or more data centers) becoming unavailable, and within that scope it is indeed effective.
This case shows that there is territory outside that assumption. If you want to cover an entire region becoming unavailable at once, you either keep copies in another region or split across providers altogether. How far to prepare depends on how much the business suffers when things stop; it is not decided by technology alone.
We also cover designing on the assumption that things will stop in how to present your site when an external service goes down.
Only three things to check
Before redrawing your architecture diagram, look into the following three things. Each can be confirmed from your current settings and records.
| What to verify | Inspection area |
|---|---|
| Which region your production data physically lives in | The settings screen of the service you use; the region shown there |
| Whether backups are in a different region | The storage destination settings. If it is the same region as production, both can be lost at once |
| Whether you can actually restore | Records of your most recent restore test. A success notification is not proof that you can restore |
The third is the one most easily skipped, yet it matters most when damage occurs. The difference between a job succeeding and being able to resume business from it is covered in measuring backup restorability in stages.
Data you entrust to SaaS is in scope too. Think separately about what the provider retains and what you should export and keep yourself. A breakdown using Google Workspace as an example is in how much of your entrusted data to protect yourself.
Two questions to ask your outsourcing partner
If you outsource operations, you may not be able to check the three items above yourself. In that case, two questions are enough.
One is "Are backups stored in the same region as production, or a different one?" The other is "When did you last test a restore, and how much could you bring back?" If neither gets an answer, restore verification may not be within the scope of your contract.
The scope of maintenance is determined by what the contract says, so rather than seeking verbal reassurance, it moves faster to turn the conversation to what to add at the next renewal.
Don't duplicate everything
Replicating every system to another region brings costs close to double. The realistic approach is to separate what only hurts for as long as it is down from what would stop your business if its data disappeared.
Put only what cannot be recovered once lost, such as internal shared files and accounting data, in another region. If processing stops but can be rebuilt later, give it lower priority. With this distinction made up front, whether to widen the scope of preparation can be handled as a budget decision.
On September 24, 2026, we checked the public information on the AWS Health Dashboard for the Bahrain and UAE regions (the March, April 30 and September 15 updates) and AWS's official materials on Availability Zone and Region design. We have not checked the scope of impact on any specific account. When assessing the impact on your company, check the notifications from your provider and official information.
For reviewing your cloud architecture or checking your recovery procedures, please consult GleamHub.
