Why Multi-Availability Zone (AZ) Deployments Weren't Enough This Time
To understand why so many organizations were caught flat-footed, it helps to understand what the standard playbook for disaster recovery looks like for AWS Availability Zones
AWS AZs are distinct physical data center facilities within a single geographic region, connected by high-bandwidth, low-latency private networking. The architecture is designed so that a failure in one AZ - a power outage, a cooling failure, a hardware fault - doesn't propagate to the others. Running a Multi-AZ deployment means your Relational Database Service (RDS) (which automates common administrative tasks like hardware provisioning, patching, backups, and monitoring) has a standby replica in a second facility, your Elastic Compute Cloud ( EC2) instances are spread across zones, and your load balancer automatically routes traffic around an unhealthy target. For the overwhelming majority of cloud incidents, such as hardware failures, localized power events, network partitions - this architecture is excellent and works exactly as intended.
The critical limitation is geographic proximity. AZs within a single region are typically located within a radius of roughly 100 kilometers of each other. That proximity is a deliberate engineering trade-off: it keeps inter-AZ latency low enough to support synchronous replication and real-time failover. But it also means that a physical event of sufficient scale- a natural disaster, a regional power grid failure, or, in this case, targeted drone strikes - can affect all AZs in a region simultaneously.
That is precisely what happened between March 1-3, 2026. The drone strikes didn't hit a single facility. They hit multiple data centers across the me-central-1 (UAE) region in close succession, with the me-south-1 (Bahrain) region sustaining damage from a nearby strike as well. Customers running textbook Multi-AZ architectures - spreading workloads across three availability zones, maintaining standby database replicas, using auto-scaling groups - experienced the same outage as customers running single-AZ deployments. Their failover logic had nowhere to fail over to.
Compounding the problem was the AWS Snapshots failure mode. EBS snapshots - the incremental, point-in-time backups that organizations rely on for disaster recovery and volume restoration - are stored in Amazon S3 within the same region. These native snapshots were no longer a viable recovery path - the physical strikes had throttled S3 and DynamoDB so severely that the storage layer underpinning those backups was itself unavailable.
As a result, Mission-critical data went dark and business continuity was jeopardized.
With EC2 compute instances offline and DynamoDB tables unreachable, customers couldn't access the data their applications depended on. For fintech operators, that meant payment processing pipelines stalled. For retail platforms, it meant order management systems went dark. Every hour of downtime carried both direct revenue consequences and growing regulatory exposure - particularly for organizations subject to UAE data residency requirements, GDPR, or financial services compliance mandates.
Why This Was Especially Hard to Recover From
Three constraints collided at once:
- Regional cloud services were degraded, not just individual facilities.
- Native recovery mechanisms depended on those same services.
- Data residency and sovereignty rules eliminated default cross-region failover options.
For organizations subject to strict regulatory requirements, restoring availability by simply moving data elsewhere was not an option. Availability and compliance were in direct tension.
This is where many recovery efforts stalled.
How Securiti Responded: An Unconventional Recovery Playbook
With the standard recovery paths unavailable, Securiti's engineering team executed a multi-track recovery operation in parallel, working around each constraint rather than waiting for AWS to resolve them.
Track 1 - Cross-region data access via Bahrain. Because regional S3 was unreachable and snapshots were inaccessible through normal means, the team established a VPC peering connection between the damaged UAE region and AWS me-south-1 in Bahrain. This created a network path to surviving instance storage that bypassed the degraded S3 layer. Approved customer data was then backed up directly to S3 buckets in the EU region - establishing a clean, geographically separate copy outside the conflict zone for the first time.
Track 2 - Direct EKS and SSM access to surviving infrastructure. The team identified EKS nodes that had survived the partial damage to me-central-1c and accessed them directly via AWS Systems Manager (SSM), avoiding the need for public network paths or healthy EC2 bastion infrastructure. Through this access, engineers reached the underlying databases and performed local backups to the UAE S3 - capturing data that would otherwise have been lost if the remaining infrastructure degraded further.
Track 3 - Cross-cloud redundancy in Azure. Simultaneously, and independently of the AWS recovery tracks, the team established backup copies of critical customer data in Microsoft Azure. This was a deliberate hedge against the possibility of a total AWS ME failure - ensuring that even if the situation in both the UAE and Bahrain deteriorated completely, a secondary copy existed on an entirely separate cloud provider with no dependency on AWS infrastructure in the region.
Migration to EU: Getting Customers Back Online Without Breaking the Rules
With data secured across multiple locations, the team moved to restore customer service. The process was deliberate, compliance-first, and faster than the alternative would have been without pre-existing EU infrastructure.
Veeam's legal team was consulted before any cross-border data movement occurred. Given that affected customers operated under strict UAE data residency requirements, moving tenant data to EU infrastructure required explicit customer consent - not assumed authorization. Approval was sought and documented for each impacted customer before migration began.
The EU cloud infrastructure was already operational. Because Securiti runs production environments across multiple regions as part of its standard multi-cloud architecture, the EU environment required no provisioning time. It was live, tested, and ready to receive tenant data.
Once customer approvals were secured, specific tenant datasets were migrated to the EU environment and restored. Customers were back online within a matter of hours from the point of approval - not days. For customers with ongoing data residency concerns about operating from EU infrastructure, Securiti offered temporary EU hosting as an explicitly time-bounded arrangement while a longer-term UAE recovery path was evaluated. Secondary copies remained in Azure as a live failsafe against any further strikes or cascading failures in the AWS Middle East footprint.
Before any cross-border data movement occurred, customer consent was obtained and documented. Because Securiti already operated a production-grade EU environment, there was no delay in provisioning new infrastructure. Approved customer datasets were migrated and restored quickly, allowing operations to resume in hours rather than days.
For customers with ongoing data residency concerns, EU hosting was offered as a temporary, explicitly time-bound measure, not a permanent shift. Secondary cross-cloud copies remained in place as a safeguard against further instability.
Why This Worked
The Role of Data Discovery and Cross-Cloud Visibility
The speed of the recovery was not accidental. A critical enabler was Securiti's continuously maintained, cloud-agnostic data catalog - which meant that when the UAE region went dark, the team already knew precisely which datasets were hosted in the affected availability zones, which workloads depended on them, what sensitivity classifications those assets carried, and which regulatory frameworks governed them. That triage took minutes, not days.
For the compliance dimension of the response - determining which customers needed to be consulted before data movement, which regulatory notifications might be required, and which EU destination buckets were permissible under each customer's residency obligations - this pre-existing data intelligence was the difference between a structured, defensible response and a chaotic one.
Governed Migration, Not Just Fast Migration
The EU restoration was fast in part because the compliance groundwork had already been laid. Securiti's platform maintained classification and lineage continuity across the migration, meaning that the regulatory metadata built up over months of operation in the UAE environment traveled with the data to its new home. Compliance teams did not need to re-classify assets from scratch post-recovery or reconstruct data maps for regulators after the fact. The restored EU environment was compliant on arrival, not compliant eventually.
The Compounding Cost of Unpreparedness
It's worth being direct about what the alternative looks like. Organizations without a real-time, cross-cloud data catalog faced a manual discovery process that, in complex environments, can take weeks. Without governed migration tooling, compliance teams had to manually review every data movement decision - a bottleneck that extended downtime. And without automated breach assessment capabilities, legal and compliance teams operated in a fog, unsure which regulators to notify, by when, and about what.
Regulatory penalties for delayed breach notification under frameworks like GDPR can reach into the tens of millions of euros. Operational downtime costs for a mid-size fintech processing regional payments can run into six figures per hour. The financial calculus of preparedness versus recovery is not close.
Lessons Learned/What This Event Clarifies
The AWS UAE outage is a reminder that cloud infrastructure is not immune to physical-world disruption. Conflict, natural disaster, and cascading infrastructure failure are not edge cases to be engineered around in theory - they are scenarios that require tested, automated, cross-cloud response capabilities.
Also, it is worth noting that the lesson is not that Multi-AZ is the wrong architecture. It remains an essential baseline practice and should be the minimum deployment standard for any production workload. The lesson is that Multi-AZ solves a different problem than the one organizations faced on March 2. It is a facility-level resilience mechanism, not a regional one. Protecting against regional failure requires either cross-region data replication - so that backups exist outside the affected geography - or active-passive multi-region architecture, where a secondary region can absorb traffic if the primary disappears entirely.
For organizations with data residency obligations, neither path is as simple as flipping a switch. Replicating regulated data to another region requires that the destination region satisfies the same sovereignty and adequacy requirements as the source. Failing over to an unvetted region to restore availability can create a compliance violation even as it solves an operational one. This is the intersection where infrastructure resilience, data security and governance converge - and where having pre-built, policy-governed cross-cloud capabilities becomes the difference between a rapid, compliant recovery and a protracted scramble.
Securiti's ability to mobilize quickly for affected customers wasn't just a function of incredible engineering effort in the moment; it was also a function of work done in advance: data assets discovered, classified, cataloged, and governed before any crisis arrived.
When the infrastructure failed, the data intelligence didn't.
To learn how Securiti can help your organization, contact us or explore our cross-cloud data and AI platform.
