What did AWS say caused the outage?

AWS attributed it to regional conflict, in its own words. Its April 30, 2026 update on the UAE Region states the Region "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications." The equivalent Bahrain update states the Region "has suffered damage due to the conflict in the Middle East and is currently unavailable." An earlier joint update, posted March 3, 2026, attributes the physical impact more broadly to "the ongoing conflict in the Middle East." We're not adding detail AWS didn't publish beyond those statements.

What's the actual difference between multi-AZ redundancy and a backup?

Multi-AZ and regional redundancy protect availability against the failures a cloud architecture is built to tolerate. AWS described that design envelope for Amazon S3 directly: "Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone while maintaining S3's durability and availability." A backup is a different thing: a separate, restorable copy of your data stored somewhere the same event can't reach. AWS's own September 15, 2026 update on Bahrain names the gap explicitly: "The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand." When damage exceeds what the redundancy is designed to withstand, only a genuinely separate backup gets you your data back.

Were affected customers able to recover their data?

AWS says most were, without giving a number. Its September 15, 2026 UAE update states: "Since the disruption began in March, most customers have been able to re-establish their operations in other Regions by restoring backups or copying data that remained accessible." The Bahrain update from the same day says "most" customers migrated their workloads out before the Region became unavailable in April, and that AWS "supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data" — AWS's own phrasing distinguishes customers who had backups to restore from those who had to improvise. AWS never published a figure for how many customers fell into either group.

Does this apply to Microsoft 365 or Azure-hosted data the same way?

The underlying distinction — built-in redundancy versus a separate, restorable backup — applies to every cloud platform, not just AWS; it isn't an AWS-specific weakness. We haven't found an equivalent public case of Microsoft saying it cannot restore customer data hosted in a Region, so we're not claiming this specific event happened to Microsoft 365 or Azure. What we do cover is Microsoft's own published division of responsibility for Microsoft 365 data specifically, in a companion post: what Microsoft's own documentation says it backs up, and what it says is on you.

Blog · 7 min read · September 18, 2026

AWS can't restore some data: redundancy is not a backup

On September 15, 2026, Amazon Web Services told customers in its Middle East (Bahrain) Region that it can't restore access to their data. Not delayed. Not still recovering. AWS's own update, posted to the public AWS Health Dashboard, reads: The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. Five minutes later, AWS posted the equivalent finding for one Availability Zone of its Middle East (UAE) Region: we are unable to restore access to the resources and data hosted exclusively in the mec1-az2 Availability Zone.

In AWS's own words, regional and multi-AZ redundancy — the thing most cloud architectures lean on for resilience — was not enough here, and AWS says it is unable to restore access to the affected data. AWS's public Health Dashboard carries the full, timestamped log of both events, from March 1, 2026 to September 15, 2026. It's also the clearest public case study yet for a distinction IT teams argue about constantly: redundancy protects availability against the failures a system is designed to withstand. A backup is a separate, restorable copy, stored somewhere the same event can't reach. Across the 38 updates AWS posted over more than six months, its instructions to affected customers repeatedly pointed to the second thing.

The one-sentence version: On September 15, 2026, AWS said it is "unable to restore access to the resources and data hosted exclusively" in its Middle East (Bahrain) Region and in one Availability Zone of its Middle East (UAE) Region — the damage "exceeded what our regional and multi-AZ services are designed to withstand," and AWS's guidance from March 1 through April 30, 2026 was to recover from backups stored in other Regions.

What AWS actually said, in order

The incident opened as a routine-sounding power problem and ended, more than six months later, with AWS confirming it could not restore access to some of the affected data.

March 1, 2026 — AWS opens the Middle East (UAE) event, describing a "localized power issue" in a single Availability Zone (mec1-az2). Within a day, a second UAE zone (mec1-az3) is also impaired, and a related event opens for the Middle East (Bahrain) Region (mes1-az2).
March 3, 2026 — AWS attributes the physical impact to "the ongoing conflict in the Middle East" and gives customers its central instruction: We recommend customers exercise their disaster recovery plans, recover from remote backups stored in other regions, and update their applications to direct traffic away from the affected regions.
April 30, 2026 — AWS confirms the UAE Region "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications," and the Bahrain Region "has suffered damage due to the conflict in the Middle East and is currently unavailable." Both updates tell customers to restore from remote backups; "relevant billing operations are currently suspended" for each Region, with restoration "expected to take several months."
September 15, 2026 — AWS reports the outcome: it is unable to restore access to data hosted exclusively in the Bahrain Region or in the UAE's mec1-az2 Availability Zone, quoted above.

The design boundary AWS drew, in its own words

Earlier in the same incident, AWS explained exactly what multi-AZ redundancy is built to tolerate. Writing about Amazon S3 on March 2, 2026, AWS stated: Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone while maintaining S3's durability and availability. That's the design envelope. What actually happened exceeded it: by that same day, two of the UAE Region's three Availability Zones were significantly impaired at once — a scenario AWS describes as causing "high failure rates for data ingest and egress," even for a service built to survive a single AZ's total loss.

Six and a half months later, AWS's September 15, 2026 update on Bahrain names that gap directly: The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. That's the whole argument for treating redundancy and backup as two different things. Multi-AZ and multi-region architecture is built around a specific failure envelope; damage beyond it doesn't make the redundancy fail gracefully, it makes it not apply. A backup stored structurally outside that envelope — infrastructure the same event genuinely cannot reach — is a different kind of protection, and it's the one AWS kept pointing customers toward.

The honest framing: nothing here is a knock on AWS's engineering. Multi-AZ redundancy did what it's designed to do through the first Availability Zone's power loss — AWS said Amazon S3 "continued to operate normally." Once a second Availability Zone was impaired, AWS reported "high failure rates for data ingest and egress," and within days, "elevated error rates and degraded availability" across both regions; by April 30, 2026, AWS said the Bahrain Region "is currently unavailable." What changed the outcome is that the damage went further than the design envelope covers, at any provider. That's the case for a real, independently restorable backup, not a reason to single out AWS.

AWS told customers to do the one thing that actually saves you

Read the whole log and the instruction repeats with almost no variation from March 1 through April 30, 2026: recover from remote backups stored in other Regions. The September 15, 2026 updates report the outcome but contain no such recommendation. On March 2, 2026, before the scale of the damage was clear, AWS was already recommending customers "recover from remote backups into alternate AWS Regions, ideally in Europe."

AWS's September 15, 2026 update on the UAE Region reports the result, without a figure attached: Since the disruption began in March, most customers have been able to re-establish their operations in other Regions by restoring backups or copying data that remained accessible. The Bahrain update from the same day adds a distinction worth noticing in AWS's own wording: most customers migrated out before the Region became unavailable in April, and AWS says it "supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data." AWS never published a figure — but "using backups where available" and "implementing alternative solutions" are not the same outcome, and the difference is exactly whether a real backup existed.

The practical question, if you aren't in me-south-1

This event was regional, tied to conflict damage AWS describes above — it isn't a reason to expect the same thing in Seattle. What generalizes is the design lesson AWS just stated publicly: damage can exceed what regional and multi-AZ redundancy is built to withstand, at any provider. For a regulated mid-market organization, the same questions AWS's own log answers for its Middle East customers are worth asking about your own environment:

Where do your restorable copies actually live? Same region as production? Same tenant, or the same credentials an attacker or an outage could also take down?
Has a restore ever actually been tested? Not a backup job reporting success — data coming back, and an application starting from it.
Which workloads are "hosted exclusively" in one place — AWS's own phrase, above — with no independent copy anywhere else?
Does the same hold for your Microsoft 365 and Azure-hosted data? The redundancy-versus-backup distinction isn't AWS-specific. We cover Microsoft's own published division of responsibility for Microsoft 365 data specifically in Microsoft 365 backup: what Microsoft covers, and what you do.

We wrote about the adjacent "we said we're covered" versus "we can prove it" gap from the compliance side in cyber-insurance readiness for the mid-market, and from the provider-outage side in what Microsoft's own service-credit policy actually covers. A backup you haven't tested is a hope, not a plan.

Where we fit

We don't resell hardware or software. When a project needs procurement, we recommend the right products for your environment, work with the vendor of your choice on quoting, and handle install, configuration, and integration. No margin in either direction.

On the implementation side, the systems we engineer for backup and disaster recovery span Veeam, Cohesity, Rubrik, Commvault, Datto, Acronis, Druva, and Wasabi, plus Microsoft 365 Backup as a Microsoft-native option for Microsoft 365 data specifically. We don't rank them and won't tell you one is best for every environment — the right fit depends on what you're protecting, where it lives, and what failure you're actually protecting it against.

Sources

AWS Health Dashboard — public events for the Middle East (UAE) and Middle East (Bahrain) Regions

The 30-second version

On September 15, 2026, AWS said it is unable to restore access to data hosted exclusively in its Middle East (Bahrain) Region or in one Availability Zone of its Middle East (UAE) Region — in AWS's own words, the damage "exceeded what our regional and multi-AZ services are designed to withstand." The incident began March 1, 2026 as a localized power issue, later attributed by AWS to conflict damage in the Middle East. Throughout, AWS's recurring instruction was to recover from remote backups stored in other Regions — and by September, AWS reported that most customers "have been able to re-establish their operations in other Regions by restoring backups or copying data that remained accessible," with the rest supported "using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data." Multi-AZ and regional redundancy protect against the failures a cloud architecture is built to tolerate; a backup is a separate, restorable copy outside that failure envelope. If you can't say where your restorable copies live, whether a restore has been tested, and which workloads are hosted exclusively in one place — for AWS, Azure, or Microsoft 365 — that's the gap this event made public.

If you want a senior engineer to review where your backup copies actually live and whether a restore has been tested, the project intake form takes about three minutes. We'll come back with scope and a fixed-fee range.

Pro IT NW helps regulated mid-market organizations design, implement, and test backup and disaster recovery for Microsoft 365, Azure, AWS, on-premises, and hybrid environments. Vendor-neutral, labor-only. This post reflects AWS's own public Health Dashboard updates as of September 18, 2026.

Questions we get asked

Did AWS confirm it's unable to restore some customer data?: Yes, in its own words, on September 15, 2026. For the Middle East (Bahrain) Region, AWS's public Health Dashboard update states: "After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region." Five minutes later, AWS posted the equivalent finding for one Availability Zone of the Middle East (UAE) Region: "we are unable to restore access to the resources and data hosted exclusively in the mec1-az2 Availability Zone." AWS did not publish a count of how many customers or how much data was affected.
What did AWS say caused the outage?: AWS attributed it to regional conflict, in its own words. Its April 30, 2026 update on the UAE Region states the Region "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications." The equivalent Bahrain update states the Region "has suffered damage due to the conflict in the Middle East and is currently unavailable." An earlier joint update, posted March 3, 2026, attributes the physical impact more broadly to "the ongoing conflict in the Middle East." We're not adding detail AWS didn't publish beyond those statements.
What's the actual difference between multi-AZ redundancy and a backup?: Multi-AZ and regional redundancy protect availability against the failures a cloud architecture is built to tolerate. AWS described that design envelope for Amazon S3 directly: "Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone while maintaining S3's durability and availability." A backup is a different thing: a separate, restorable copy of your data stored somewhere the same event can't reach. AWS's own September 15, 2026 update on Bahrain names the gap explicitly: "The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand." When damage exceeds what the redundancy is designed to withstand, only a genuinely separate backup gets you your data back.
Were affected customers able to recover their data?: AWS says most were, without giving a number. Its September 15, 2026 UAE update states: "Since the disruption began in March, most customers have been able to re-establish their operations in other Regions by restoring backups or copying data that remained accessible." The Bahrain update from the same day says "most" customers migrated their workloads out before the Region became unavailable in April, and that AWS "supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data" — AWS's own phrasing distinguishes customers who had backups to restore from those who had to improvise. AWS never published a figure for how many customers fell into either group.
Does this apply to Microsoft 365 or Azure-hosted data the same way?: The underlying distinction — built-in redundancy versus a separate, restorable backup — applies to every cloud platform, not just AWS; it isn't an AWS-specific weakness. We haven't found an equivalent public case of Microsoft saying it cannot restore customer data hosted in a Region, so we're not claiming this specific event happened to Microsoft 365 or Azure. What we do cover is Microsoft's own published division of responsibility for Microsoft 365 data specifically, in a companion post: what Microsoft's own documentation says it backs up, and what it says is on you.
Should a mid-market business outside the Middle East care about this?: The event itself was regional, tied to physical damage AWS attributes to conflict in the Middle East, and it isn't a reason to expect the same thing in Seattle or any other region. What generalizes is the design lesson AWS stated in its own words: damage can exceed what regional and multi-AZ redundancy is built to withstand, at any provider. That's exactly why AWS's own recommendation, repeated from March 1 through April 30, 2026, was for customers to keep independent backup copies outside the infrastructure that could be affected — the same question is worth asking about every workload you run, anywhere.

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle and the Pacific Northwest, delivered USA-wide.

Share on LinkedIn Follow Pro IT NW