What happened
On September 15, 2026, AWS said it could not restore access to resources and data hosted exclusively in the Middle East (Bahrain) region or in the mec1-az2 availability zone of Middle East (UAE). This changed the status from a prolonged recovery effort to a confirmed permanent-loss outcome. AWS said work continues on regional resources and on zonal resources in mec1-az1 and mec1-az3. AWS did not publish a restoration date for the UAE region.
In Middle East (UAE), me-central-1, the unrecoverable scope is resources and data hosted exclusively in mec1-az2. In Middle East (Bahrain), me-south-1, AWS said damage spanned multiple availability zones and exceeded what its regional and multi-AZ services were designed to withstand. These statements do not mean every customer workload in either geography was lost; the disclosed scope turns on where data was hosted and whether recoverable copies existed elsewhere.
AWS said most customers had re-established operations in alternate regions by restoring backups, copying data that remained accessible or using alternative solutions. The cited sources did not publish the number of affected customers, the volume or classes of irrecoverable data, or a complete service-by-service impact list. Enterprise owners must therefore reconcile their own resource, replication and backup inventories rather than wait for a provider-wide customer count.
The disruption began in March 2026 after physical strikes damaged AWS infrastructure in the UAE and Bahrain, with the Bahrain region later becoming fully unavailable. Attribution posture: AWS described Iranian attacks as the cause of the infrastructure damage; no cyber threat actor is involved in the disclosed data-loss mechanism. The new enterprise fact is not an intrusion indicator but the demonstrated failure of region-local redundancy under correlated physical destruction.
Why this matters now
Availability zones reduce many infrastructure failures, but they remain part of a provider region and can share geopolitical, utility, physical-access and recovery dependencies. AWS’s determination demonstrates a correlated failure that crossed multiple zones in Bahrain. Enterprises that equated multi-AZ architecture with disaster recovery must now reassess whether their recovery design survives permanent loss of the region, its local control dependencies and any data stored only there.
The most exposed organisations are those with regulated or latency-sensitive workloads constrained to Bahrain or the UAE, single-region databases, region-local backup vaults, locally replicated object stores or recovery procedures that assume AWS can eventually restore underlying infrastructure. Dependence on a second availability zone is not enough if backup catalogues, encryption keys, identity paths, infrastructure code or recovery operators are unavailable outside the affected failure domain.
The decision for security leaders
The CISO and CTO should require application owners to separate high availability from disaster recovery in architecture records and risk reporting. A workload is not region-resilient merely because it spans availability zones. Approval should depend on a tested recovery path that remains operable after permanent loss of the source region, including the loss of local backup services, identity dependencies, encryption keys and deployment infrastructure.
Business continuity and data owners should classify any resources that cannot be reconciled or restored. That determination must connect technical evidence to business records, legal retention requirements, customer commitments and financial reporting. Where sovereignty rules limit replication, leadership must choose an explicit alternative: independent in-country media, another legally permitted region, an alternate provider or a time-bound acceptance of permanent-loss risk.
Evidence of closure
- Successful tier-one restore report from an independent region or provider.
- Architecture record showing separation of production, backup, keys and recovery control planes.
- Reconciled register identifying every restored, inaccessible and irrecoverable data set.
- Approved legal and business disposition for each irrecoverable regulated record.
The Security.io assessment
This is a cloud-resilience event caused by physical destruction, not evidence of a cyber compromise at AWS. Its importance lies in the realised consequence: a major provider has concluded that regional and multi-availability-zone mechanisms could not recover some exclusively hosted resources. The relevant control question is therefore whether the customer created and tested an independent recovery copy before the provider region became unavailable.
AWS’s statement that most customers re-established elsewhere is encouraging but cannot serve as assurance for any individual organisation. Successful migration by other customers does not prove that a specific database, object version, key, identity dependency or audit record is recoverable. Closure requires workload-level restoration evidence and an approved disposition for anything missing, rather than a generic confirmation that backups were configured.
Questions for the morning meeting
- Which critical workloads still depend on availability zones without an independently recoverable copy in another region?
- Can the organisation restore encryption keys, identity services and deployment tooling without the failed region?
- Which residency, sovereignty or contractual constraints currently prevent cross-region recovery?
- Who can declare data irrecoverable and initiate legal, customer or regulatory assessment?