A backup kept in the same cloud Region as the production database can survive ordinary hardware failures and still disappear with it. AWS's outage in the United Arab Emirates made that boundary unusually plain: Amazon S3 was designed to withstand the loss of one Availability Zone, but two of the Region's three zones became impaired. Six months after the strikes, AWS says it cannot restore access to some customer data held in its Bahrain and UAE facilities, The Wall Street Journal reported.
That is the part developers should carry into their next architecture review. Multi-AZ deployment protects an application from a zone-level failure. A recoverable copy outside the Region covers a different event. The names sound similar on a diagram, and both involve replication, but AWS's own guidance draws a wider failure boundary around the second case.
Two impaired zones changed the problem
AWS opened its UAE Region in August 2022 with three Availability Zones. At launch, the company described each zone as an isolated infrastructure partition containing one or more data centers, separated far enough to reduce the chance that one event would affect the whole Region. The launch announcement told customers they could spread applications across those zones.
The March 2026 incident moved beyond the single-zone case that design addresses. AWS's public health history says two UAE facilities were directly struck by drones, leaving two of the three zones, mec1-az2 and mec1-az3, impaired. AWS also reported physical effects near a Bahrain facility, along with structural, power and water damage across the affected infrastructure.
S3 provides the cleanest view of the threshold. AWS said S3 in UAE continued operating when the first zone was powered off on March 1. Error rates rose after the second zone was impaired. The service then saw high failure rates for both data entering and leaving the Region. The same status record named elevated errors or degraded availability across EC2, DynamoDB, Lambda, Kinesis, CloudWatch, RDS and the management interfaces. A storage incident had become a regional control-plane and dependency problem.
By April 30, AWS was advising customers to move accessible resources elsewhere and restore inaccessible ones from remote backups. It said the UAE recovery would take several months. The latest disclosure goes further: AWS is unable to restore some customer data from the facilities, according to the Journal's September report. The newspaper said the announcement was the first indication that data stored only in Bahrain and UAE might be permanently lost.
One Region remains one failure boundary
AWS's own architecture guidance separates the two scopes. Its Reliability Pillar tells teams to run production workloads in at least two Availability Zones. S3 and DynamoDB distribute data across zones by default, while services such as RDS require customers to enable a Multi-AZ configuration. Self-managed storage on EBS needs a customer-managed replication plan.
Those patterns are built for zone faults. They keep an application running when a power system, network path or building group in one zone goes away. They can also support synchronous replication because zones in a Region are connected with low-latency links. The March sequence shows why that strength has a defined edge. Once two zones and regional service dependencies were impaired, the healthy-zone assumptions behind routine failover no longer described the event.
A second Region widens the physical and logical separation. AWS recommends multi-Region operation for workloads whose availability requirements exceed what one Region can provide, subject to data residency rules. It also suggests a secondary Region as a disaster-recovery site even when an application does not run active in both places. That secondary deployment can be a small pilot-light or warm-standby environment, with data and enough infrastructure copied over to start recovery.
Cost and complexity explain why every workload does not use that pattern. A second Region needs its own network configuration, compute definitions, container images, secrets and data path. Replication lag has to fit the amount of data the business can lose. The standby also has to work without calling back into a failed primary Region. AWS warns that cross-Region dependencies can weaken the design. Paying for another location is only one part of the work.
Recovery starts with a working restore
AWS Backup distributes recovery points across several zones inside a Region and advertises 99.999999999% annual durability when customers follow its documentation. The same AWS Backup resilience page presents cross-Region copying as an added protection. A highly durable regional backup still lives inside the Region whose physical loss is being considered.
AWS Backup can copy recovery points to another Region on demand or on a schedule. Its cross-Region documentation says most supported resources and Regions can use the feature, though support and copy behavior vary by service. Encryption also has to be prepared at the destination. For example, the destination vault uses its own customer-managed KMS key, and some RDS configurations need matching option groups or a copy job can fail.
A live replica and a backup answer separate recovery questions. Replication reduces the amount of recent data at risk and may allow faster failover. It can also carry an unwanted deletion or damaged record to the other side. Point-in-time recovery gives the operator an older state to return to. AWS's disaster-recovery guidance says replicated data at the recovery site also needs point-in-time backups. Teams therefore need to name both the location that can take traffic and the recovery point they would trust after a logical failure.
A completed restore is the proof. A green backup job confirms only that a copy operation finished. AWS Backup restore testing can periodically create resources from selected recovery points and record how long the jobs take. It supports services including S3, EBS, EC2, RDS and DynamoDB. That result can be compared with two business limits: the recovery point objective, which sets acceptable data loss, and the recovery time objective, which sets acceptable downtime. A backup plan that has never produced a working resource has not measured either limit.
Data residency belongs in the recovery decision
AWS's April incident guidance told customers to consider Regions in the United States, Europe or Asia Pacific as appropriate for their latency and data residency requirements. That qualification is easy to leave out of a simple multi-Region diagram. Some workloads cannot move every record to any available geography, and internal policies may narrow the options further.
The architecture decision has to record which data may cross a regional boundary, where encryption keys will exist and what can be rebuilt from source material. AWS's multi-location guidance puts that decision before implementation: teams should determine which Regions are permitted, then choose whether Multi-AZ coverage meets the workload's stated recovery needs. If no second AWS Region is allowed, the plan still needs an answer for a regional loss, such as an approved copy in another controlled location. The acceptable answer depends on the workload and its rules. Silence is also a decision, but it leaves the data exposed to the primary Region's fate.
The missing recovery details matter
The public record does not yet identify the affected customers, services, volume of data or exact storage configurations. It also does not show whether the unrestorable material lacked remote backups, whether copies were damaged with the primary data, or whether another dependency blocked recovery. The Journal report establishes that some data cannot be restored. It does not support a claim that every service or Multi-AZ configuration failed in the same way.
AWS's next useful disclosure would map the loss to services, zone placement and recovery paths, then explain which assumptions did not hold. Customers also need the eventual state of the Bahrain and UAE Regions and any changes AWS makes after the incident. Teams cannot fill those gaps themselves. They can test the boundary now with the restore process AWS documents: treat every copy inside one Region as part of the same regional failure domain, restore one recovery point outside it and time the process. If that test has never run, the architecture diagram has not proved recovery.