There’s a belief that shows up in nearly every architecture review I’ve been part of. It goes something like this: “We’re running in a single Availability Zone, but AWS is reliable enough. If something goes wrong, we’ll deal with it.”
It sounds reasonable. AWS AZ outages are rare. When they happen, they’re usually measured in hours. You restore from a snapshot, relaunch some instances, update your post-mortem template, and move on. The math feels fine.
On March 1, 2026, drone strikes physically hit three AWS data centers, two in me-central-1 (UAE) and one in me-south-1 (Bahrain). Fires broke out, local fire departments cut primary power and backup generators, and two of me-central-1’s three availability zones (mec1-az2 and mec1-az3) went down. In me-south-1, mes1-az2 lost power. 109+ services were disrupted across me-central-1, with 50+ affected in me-south-1. AWS told customers to move their data out: launch replacement instances in surviving AZs, restore from EBS snapshots, reroute traffic. Your stuff is stranded. Rebuild somewhere else.
Then on March 24, me-south-1 was hit again. AWS confirmed the Bahrain region was disrupted by drone activity and advised customers to migrate workloads out of the region entirely. Two regions, three weeks, and AWS is now telling customers to leave.
On April 1, drones hit Bahrain again, making it the third strike on me-south-1 in five weeks. The next day, a strike attempt on Oracle’s Dubai data center was intercepted by air defenses, with shrapnel hitting the Oracle building in Dubai Internet City. Oracle’s Dubai services stayed up. That one was a near miss. But the campaign extended past AWS to a second cloud provider in the same geography.
Two months on, mec1-az2, mec1-az3, and mes1-az2 are all still impaired.
This isn’t a software recovery. It’s not even a single physical recovery anymore. It’s an ongoing campaign against cloud infrastructure inside an active conflict zone.
That changes the “we’ll deal with it” math completely.
The single-AZ bet is popular because it’s cheap and simple. One subnet, one set of instances, no cross-AZ data transfer costs, no complexity from replication or failover logic. For staging environments, batch jobs, and internal tools, it’s a defensible choice.
The problem is when production workloads end up there. Not because someone decided single-AZ was the right architecture, but because nobody decided otherwise. The default sticks. The workload grows. The blast radius grows with it. And the reasoning that justified single-AZ for a prototype (”AWS is reliable enough”) becomes the reasoning that justifies single-AZ for a revenue-critical system.
AWS is reliable enough, until the failure mode changes from “a few hours of degradation” to “your AZ is gone and your data is on hardware you can’t reach.”
Every prior AZ outage taught the same lesson: it’ll be a few hours, you’ll restore from a snapshot, you’ll write a post-mortem. Power blips and network issues, partial service degradation, recovery within hours. The December 2021 us-east-1 incident was the high-water mark: 7 hours down, and roughly 7.5% of EBS volumes in the affected AZ experienced permanent data loss. But even that resolved within a day.
The Middle East outages broke the template. Drone strikes caused structural damage and fires at three facilities across two regions. Fire departments shut off power, including backup generators. Two of three AZs in me-central-1 went down, plus one in me-south-1. And the recovery timeline isn’t measured in hours. It’s been months, with follow-on strikes landing before the first damage was repaired, and no announced restoration date.
That changes the recovery model completely. You’re not waiting for AWS to fix a software issue or restore power from backup generators. You’re waiting for structural inspections, smoke and water damage assessments, and staged power-ups to avoid electrical surges. And you might get hit again while you wait.
This is where it got interesting.
When mec1-az2 lost power, every EC2 instance in the zone went dark. Normal so far. But Elastic IPs associated with those instances couldn’t be released. The AWS control plane needs to talk to the underlying hardware to safely detach a network address from an instance. If the hardware is off, that conversation can’t happen.
So customers had public IPs pointing at dead instances, and they couldn’t move those IPs to healthy instances in other AZs. For 14 hours. DNS-based failover would have worked, but teams that hardcoded Elastic IPs into their architecture, or had downstream systems pointing at those IPs, were stuck.
At 6:01 PM PST, AWS deployed a workaround: forceful disassociation, letting the control plane ignore the state of trapped resources and free up the IPs anyway. That wasn’t in anyone’s runbook. AWS engineers built it during the incident because the normal control plane had no answer for hardware that was simply off.
This is the part that most post-mortems will skip. The AZ going down is the headline. The Elastic IP trap is the engineering lesson. Stateful resources actively block recovery when their hardware is unreachable.
EC2 instances, EBS volumes, and Elastic IPs are zonal services. They exist in exactly one Availability Zone. When that zone is healthy, this is invisible. When it’s not, it’s everything.
EBS volumes in a dead AZ are inaccessible until the AZ comes back. If the AZ doesn’t come back, or takes days, your data is hostage. You can restore from snapshots, if you have recent ones and if your application can tolerate the gap between the last snapshot and the failure.
EC2 instances are just gone. You launch new ones in another AZ, but local storage, in-memory caches, anything not replicated elsewhere disappears with the old instance. And Elastic IPs, as we just saw, can end up trapped on dead hardware. Your public address becomes a liability.
Every stateful resource you attach to a single AZ is a bet that the AZ stays up. Not for hours, but indefinitely. Because when it goes down hard, those resources don’t degrade gracefully. They become anchors.
The teams that fared best on March 1 weren’t the ones with the smartest failover plans. They were the ones who never put state in a zone in the first place.
DynamoDB, S3, and Lambda are regional services. They spread data and compute across multiple AZs by default. When mec1-az2 went down, these services mostly kept running in the remaining AZs.
A caveat: when two of three AZs go down simultaneously, regional services lose enough capacity that they degrade too. The “route around the dead zone” model assumes one zone fails, not two. The “fail over to another region” model assumes the other region isn’t also under attack.
That said, the failure mode observation still holds. Services that don’t pin state to a single AZ recovered faster and didn’t produce the cascading Elastic IP traps that EC2+EBS+EIP architectures did. Regional services degraded. Zonal services were stranded.
Application state in DynamoDB instead of on an EBS volume? Losing an AZ doesn’t strand your data. Compute on Lambda instead of EC2? You don’t need to launch replacement instances and reattach storage. Traffic through API Gateway or CloudFront instead of an Elastic IP? Your public address doesn’t end up trapped on dead hardware.
The less state you pin to a zone, the less a dead AZ can hurt you.
If your failover plan for me-central-1 was “fail over to me-south-1,” you now have two compromised regions. AWS’s own guidance is to use a second region for disaster recovery. Teams that followed it and picked the nearest Middle East region as their DR target are back to square one. Their primary is damaged, their secondary is under active attack, and AWS is telling them to leave both.
This introduces a failure mode that most DR designs don’t account for: correlated regional failure driven by geopolitics. Your two regions aren’t independent if they’re both within range of the same threat actor. Geographic proximity, which you chose to minimize latency, becomes a liability.
Fortune called this “a new kind of war.” From an infrastructure perspective, it’s a new kind of correlated failure. Your region selection is now a geopolitical decision, not just a latency one.
This is the objection I hear most. And it’s partly true.
Running EC2 across multiple AZs means cross-AZ data transfer costs, more instances than a single-AZ setup, and the operational complexity of ensuring your application actually works in a multi-AZ topology. It’s not free.
But the AWS Fault Isolation Boundaries whitepaper is explicit: you need static stability. That means pre-provisioning enough capacity in each AZ to handle the loss of any other AZ without relying on auto-scaling to save you. If you need 6 instances across 3 AZs, you run 9, three per AZ, so any single AZ failure leaves you with 6 functioning instances.
That’s the real cost of multi-AZ: 50% overcapacity on top of the cross-AZ instance count, to maintain static stability. For teams that balk at the single-AZ cost, this is a non-starter. Which is exactly why they don’t do it, and why me-central-1 is a wake-up call.
The alternative isn’t suffering through AZ failures. It’s rethinking what lives in a zone at all.
Start by auditing your zonal dependencies. Which of your resources are pinned to a single AZ? These resources become anchors when an AZ goes hard down: EC2 instances, EBS volumes, Elastic IPs, RDS single-AZ deployments, ElastiCache nodes.
For each one, ask: does this resource need to be zonal?
If the answer is yes (maybe you need GPU instances or specific instance types only available in certain AZs), then you need genuine multi-AZ with static stability. Pre-provisioned capacity, health-checked failover, and recent snapshots you’ve actually tested restoring.
If the answer is “we just never moved it” (and it often is), consider whether a regional service does the job. DynamoDB instead of RDS single-AZ. Lambda instead of a long-running EC2 daemon. S3 instead of EBS for data that doesn’t need block storage semantics. Route 53 health checks instead of Elastic IPs.
Stop treating Elastic IPs as static infrastructure. They are zonal resources with a dependency on hardware state. If your architecture can’t survive losing an EIP for 14 hours, you have a single point of failure wearing a different name.
If you’re in a region with geopolitical risk, your DR region needs to be outside the blast radius. me-south-1 as DR for me-central-1 looked reasonable on a latency chart. It doesn’t look reasonable when both are being struck in the same campaign. eu-central-1 or eu-south-1 as your DR target costs more in cross-region latency but doesn’t share the same threat model.
One more thing operators tend to miss until it’s too late: cyber insurance excludes war. As one data center insurance specialist put it, “typically, a policy excludes war. So if it’s an active war, it’s not gonna be covered.” Cloud vendor credits cover a slice, usually as a discount on future spend. The real losses on your side are revenue lost during outages, emergency migration costs, and abandoned regional infrastructure investments. Those fall on you. Your cyber insurance won’t pay either, because war exclusions are standard policy language. Build your DR plan assuming the financial backstop you thought you had isn’t there.
And test your recovery. “We have snapshots” isn’t enough. Restore one in a different AZ and confirm your application comes up. “We have a DR region” isn’t enough. Fail over to it and confirm your application works at acceptable latency from a geographically distant region. Most teams that say they can recover from an AZ failure have never tried it. Even fewer have tested cross-region failover.
Every team running production in a single AZ is making an implicit prediction: the worst-case AZ failure will be short enough that manual recovery is acceptable. Every team running multi-AZ in a single region is making a second prediction: only one AZ fails at a time. Every team with multi-region DR is making a third: the DR region is independent of the primary.
March 2026 broke all three.
The old assumption was that AZ failures are contained and brief. The slightly less old assumption was that region failures are independent. Neither held.
Your infrastructure’s resilience is defined by the things you bolted to a single zone, and the assumptions you made about the independence of your regions. The fewer stateful zonal resources in your architecture, the less a dead AZ can do to you. The more geopolitically distant your DR region, the less a regional conflict can do to you.
Because now we know an AZ can disappear for months, a region can be struck repeatedly, and your DR region might be next. Act like it.
AWS says drones hit two of its datacenters in UAE — The Register — confirmed drone strikes as cause, two UAE facilities hit
AWS UAE suffers AZ outage after ‘objects strike data center’ — Data Center Dynamics — two AZ impact, three facilities across two regions
Amazon Data Centers on Fire After Iranian Missile Strikes — 404 Media — geopolitical context and physical damage reporting
Amazon’s Bahrain data center targeted by Iran — CNBC — confirms me-south-1 was directly struck, not collateral
AWS Middle East Outage After Data Centers Hit — Data Center Knowledge — 109+ services affected, regional service degradation
AWS Middle East Outage: Physical Fire Shuts Down me-central-1 — Cyber Updates 365 — detailed timeline including Elastic IP trap and forceful disassociation
AWS Power Outage in Middle East Triggers Major Disruption — Cybersecurity News — service impact scope and API failure details
Amazon Web Services Power Outage in Middle East — CyberPress — Elastic IP association failures and control plane behavior
AWS says recovery ‘many hours away’ — TahawulTech — AWS official statements on recovery timeline
Amazon Web Services Reports Hours-Long Recovery Effort — TechAfrica News — March 2 status update
Iran hits Amazon Web Services building in Bahrain — Free Press Journal — structural damage and power disruption in Bahrain
Iranian drone strikes raise alarms — Rest of World — regional impact and customer displacement
AWS Bahrain operations disrupted for second time — The National — second strike confirmed
Amazon says AWS Bahrain region disrupted following drone activity — Al Jazeera — AWS confirms disruption
Amazon faces further AWS disruption in Bahrain — CNBC — AWS advises customer migration out of region
AWS Bahrain region disrupted by drone activity — Data Center Dynamics — ongoing impact of conflict on data center infrastructure
Fire at AWS data center in Bahrain after Iranian attack — Data Center Dynamics — third strike on me-south-1 confirmed by Bahrain authorities
Iran attack hits an Oracle data center in Dubai, causes limited damage — Data Center Dynamics — strike attempt intercepted, shrapnel damage to Oracle building, services unaffected
Iran’s attacks signal new kind of war — Fortune — IRGC claims responsibility, strategic analysis
War in Iran damages multiple AWS data centers — InfoQ — technical multi-AZ analysis
Amazon loses $150M after drones hit its data centers — Yahoo Finance — cyber insurance war exclusion, customer-side cost reality
Legal and policy fallout from data center strikes — TechPolicy.Press — legal and policy implications
Zonal services — AWS Fault Isolation Boundaries — AWS whitepaper on zonal vs regional service classification
AWS service types — AWS Fault Isolation Boundaries — zonal, regional, and global service taxonomy
Summary of the Amazon EC2 and Amazon RDS Service Disruption — AWS — December 2021 us-east-1 incident with permanent data loss
Multi-AZ resilience: Why the recent AWS outage shows you need it — Loadbalancer.org — October 2025 us-east-1 outage analysis
AWS Data Center in UAE Goes Dark — Trending Topics EU — incident context and customer impact
Operational issue – Multiple services (UAE) — Hacker News — community discussion and real-time status updates
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.