AWS Bahrain Region Data Cannot Be Restored After War Damage

The Register first reported the update from AWS’s Health Dashboard, and AWS’s own status communications confirm the central point: damage in Bahrain spanned multiple Availability Zones, while the UAE incident left one specific physical zone with resources and data that AWS says it cannot make accessible again. Customers with copies in another AWS Region, independent backups, or replicated datasets have a recovery path. Customers whose only remaining copy lived in the affected footprint do not.

AWS’s wording matters. The company says it is “unable to restore access,” rather than making a technical declaration that every underlying storage device or data fragment has been permanently destroyed. But for the affected customer, that distinction offers little comfort. If the provider cannot return the data or workload to service, it is functionally lost until proven otherwise.

Bahrain’s failure crossed the Regional boundary​

AWS divides infrastructure into Regions, such as Bahrain’s me-south-1, and Availability Zones within them. The company designs services around the premise that an Availability Zone can fail while applications deployed across multiple zones remain available. AWS documentation describes each Region as having at least three Availability Zones, intended to support high-availability designs.

In Bahrain, AWS now says the damage covered multiple zones and exceeded what its regional and multi-zone services were designed to withstand. The result is more than a prolonged outage: AWS has determined it cannot restore access to resources and data that existed solely in me-south-1.

That disclosure changes the status of the Bahrain event. In April, AWS described the Region as unavailable and said recovery could take several months, while instructing customers to restore in other Regions from remote backups. The September 15 update is an endpoint for at least part of that recovery effort. Customers should no longer treat the original Bahrain environment as a delayed restoration project.

AWS says it recommended migration after the first Bahrain Availability Zone was damaged in March, and that most customers moved workloads before a second disruption made the Region unavailable in April. The company has not published a count of customers who did not migrate, an inventory of affected services, or a breakdown of which storage systems held unrecoverable customer data. Those omissions leave organizations that operated there to perform their own account-by-account assessment rather than wait for a broad service recovery notice.

UAE loss is limited to one named physical zone — but the Region remains impaired​

The UAE outcome is narrower but still consequential. AWS says it cannot re-establish access to resources and data hosted exclusively in mec1-az2, one of three Availability Zone IDs in me-central-1. It says work continues on regional resources and on zonal resources in mec1-az1 and mec1-az3.

Administrators should pay close attention to the identifier. mec1-az2 is an AWS Availability Zone ID, the stable designation of a physical AWS zone. It is not necessarily the same as the lettered zone name — such as me-central-1a — displayed in every customer account. AWS has historically mapped some lettered availability-zone names independently between accounts, meaning two organizations can see the same zone letter while referring to different physical facilities.

The immediate task is therefore to identify actual Zone IDs, not rely on application documentation that only records a lettered zone name. AWS’s describe-availability-zones command and the EC2 console’s Service Health view can show the account-specific mapping between a ZoneName and its ZoneId. A recovery review that skips that mapping risks wrongly classifying a workload as safe or lost.

The reporting around the UAE Zone also contains a material discrepancy worth flagging. The Stack reported that AWS had restored access to mec1-az2, while AWS’s Health Dashboard text, The Register’s account, and reporting by The National say the opposite: AWS cannot restore access to resources and data hosted exclusively in that zone. AWS’s own status statement is the controlling record for the service state, and teams should not make recovery decisions on the assumption that mec1-az2 has returned.

“Multi-AZ” was never a multi-Region recovery plan​

The incident exposes a distinction that frequently gets obscured in cloud architecture reviews: high availability inside one Region is not disaster recovery from loss of that Region.

A service deployed across three Availability Zones in Bahrain could tolerate the loss of one zone under the design assumptions AWS advertises. It could not necessarily survive a conflict that damages several zones, disables regional control-plane access, impairs network infrastructure, or leaves the provider unable to reconstruct service from the remaining facilities. Replication that stays inside a single Region remains exposed to a Region-wide physical event.

AWS’s own advice during the disruption was to recover from remote backups, restore into alternate Regions, and move traffic away from the affected Middle East Regions. That was not a routine availability recommendation. It was a declaration that customers needed an independently recoverable copy outside the affected geographic boundary.

For organizations that must keep data in-country because of sovereignty rules, this produces an uncomfortable operational problem. A second copy in another country may raise regulatory, contractual, or customer-residency objections; a copy kept only locally may be unavailable when it is most needed. The answer cannot be to ignore one side of that trade-off. It requires a documented decision over what data can cross borders, which encrypted backups can be stored elsewhere, who controls the encryption keys, and whether the business can operate temporarily from a non-local Region.

A recovery plan is only real if it covers the dependencies outside the database or virtual machine. Teams should check whether the following were protected outside the afflicted Region:

• Backups must include usable copies of databases, EBS volumes, object data, application configuration, secrets, certificates, infrastructure-as-code state, and identity dependencies.
• Recovery procedures must account for DNS, traffic management, CI/CD pipelines, container registries, encryption keys, observability systems, and third-party SaaS integrations that may have been tied to the failed Region.
• Runbooks must be tested with a cold start in the alternate Region, because copying backups does not prove that IAM policies, quotas, network ranges, service limits, or application licensing will allow a production restart.

What affected AWS customers should do now​

Organizations with any historical use of me-south-1 or me-central-1 should treat this as an incident-response and continuity exercise, even if production was moved months ago. The first priority is establishing whether the organization has data or resources in the categories AWS now says cannot be restored.

Start with account inventories, CloudTrail histories stored outside the affected Regions, billing exports, infrastructure-as-code repositories, backup catalogs, and configuration-management records. Identify any asset last known to reside solely in Bahrain, then match UAE assets against the relevant Zone ID rather than just an Availability Zone letter. For managed AWS services, verify where backups, snapshots, replicas, recovery points, and encryption keys were actually stored at the time of the disruption.

Next, distinguish operational recovery from data recovery. AWS says most customers have re-established operations elsewhere either by restoring backups or copying data that remained accessible. Restarting an application in another Region may satisfy immediate availability objectives while still leaving a historical dataset, audit record, customer upload collection, or transactional gap behind. Those missing records should be tracked as a business and compliance issue, not silently folded into an outage closure report.

Finally, update resilience language that promises “multi-AZ protection” without naming the disaster boundary it covers. Recovery objectives should specify whether an application can survive an Availability Zone loss, a Region loss, a cloud-provider loss, or a geopolitical event affecting several nearby facilities. Each is a different engineering and budget decision.

AWS says it will replace affected infrastructure and provide an update on restoration of services in the coming months. That may bring new capacity to Bahrain and restore more of the UAE Region, but it will not recover the resources and data AWS has already declared inaccessible. For customers that relied on a single Middle East Region, the recovery decision has already moved from infrastructure repair to the much harder question of what records exist somewhere else.