On September 15, 2026, Amazon Web Services (AWS) announced that it cannot restore access to data stored only in the Bahrain Region and in part of the United Arab Emirates (UAE), where facilities were damaged in the war. The outage, which began with drone attacks in March, is no longer something some customers can simply wait out until the facilities are repaired. AWS is helping customers resume operations in other regions, but success depends on what they kept outside the affected locations. Getting from a copy in another region to a working business involves several conditions, including how far the data was replicated and whether the encryption keys are available.

AD

What can't be recovered, and what is still being restored

The scope in AWS's September 15 update differs between Bahrain and the UAE. In Bahrain, it covers data and resources stored only in the Region. In the UAE, it covers data and resources stored only in one Availability Zone (AZ), "mec1-az2." A Region is a geographic area where AWS provides services, and each contains multiple AZs with separate power, cooling and networking.

Target Scope AWS says it cannot restore access to Ongoing work and next update
Bahrain (me-south-1) Data and resources stored only in the Region Helping customers resume operations in other regions. Next report in early 2027
mec1-az2 in the UAE (me-central-1) Data and resources stored only in this AZ Replacing damaged infrastructure; an update on service restoration is expected within the next few months
mec1-az1 and mec1-az3 in the UAE, and Region-wide resources Described separately from the unrecoverable finding Recovery work continues

Source: AWS Health's September 15, 2026 announcement on Bahrain and the UAE. The planned updates are not a promise of when services will resume.

The qualifier common to both announcements is stored only there. It does not mean that backups kept elsewhere were lost. AWS says many customers in the UAE resumed operations in other regions by restoring backups or copying data that remained accessible.

Bahrain also saw damage unfold over time. When the first AZ was damaged in March, AWS urged customers to migrate, and many did so before a failure in another AZ in April made the entire Region unavailable. AWS then exhausted its options for recovering the data and resources that had not been moved, and concluded it cannot restore access.

So "early 2027" should not be read as a date when Bahrain's data will return. Rebuilding facilities is a different task from regaining lost access. Recovery work also continues in the other UAE AZs, so it cannot be said across the board that spreading workloads over multiple AZs avoided the damage.

What multi-AZ protects, based on this sequence of events

When the first AZ in the UAE went down, Amazon S3 kept running. In its March 2 incident description, AWS wrote that S3 is designed to maintain durability and availability even after losing a single AZ entirely, and that it operated normally after the March 1 power outage in mec1-az2. Errors rose only after a second AZ also failed.

The physical damage was not of one kind either. As of March 2, AWS reported direct drone strikes on two facilities in the UAE and an attack near one facility in Bahrain. Along with structural damage and power interruptions, firefighting caused water damage in some places. An AZ is a unit that isolates services, so the number of facilities reported cannot be equated with the number of AZs.

This sequence does not negate multi-AZ wholesale. A design may absorb the first failure, but when damage compounds in the same area, it exceeds what the design can withstand. In its September announcement on Bahrain, AWS itself acknowledged that the damage spanned multiple AZs and exceeded the design assumptions for services running within a Region or across multiple AZs.

AWS's disaster recovery guidance likewise separates preparing for fire, flood and major power outages using multiple AZs in one Region from preparing for events that make it impossible to run workloads within a Region. Covering the latter calls for a multi-Region recovery strategy. Adding AZs is not a substitute for having a recovery site outside the area.

AD

Conditions for making a copy in another region "recoverable"

With S3, adding a replication configuration does not automatically replicate data that existed before it. According to the official guide, standard live replication covers new or updated objects written after the configuration. To move existing data, you use S3 Batch Replication. A record that cross-Region replication was enabled does not show whether data accumulated over the years is all present at the destination.

To recover in another region, you need to confirm not just copies of the necessary data but also decryption permissions, the configuration that runs the application, and the conditions at the destination.

Classifying AWS's design documents by what to verify at recovery time gives the following.

What to check Condition in AWS documentation What to verify in a recovery test
Data scope (S3) Live replication does not retroactively replicate objects that existed before configuration Whether data needed from earlier also exists at the recovery site and can be read. S3 guide
Decryption (AWS KMS) Multi-Region keys are not replicated automatically; key policies and similar settings are managed in each Region Whether the keys used at the recovery site can be used with actual operating permissions. KMS guide
Runtime environment Recovery from backups requires creating infrastructure, deploying code and restoring data; even a running standby needs secured capacity Whether the application starts and can handle the required load. Recovery strategies
Destination Check service availability, latency and data residency requirements Whether the recovery procedure can run in a location that meets business and data requirements. Choosing a recovery site

The conditions for data, decryption, runtime environment and destination were classified from AWS documents checked on September 19, 2026. This is not a table of affected customers' configurations or of the individual causes of data that could not be recovered. Conditions specific to S3 or KMS need to be checked in the relevant service.

An encrypted copy becomes usable for business only once it can be decrypted at the recovery site. AWS KMS multi-Region keys let different regions use the same key material, but the user chooses the regions to replicate to and manages each key's policies and permissions. AWS does not automatically distribute keys to the places they are needed.

That does not mean every recovery design should adopt multi-Region keys. S3 cross-Region replication re-encrypts data keys with the destination's KMS key, even when related multi-Region keys are used on both sides. What to check is not the name of the key but which key the service in use relies on, and whether the data can be read with the permissions available at the recovery site.

Data replication also serves a different role from backups that can roll back to a known-good point in time. AWS notes that continuous replication alone may not handle data corruption or destruction, and recommends also having versioning and point-in-time restore. Geographic separation and the ability to go back in time need to be verified separately.

Recovery tests should confirm business can resume without returning to the original region

With the approach of rebuilding an environment from backups, recovery involves preparing infrastructure, deploying code and restoring data. With a standby approach that keeps a small system running in another region at all times, you can scale up an already running environment and take over. AWS asks customers to choose among such approaches by balancing acceptable downtime and data loss against cost and operational complexity.

For companies in Japan that use AWS, the unit of review can be more concrete than a "backup exists" setting. Test the whole path: restore the data needed from the past at the recovery site, read it with local keys and operating permissions, and run business processing in the application. If steps remain that create resources or change settings in the original Region, also confirm that such dependencies don't block recovery.

AWS's guidance on choosing a recovery site calls for documenting the dependencies of the recovery path and validating objectives through exercises. The objectives include RTO, the time allowed to recover, and RPO, the point in time up to which data is recovered. Even if a copy exists far away, it cannot serve as a recovery site if the services needed are unavailable there or if residency requirements cannot be met.

AWS's future updates on the UAE and its early 2027 report on Bahrain will be material for judging the fate of the local facilities. In the meantime, companies can run recovery tests on the assumption that the original region does not come back. Only after confirming that the necessary data can be decrypted and that business resumes within the target time can a copy in another region be judged a real business continuity measure.