AWS ME-CENTRAL-1 and ME-SOUTH-1: When War Came to the Cloud

When the Threat Model Changes Overnight

Every architecture review I have ever sat through includes a risk matrix. Power failure, yes. Network partition, absolutely. Ransomware, increasingly so. Iranian ballistic missiles hitting your data center? That one rarely makes the slide.

On March 1, 2026, AWS discovered that its threat model had a gap. Iranian forces launched a coordinated strike involving over 165 ballistic missiles and 540 drones across the UAE and Bahrain. Two AWS data centers in ME-CENTRAL-1 (UAE) took direct hits. A third facility in ME-SOUTH-1 (Bahrain) sustained damage from a strike in the surrounding area. By the time fire suppression systems finished flooding the server floors and local authorities cut mains power to contain the fires, entire cloud regions had gone dark.

This was not a software bug or a misconfigured load balancer. This was the first confirmed instance of a major US hyperscaler’s physical infrastructure being taken offline by military action. The industry had theorized about geopolitical risk in cloud deployments for years. Now it had a case study.

What Failed and How It Cascaded

The immediate failure was physical. Fire suppression systems, doing exactly what they were designed to do, flooded equipment bays. Structural damage from blast impacts made portions of the buildings unsafe to enter. Local fire departments, prioritizing life safety over compute capacity, cut all mains power including generator circuits. AWS had no path to restoration that did not involve waiting for the situation on the ground to stabilize.

From an infrastructure perspective, both ME-CENTRAL-1 and ME-SOUTH-1 are relatively young regions. ME-CENTRAL-1 launched in 2022 to serve the UAE market. Neither region had the same depth of redundancy as older, more mature regions like us-east-1 or eu-west-1.

With the regions offline, approximately 60 AWS services went dark. The cascade into downstream platforms was immediate and severe. Snowflake, which routes significant regional workloads through AWS infrastructure, lost availability for Middle Eastern customers. Careem, the ride-hailing platform that underpins urban mobility in the UAE, went offline. Abu Dhabi Commercial Bank’s mobile app stopped functioning. Emirates NBD’s phone banking became unreachable. Fintech platforms Alaan and Hubpay lost connectivity. Sarwa’s investment app went down.

AWS engineering teams were, for once, powerless in a very literal sense. There was no rollback to push. No configuration to revert. The facility assessment teams could not even enter portions of the building.

The Recovery That Took Days

AWS issued customer guidance urging workload migration to EU regions. The phrasing was careful but the message was clear: do not wait for us, move your applications now.

Recovery took over 72 hours. Even after the physical situation stabilized, restoring services required systematic assessment of which hardware had survived, which storage volumes were intact, and whether data durability guarantees had been maintained. AWS’s S3 durability model, built on cross-facility replication, held for customers who had properly configured cross-region replication. Customers running single-region deployments without backup strategies had a much worse day.

As Werner Vogels once wrote, “Everything fails, all the time.” Most AWS engineers internalized that as meaning software failures, flaky networks, or disk corruption. Nobody expected it to mean a data center physically burning.

What This Means for Cloud Architecture

The standard resilience conversation around cloud infrastructure focuses on availability zones and multi-region deployments. Those abstractions assume the underlying regions are intact. They do not account for an entire geographic cluster being removed from the available pool.

Organizations running workloads in politically volatile regions now face a harder question: what is the acceptable recovery time objective if your primary region is physically inaccessible for multiple days? For most, the honest answer before this incident was “we have not modeled that.”

The event surfaces a few concrete architecture decisions that separate resilient deployments from fragile ones. Active-active multi-region deployments, not merely warm standby, provide actual continuity when a region vanishes. Data replication strategies need to account for the possibility of permanent, not temporary, loss of a region. And the selection of cloud regions in geopolitically unstable areas needs to carry a risk premium in the architecture conversation, not just in the commercial negotiation.

The Broader Signal

What makes this incident categorically different from every other outage on this list is that no post-mortem action item can prevent it. AWS cannot patch its way to missile resistance. The cloud providers built their redundancy models around software faults, hardware failures, and natural disasters. Military conflict in populated urban areas represents a different class of risk entirely.

The insurance industry has language for this. Force majeure clauses in cloud provider agreements specifically exclude liability for acts of war. Most customers have never read that section carefully.

The financial and operational sector in the UAE had largely consolidated onto cloud infrastructure over the preceding four years. The outage demonstrated, with extraordinary clarity, that cloud consolidation in a single geographic region carries systemic risk that no SLA can address once the physical substrate is compromised.

For architects designing systems in 2026, the lesson is uncomfortable but necessary: geographic redundancy is not a nice-to-have feature for high-availability applications. It is the minimum viable architecture for any workload that cannot afford days of downtime. The assumption that cloud regions are effectively permanent is now demonstrably false.

References

1. AWS Service Health Dashboard, March 2026, ME-CENTRAL-1 and ME-SOUTH-1 outage records
2. DataCenterDynamics, “AWS data centers hit in Iran UAE military exchange,” March 2026
3. The Register, “Missiles and servers: inside the AWS Middle East outage,” March 2026
4. Reuters, coverage of Iranian strikes in UAE and Bahrain, March 1-3, 2026
5. AWS Customer Advisory, “Migrate workloads from ME-CENTRAL-1,” March 2, 2026