English
English

Blogpost // Cross-Industry

Now they're gone

Blogpost // Cross-Industry

Now they're gone

What the AWS Bahrain Region Failure Teaches Companies About Cloud Resilience and Data Sovereignty

Download PDF

Our 3 Key Take-away's

Naively putting data in the cloud with a multi-AZ architecture does not protect you from disaster: availability zones survive a single data center failing, not the loss of an entire region like Bahrain.

Critical systems need a tested, multi-level backup strategy (including SaaS), because whether you lose only time or your actual data is decided in the architecture, long before any disaster.

Resilience and data sovereignty pull in opposite directions, and a single-region "sovereign" cloud is a trade-off you must make consciously, not assume away.

As of September 15, 2026, it is final. In an update to its Health Dashboard, Amazon confirmed that access to resources and data in the Bahrain cloud region (me-south-1) - which were hosted exclusively there - can no longer be restored.

This means that data whose only copy was in Bahrain is permanently lost. Those who had replicated data across regions or kept backups in another cloud region or outside the cloud lost time, but not data.

The Bahrain (me-south-1) region consisted of three availability zones. In March 2026, drone attacks struck two data centers in the UAE and damaged a facility in Bahrain, prompting AWS to urge customers to activate their disaster recovery plans and reroute traffic. After the first zone was damaged, AWS advised moving workloads to other regions, and most customers migrated before damage to a second zone in April rendered the entire region unusable.

This brings the issue of redundancy and data security in cloud usage back into the spotlight. Many companies rely on the principle that data and resources in the cloud are “secure” as long as they are distributed across multiple availability zones. The incident in Bahrain dramatically demonstrates that this is not the case and clearly illustrates that availability and disaster recovery capabilities are two distinct things.

Availability zones are designed to withstand the failure of resources in a single data center and to quickly restore the corresponding services. Availability zones are often located close to one another to enable, for example, synchronous replication with latency in the single-digit millisecond range. However, this does not protect against large-scale disasters or infrastructure failures - and certainly not against coordinated attacks on data center infrastructure, as seen in Bahrain. Consequently, the Federal Office for Information Security (BSI) typically stipulates a minimum distance of 200 km between data centers to ensure geographic redundancy.

Companies should therefore make it a priority in their data center or cloud strategy to define how they intend to meet the requirements for high availability and disaster recovery, depending on the criticality of the application and data. Possible solutions include shifting workloads and data to other cloud regions or maintaining backups of data in distant data centers (if necessary, even outside the infrastructure of a cloud provider or hyperscaler).

For many companies, this presents a dilemma between resilience on the one hand and sovereignty and GDPR compliance on the other: Resilience means replicating your data to a second, geographically distant region. The regulatory and contractual reality is often that data must not leave the EU - sometimes not even the country - and, in a sovereignty context, it must not even come within the reach of U.S.-controlled operators.

This is illustrated by the AWS European Sovereign Cloud, which currently consists of several availability zones within a single geographic region in Brandenburg. An expansion into other local zones is planned but has not yet been implemented. Therefore, true cross-region disaster recovery within the sovereign AWS cloud is not possible.

Those who want true geo-redundancy must either wait for a second sovereign region or store copies in a standard EU region such as Frankfurt or Ireland, thereby compromising some of the sovereignty promises.

One workaround could be to encrypt the data in the non-sovereign cloud using a customer-owned key and manage that key outside the hyperscaler’s infrastructure. The possibility of storing backups at other locations should also be explored. That way, in the still unlikely scenario of a total failure of a cloud region, one would at least lose only time and only a limited amount of data.

Therefore, developing a comprehensive availability and disaster recovery strategy for critical applications is essential. At a minimum, three levels should be taken into account. The first level is redundancy within the application itself, which mitigates individual hardware failures before any data is lost. The second is the traditional local backup of databases and file storage, which allows application or administrative errors to be rolled back quickly; for critical infrastructures, this should be already geographically redundant. The third is an external copy, depending on requirements, located at a significantly distant site, with a different provider, and, if necessary, on a different medium.

This third level provides protection against an actual disaster scenario. Here, compromises regarding RPO (maximum data loss) and RTO (time to recovery) are likely unavoidable, raising the question of the cost-benefit ratio: What level of damage is still acceptable from a business perspective? Critical applications must therefore be designed with disaster scenarios in mind from the outset, and this depends not only on the infrastructure but also, to a significant extent, on the capabilities of the application itself.

In particular, SaaS applications (such as Office products used as cloud services) must also be considered here. For these applications, there is often little information available about their operation and the underlying data backup, and users must rely on contractual commitments, if any exist.

Companies should therefore regularly conduct a risk assessment of their applications and data regarding disaster scenarios and develop a data backup and recovery strategy based on the results. This assessment should also consider failure scenarios that have been considered unlikely until now. The strategy must be reviewed regularly, and data recovery must be tested.

In Bahrain, the cloud delivered what it promised: protection against the failure of a single data center. It did not deliver what many tacitly assumed it would: protection against the loss of the region itself. Whether a company ultimately loses only time or its data is not decided at the moment of the disaster, but long before, in the architecture. The real question, therefore, is not whether something like this will happen again, but whether one’s own environment would survive the permanent loss of an entire region. Anyone who hesitates when asked this question already knows the answer.

About the author(s)

3d avatar

Senior Expert Advisor

Carsten Wedekind

PhD in atmospheric physics with 30+ years of expertise in IT architectures and engineering solutions; special focus on financial services and manufacturing industries. Former professional work at SAP, CORE and EPAM.

3d avatar

3d avatar

Meet Amaranth

Is increasing tech complexity a challenge?

Let's discuss how we can help your organization navigate complexity and achieve lasting success.

Meet Amaranth

Is increasing tech complexity a challenge?

Let's discuss how we can help your organization navigate complexity and achieve lasting success.

Meet Amaranth

Is increasing tech complexity a challenge?

Let's discuss how we can help your organization navigate complexity and achieve lasting success.