TL;DR: A March 2026 drone strike on AWS data centres in the UAE knocked out regional services, exposed the limits of Multi-AZ resilience, and forced Securiti customers toward governed cross-cloud recovery, according to Securiti. The core lesson is that continuity now depends on pre-approved data portability, compliance-aware failover, and live data intelligence, not redundancy alone.
At a glance
What this is: This is an analysis of how the AWS UAE outage exposed the limits of Multi-AZ resilience when a regional event, not a single facility failure, took cloud services offline.
Why it matters: It matters because resilience plans that stop at zone-level redundancy can still fail when regulatory constraints, data locality, and recovery dependencies prevent rapid cross-region restoration.
Context
Multi-AZ architecture is designed to survive a facility outage, not the collapse of an entire cloud region. When the outage is driven by physical damage, degraded storage services, and regulatory limits on where data can move, the usual disaster recovery playbook can fail even when the infrastructure itself is highly available.
For identity, data, and security teams, the real issue is not availability alone but governed recovery. Cross-cloud continuity depends on knowing where sensitive data lives, which replicas are legally usable, and which failover paths are already approved before an incident begins.
Key questions
Q: What fails when Multi-AZ is used as the only disaster recovery strategy?
A: Multi-AZ fails when the disruption spans the whole region, because the architecture assumes one zone can be lost while the region still functions. If shared storage, networking, or control-plane services degrade together, the standby zone may be just as unreachable as the primary workload. Teams need a separate regional recovery design, not just zone redundancy.
Q: When does compliance become the limiting factor in cloud recovery?
A: Compliance becomes the limiting factor when regulated data cannot be moved automatically to another region or cloud. In that case, availability and lawful processing pull in opposite directions, and the recovery plan must already define where data may go, who can approve it, and how the transfer is documented. Without that preparation, the outage becomes a governance delay as well as a technical one.
Q: What are the signs that a backup strategy is not truly independent?
A: A backup strategy is not independent when restore paths rely on the same regional storage, services, or network fabric as the primary environment. If snapshots disappear when the region degrades, the backup is part of the same failure domain. The practical test is whether you can restore after a regional outage without first reviving the region that failed.
Q: How should teams balance resilience with data sovereignty requirements?
A: Teams should balance them by pre-classifying data, defining approved recovery geographies, and rehearsing migrations that comply with local rules. The right question is not whether data can be moved quickly, but whether it can be moved legally and with clear accountability. If those decisions are left until an outage, recovery slows and compliance risk rises together.
Technical breakdown
Why Multi-AZ stops at the region boundary
Multi-AZ spreads workloads across multiple Availability Zones within one cloud region, which reduces the chance that a single facility failure will interrupt service. The model assumes the region remains operational enough for traffic routing, storage access, and replica coordination to continue. Once the disruption spans multiple data centres, shared regional services, or the power and network fabric that binds zones together, Multi-AZ no longer has anywhere to fail over. That is why the architecture is strong for local failures but weak against regional collapse.
Practical implication: treat Multi-AZ as a baseline availability control, not as a complete disaster recovery design.
Why native snapshots can fail as a recovery path
Cloud backup features often rely on the same regional control plane or storage layer as the workloads they protect. In this case, snapshots and regional storage became inaccessible at the same time as the primary services, which meant backup data was not an independent recovery tier. That creates a hidden dependency: a backup that appears separate operationally may still be coupled to the same regional failure domain. Recovery architecture has to test whether backups are actually survivable outside the blast radius, not merely whether they exist.
Practical implication: validate that backup copies and restore paths sit outside the failure domain of the protected workload.
How data residency turns resilience into a governance problem
Data residency and sovereignty requirements can block the fastest technical recovery option, even when another region is healthy. If regulated data cannot be moved automatically to an alternate geography, failover has to be pre-approved, documented, and aligned with legal obligations before an outage begins. That means continuity depends on data classification, policy mapping, and lawful transfer logic as much as on infrastructure design. In regulated environments, resilience is not just an engineering property; it is a governance boundary.
Practical implication: align recovery architecture with residency rules so legal approval does not become the outage bottleneck.
Threat narrative
Attacker objective: The objective was to disable regional cloud availability by physically degrading the infrastructure that supported customer workloads and backups.
- Entry occurred when drone strikes physically damaged AWS data centres in the UAE, disrupting the regional cloud environment rather than a single isolated facility.
- Regional services and backup dependencies were degraded at the same time, which removed the normal recovery path through snapshots and native failover.
- Impact followed as mission-critical applications lost access to data and organisations faced operational downtime plus regulatory exposure.
Breaches seen in the wild
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Regional resilience is a governance problem once recovery options are constrained by law. The article shows that technical redundancy is not enough when the next valid recovery region is governed by residency and adequacy requirements. Recovery design therefore has to reconcile availability with lawful data movement before the incident occurs. Practitioners should treat region selection, replication scope, and approval workflows as part of resilience architecture, not post-incident paperwork.
Multi-AZ created a false sense of survivability for region-wide disruption. The control solves a narrower problem than many teams assume, because it assumes the region itself remains serviceable. When a physical event or large-scale regional outage affects shared cloud services, Multi-AZ only preserves the illusion of continuity. Practitioners need to challenge any recovery plan that uses zone redundancy as evidence of regional survivability.
Live data intelligence becomes the deciding factor when infrastructure fails. Securiti’s account makes clear that classification, lineage, and approval state had to travel with the data for restoration to work quickly and compliantly. That is a data governance lesson with direct cloud-security consequences: if teams cannot identify what can move, where it can move, and under whose approval, recovery slows to a manual crawl. Practitioners should make data visibility a recovery dependency, not a reporting afterthought.
Compliance-aware portability is the new baseline for cloud continuity. The article describes a world where failover decisions are shaped by regulatory exposure as much as by technical uptime. This pushes resilience programmes toward pre-authorised cross-cloud options, tested legal workflows, and environment-specific restoration runbooks. Practitioners should assume that fast recovery now depends on governance-ready portability, not simply on spare capacity.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Security Guide
What this signals
Regional failover has become a governance decision, not just an engineering one. The UAE outage shows that continuity planning now has to account for the legal status of the next recovery region, not simply its technical availability. Teams should expect the approval path, not the topology diagram, to determine how fast restoration can happen.
Cross-cloud portability is the practical answer to shared cloud blast radius. When the same regional services that host the workload also host the backups, resilience is only nominal. Programmes that can restore data and workload state across clouds will recover faster because they are not waiting for a single provider’s regional fabric to return.
Data intelligence is now part of the recovery control set. If classification and lineage are missing, every restoration becomes a manual legal and operational review. That is why data governance and disaster recovery cannot be run as separate disciplines in regulated environments.
For practitioners
- Define recovery tiers by residency rule Map each regulated dataset to the regions and clouds where it may legally be restored, then pre-approve the failover order for each tier.
- Test recovery outside the primary region Run exercises that assume the source region is unavailable, including restore tests from alternate clouds and alternate geographies.
- Verify backup independence from regional services Check whether snapshots, object storage, and replication controls depend on the same regional services as the workload they protect.
- Build approval workflows into failover plans Document who can authorise cross-border data movement, what evidence is needed, and how quickly that approval can be granted during an outage.
Key takeaways
- The outage shows that zone-level redundancy does not protect against a regional collapse that takes shared services and backups down together.
- Regulatory constraints can turn a technically simple failover into a governance-heavy recovery process, especially for residency-bound data.
- Teams need pre-approved cross-cloud recovery paths, independent backup tiers, and live data intelligence if they want continuity to survive a regional event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | The article is fundamentally about recovery execution after a regional cloud outage. |
| RC.IM-01 — Improvements | The post argues for reworking resilience assumptions after a failed regional failover model. | |
| PR.DS-11 — Data at Rest | The article centres on backup copies, snapshot survival, and data portability across regions. | |
| Recommendation — Test recovery plans against regional outage scenarios and validate restore execution outside the primary cloud region. Update recovery plans after regional disruptions and capture the control gaps that delayed restoration. Verify that data copies and backups remain recoverable when the original region is unavailable. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | Regional continuity planning and failover sequencing are the main control issues in the article. |
| CP-10 — System Recovery and Reconstitution | The recovery workflow described is a direct example of system recovery under degraded cloud conditions. | |
| Recommendation — Align contingency plans to regional outage scenarios and rehearse restoration from alternate geographies. Validate recovery and reconstitution procedures for workloads that cannot return to the primary region immediately. | ||
| ISO/IEC 27001:2022 | A.5.29 — Information security during disruption | The post is about maintaining secure operations during a major cloud disruption. |
| A.5.30 — ICT readiness for business continuity | The article shows why continuity planning must include ready-to-use alternate environments. | |
| Recommendation — Define disruption procedures that preserve security, compliance, and continuity when regional services fail. Prepare alternate environments and restore paths so continuity actions can start immediately after a regional outage. | ||
Key terms
- Multi-AZ Architecture: A Multi-AZ architecture distributes workloads across multiple Availability Zones inside one cloud region so a single facility failure is less likely to interrupt service. It reduces local blast radius, but it does not protect against region-wide disruption or against dependencies that still sit inside the same regional boundary.
- Regional Failure Domain: A regional failure domain is the set of services, backups, and dependencies that can all be affected by one large cloud-region outage. If recovery assets share that same boundary, the environment may look redundant on paper while remaining exposed in practice.
- Data residency: The requirement that data remain in a specific jurisdiction or region for storage, processing, or both. In regulated identity programmes, residency is part of the assurance model because it influences legal exposure, audit scope, and the set of controls needed to prove compliance.
- Governed Migration: Governed migration is the movement of data or workloads under documented approval, policy controls, and preserved metadata. It matters when recovery must stay compliant while moving across regions or clouds, because restoration speed without governance can create a second incident.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a practical route for security teams that need to connect governance, access control, and operational resilience across their programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org