AWS Bahrain outage exposes limits of multi-az cloud resilience

The disruption began in March during the Iran war. Reuters reported that two AWS facilities in the UAE were struck, while a drone strike close to a facility in Bahrain damaged AWS infrastructure. Some banking operations were affected at the time.

AWS said the scale of the damage ultimately exceeded the resilience its regional architecture was designed to provide.

“The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand,” said the company in a status update.

The incident has demonstrated an important boundary in cloud resilience: distributing workloads across Availability Zones can protect against failures within a Region, but does not necessarily protect against physical disruption severe enough to affect multiple zones.

AWS Advised Customers to Move Workloads

After the first Availability Zone was damaged in March, AWS advised customers to migrate workloads to other Regions. Most had done so before disruption to a second Availability Zone in April made the Bahrain Region unavailable.

AWS said it has since supported remaining customers in re-establishing operations in alternative Regions, using backups where available or implementing other measures to mitigate the impact of inaccessible data.

In parallel, the company assessed the affected infrastructure and explored options for restoring data and resources that had not been migrated before the Region became unavailable.

AWS has now said those options have been exhausted.

The company added that it remains committed to supporting customers in Bahrain over the longer term and expects to provide another update in early 2027.

Where Regional Resilience Ends

The incident highlights a distinction for organisations designing cloud resilience.

Multiple Availability Zones provide a way to distribute workloads within a Region. In Bahrain, however, physical damage affected multiple zones and created circumstances that AWS said its regional and multi-AZ services were not designed to withstand.

For enterprises, that puts greater emphasis on understanding which failure scenarios their architecture actually covers. Workloads distributed across several Availability Zones can still share dependence on the wider Region in which those zones operate.

The sequence of events in Bahrain also shows the role of planning beyond that regional boundary. Customers that migrated after the initial March disruption were in a different position when a second Availability Zone was affected the following month.

Sovereignty and Resilience Are Different Questions

The disruption has also prompted questions about where critical compute is located and who controls it.

Mark Boost, CEO of Civo, argued that the incident should encourage UK organisations to examine their reliance on infrastructure operating outside their jurisdiction.

“Amazon has spent six months trying to bring its sites back and has now informed its customers that it cannot. That is not a criticism of Amazon,” he said. “It is simply what happens when critical infrastructure resides in foreign territories.”

He argued that sovereign AI requires the compute on which a country depends to be built and owned domestically, rather than treating sovereignty primarily as a question of data residency.

The Bahrain incident does not establish that domestically owned infrastructure would be more resilient to physical disruption. Sovereignty and resilience address different dependencies.

Where infrastructure is located and owned can affect jurisdiction and control. Resilience also depends on how workloads, data, backups, and recovery arrangements are distributed.

AWS’s experience in Bahrain has shown that even hyperscale infrastructure has a failure boundary. For organisations dependent on cloud services, the practical consideration is where that boundary sits and whether their recovery plans extend beyond it.