AWS lost Bahrain for good: your Azure region-loss plan

On 15 September 2026, AWS told customers it cannot restore access to resources and data hosted exclusively in its Middle East (Bahrain) region, and that data hosted only in one of the three Availability Zones of its UAE region, mec1-az2, is also beyond recovery. The cause was physical: Iranian missile and drone strikes that began in March. In AWS's own words on its status page, "the damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand."

Read the key phrase again: hosted exclusively in this Region. Customers with a copy somewhere else still have their data. Customers who relied on multi-AZ deployment as their protection do not. Azure is built on the same regional model, and many Swedish and EU organisations have deliberately configured their estates to keep every byte inside one region for data residency reasons. This is the week to check whether that choice was a residency decision or an accidental single point of failure.

What happened, in order

The sequence, as reported by Reuters from AWS's status updates:

• March 2026. Following US and Israeli attacks on Iran, Iran retaliated with missiles and drones against Israel and Gulf states hosting US bases. Two AWS facilities in the UAE were struck directly, and a facility in Bahrain was damaged by a nearby drone strike. Reporting at the time described structural damage, power disruption, fire, and water damage from fire suppression.
• After the March damage. AWS recommended that customers migrate workloads to other regions. According to the Reuters report, most customers did so before Bahrain became unavailable.
• April 2026. A second Availability Zone in Bahrain was disrupted, and the region became unavailable.
• 15 September 2026. AWS said it had exhausted recovery options for Bahrain data that was not migrated, and that resources in mec1-az2 are unrecoverable while recovery continues across the rest of the UAE region. AWS expects to update on the UAE in the coming months and on Bahrain in early 2027.

AWS has not said how much data was lost or how many customers were affected. Nobody outside AWS knows that number yet, so treat any figure you see quoted with suspicion.

Why multi-AZ did not save anyone

Availability Zones were designed for a specific threat: a failure in one facility. AWS describes its zones as "physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other." Microsoft's wording for Azure is almost identical: zones "are typically separated by several kilometers, and usually are within 100 kilometers of each other."

That distance protects you against a power failure, a flood in one building, or a fire. It does not protect you against a sustained campaign that can reach every building within a 100 km circle. Microsoft is explicit about this in the Azure reliability documentation: "Availability zones don't protect against a full-region outage."

There is a second, less obvious lesson. Zone-redundant replication is synchronous, which is exactly what you want for availability and exactly what hurts when the region itself goes. Azure's storage documentation says so in plain terms: ZRS "might not fully protect your data against a regional disaster where multiple zones are permanently affected." The same documentation notes that LRS replicas all reflect the same current state, so "redundancy protects against hardware failure, not against data-modifying operations." Replication and backup solve different problems. A plan that treats them as interchangeable has a gap in it.

The Azure equivalents: what survives a lost region

Map the Bahrain scenario onto Azure and ask one question per service: if the primary region never comes back, where is the most recent usable copy?

Storage accounts: GZRS, and the failover fine print

GZRS writes synchronously across three or more zones in the primary region and asynchronously to the paired secondary region. Microsoft recommends it "for applications that require high consistency, durability, availability, and resilience for disaster recovery." Because geo-replication is asynchronous, a sudden regional loss means losing whatever had not replicated yet. The storage account's Last Sync Time property tells you where that line sits. For block blobs, Microsoft now offers Geo priority replication, which it says keeps the RPO at or below 15 minutes.

Three details matter when you write the runbook:

• Do not wait for Microsoft. Microsoft-managed failover exists, but the storage documentation says in bold: "Do not rely on Microsoft-managed failover, which might only be used in extreme circumstances." The region-pairs page adds that it is "only performed in catastrophic situations and after repeated failed recovery attempts." Plan for customer-managed failover.
• Unplanned failover costs you your geo copy. After a customer-managed unplanned failover the account is converted to LRS in the new primary region and geo-redundancy is lost until you re-enable it. Re-replicating to a new secondary is billed, and archived blobs must be rehydrated first.
• The control plane stays behind. The Azure Storage resource provider does not fail over. If the primary region is unavailable, you cannot perform management operations on the account, even though data access works from the new primary.

Azure SQL Database: the residency policy trap

New Azure SQL databases store backups on geo-redundant storage by default, which is what makes geo-restore possible. Geo-restore "creates a new database on any existing server in any Azure region."

The trap is a built-in Azure Policy called "Azure SQL DB should avoid using GRS backup", which Microsoft documents specifically for organisations with data residency requirements. Assign it, and every database in scope keeps backups on LRS or ZRS. Microsoft's warning on the same page is unambiguous: "Geo-restore is disabled as soon as a database is updated to use locally redundant or zone-redundant storage." An estate that combined that policy with a single-region deployment is structurally in the same position as the Bahrain customers who never migrated. Also note that changing redundancy on an existing database only affects future backups, and can take up to 48 hours to apply. Hyperscale databases can only set backup redundancy at creation.

Azure Backup: decide before the first backup runs

Recovery Services vaults default to GRS, but the redundancy setting locks once you configure a backup. Microsoft's note: "Be sure to change the storage replication type for a Recovery Services vault before you configure a backup in the vault. After you configure a backup, the option to modify is disabled." Moving an existing vault means creating a new one and re-protecting workloads.

Cross Region Restore (CRR) is what lets you restore into the paired region on your own schedule, with or without a declared outage. It requires a GRS vault, carries extra charges, takes up to 48 hours before items appear in the secondary region, and "currently can't be reverted to GRS or LRS after the protection starts for the first time." For Azure VM backups, Microsoft states the secondary-region RPO "can be up to 36 hours in the worst case": up to 24 hours from the Standard policy plus up to 12 hours of replication. If 36 hours of lost transactions is unacceptable for a system, VM backup with CRR cannot be its only cross-region protection; that system needs application-level replication such as SQL failover groups.

Consider immutable vaults as well. Physical destruction and ransomware are different threats, but both punish the same weakness: every recoverable copy living inside one blast radius.

The cost math: Sweden Central, 10 TB of hot blob data

The usual objection to geo-redundancy is cost. Here are Azure retail list prices for General Purpose v2 hot block blob storage in Sweden Central, first tier (up to 50 TB), in EUR per GB per month, taken from the Azure Retail Prices API on 17 September 2026. The monthly figure assumes 10,240 GB stored and excludes transactions.

Moving 10 TB from ZRS to GZRS costs roughly €203 a month, or about €2,430 a year at list price. Write operations cost more too: the same price list shows hot-tier writes at €0.0537 per 10,000 on ZRS against €0.1009 on GZRS, so write-heavy accounts should be modelled on actual transaction counts rather than capacity alone. Negotiated discounts will change the absolute figures but rarely the ratio.

That does not mean every account should move to GZRS. Doubling the storage bill across an entire estate to protect scratch data and rebuildable caches is waste. The work is classification: decide which data would end the business if it vanished, pay the geo premium for that, and accept LRS or ZRS for the rest with your eyes open.

Find your single-region data in ten minutes

Azure Resource Graph answers the inventory question across every subscription you can read. Start with storage accounts that have no geo copy:

az graph query -q "
Resources
| where type =~ 'microsoft.storage/storageaccounts'
| extend sku = tostring(sku.name)
| where sku !contains 'GRS' and sku !contains 'GZRS'
| project subscriptionId, resourceGroup, name, location, sku
| order by location asc" --first 1000

Then Azure SQL databases whose backups cannot be geo-restored:

az graph query -q "
Resources
| where type =~ 'microsoft.sql/servers/databases'
| where name != 'master'
| extend backupRedundancy = tostring(properties.currentBackupStorageRedundancy)
| where backupRedundancy !in ('Geo', 'GeoZone')
| project subscriptionId, resourceGroup, name, location, backupRedundancy" --first 1000

And Recovery Services vaults, with their redundancy and Cross Region Restore state:

az graph query -q "
Resources
| where type =~ 'microsoft.recoveryservices/vaults'
| extend redundancy = tostring(properties.redundancySettings.standardTierStorageRedundancy),
         crr = tostring(properties.redundancySettings.crossRegionRestore)
| project subscriptionId, resourceGroup, name, location, redundancy, crr" --first 1000

The output is not a to-do list on its own. A dev storage account on LRS is fine. A production database holding customer contracts on ZRS backups, in a subscription governed by a no-GRS policy, is the row that should reach your risk owner this week.

The Swedish and EU angle

Data residency does not require a single region

HN commenters discussing the AWS news pointed at Gulf data localisation rules as one reason some customers had no copy elsewhere. Swedish organisations face a softer version of the same pressure: procurement clauses, internal policy, and cautious readings of GDPR transfer rules that translate into "keep it in Sweden Central".

Sweden Central, physically located in Gävle, supports availability zones and is paired with Sweden South. GRS and GZRS replicate to that pair, and Microsoft notes that "almost all regions reside within the same geography as their pair." Staying inside Sweden and surviving the loss of a region are compatible goals. The same holds for Norway East with Norway West, Germany West Central with Germany North, and Switzerland North with Switzerland West. If your constraint is EU rather than national residency, North Europe and West Europe are paired with each other. Denmark East, Poland Central, Italy North, Spain Central, Austria East and Belgium Central have no pair, so any geo copy from those regions has to be designed deliberately to another region.

Request Sweden South access now, not during an incident

Sweden South, Norway West, Germany North and Switzerland West are restricted-access regions, which Microsoft describes as reserved "to support specific customer scenarios, such as disaster recovery within a specific geographic area." Storage replication into the pair does not depend on you having access. Deploying compute there does. That matters for Cross Region Restore of VMs, where the staging storage account must sit in the vault's secondary region.

Access is granted through a support request (Service and subscription limits, quota type "Other Requests") that Azure engineering validates. You do not want that ticket in a queue on the day your primary region is dark alongside every other customer's. File it now for the subscriptions that would host your recovery environment, and run a restore drill once access lands.

NIS2 and DORA already ask for this

Sweden's Cybersäkerhetslag (SFS 2025:1506), which implements NIS2, entered into force on 15 January 2026. NIS2 Article 21(2) requires risk-management measures "based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems," including "business continuity, such as backup management and disaster recovery, and crisis management." An all-hazards approach that never considered losing a whole cloud region is difficult to defend after this week.

For financial entities, DORA Article 12 goes further on restoration: when restoring backup data using their own systems, entities "shall use ICT systems that are physically and logically segregated from the source ICT system." For central securities depositories, the secondary processing site must be "located at a geographical distance from the primary processing site to ensure that it bears a distinct risk profile." A backup that lives in the same regional blast radius as the system it protects fits poorly with either text.

A region-loss checklist for Azure teams

1. Run the three Resource Graph queries above and export the results.
2. Classify each hit as rebuildable, important, or critical. Only the last two need a geo copy.
3. Review residency policies. If "Azure SQL DB should avoid using GRS backup" or a similar deny policy is assigned, confirm with legal whether the requirement really names a single region or only a country or the EU.
4. Convert critical storage to GZRS (or RA-GZRS where read access during an outage matters) and record the Last Sync Time monitoring in your runbook.
5. Switch production SQL backups to Geo or GeoZone, remembering the change only protects future backups.
6. Create new GRS vaults with Cross Region Restore for critical workloads before re-protecting them, since existing vault redundancy is locked.
7. Request access to your restricted pair region for the recovery subscriptions.
8. Drill it. Run a customer-managed planned failover on a test storage account and a Cross Region Restore of one VM. Time both, and write down every permission, quota and network gap you hit.

Bahrain customers had weeks of warning between AWS's March advice to migrate and the April loss of the region. Most Azure customers will get no warning at all. Put a copy of every critical dataset outside the region it runs in, and prove you can restore it, while doing so is still a routine change ticket.