Your Multi-Region Architecture Assumes the Weather

On 1 March 2026, Iranian drones directly struck two Amazon Web Services facilities in the United Arab Emirates, and a strike in close proximity caused physical damage to a third AWS facility in Bahrain. The most useful part of what followed is the part that worked.

AWS reported that at around 4:30 AM PST availability zone mec1-az2 had been impacted by objects that struck the data centre, creating sparks and fire, and that the fire service had cut power to the facility and its generators while containing the blaze. In the same update the company said the region’s other zones were functioning normally and that customers running workloads redundantly across zones were not affected. A facility had been knocked offline by physical attack, and for genuinely multi-zone workloads the architecture absorbed it. The design did what it was built to do.

Later the same day, mec1-az3 became impaired as well. AWS’s own account of what happened next is the cleanest evidence in this story: S3 is designed to withstand the total loss of one availability zone, it kept operating normally after mec1-az2 was powered off, and error rates rose as the second zone degraded, producing high failure rates for data ingest and egress. Dozens of services were disrupted or degraded across the two regions, and the effects propagated into banking, payment, delivery and enterprise services used across the Gulf.

Zone redundancy is a hedge against one thing going wrong. A conflict is a source of repeated physical events in a single geography, and adversarial infrastructure resilience begins where that distinction is written down.

Independence is an assumption about the adversary

Every layer of modern resilience practice inherits the same premise.

Availability zones exist to prevent single-site loss from becoming regional loss. They are physically separate facilities with independent power, cooling and networking, placed far enough apart that no single fire, flood, storm or grid event takes more than one. That is a bounded fault model, and it assumes a hazard with no preferences and no second attempt.

Three resilience disciplines already do more than “everything assumes randomness” allows. Chaos engineering can and does model severe correlated failures; AWS’s own fault injection service has availability-zone power-interruption scenarios, and good practitioners choose faults deliberately rather than randomly. Static stability is about not taking new control-plane dependencies during a failure, which says nothing about what caused it. Cell-based architecture creates containment boundaries without assuming faults spread only by proximity.

What ordinary resilience practice rarely models is an adaptive opponent. Fault injection is non-adaptive: you choose the fault, the system does not choose back. An adversary observes where you fail over and selects the next failure accordingly. An adaptive opponent is a narrower claim than randomness, and a harder one to argue with.

March 2026 is the first documented wartime kinetic attack on commercial public cloud infrastructure, and the shape of it is precise. Commercial hyperscale facilities are comparatively soft targets by military standards, neither hardened nor given dedicated air defence, which makes them attractive as targets of opportunity. Whether these particular buildings were chosen carefully or hit because they were easy, the outcome for anyone downstream is the same: two correlated physical failures in one region within a single day, which no probabilistic model of independent hazards would have generated.

The availability arithmetic depends on it. Under an independence assumption, losing two specified zones is assigned probability p squared, a number small enough to design around. Independence does not forbid the outcome, it just makes it very unlikely. Once the same adversary selects both targets, the independence assumption is no longer justified and the number that made the architecture look adequate stops meaning anything. Nobody sends you an alert when that happens.

I have spent a long time in labs testing attacks against physical systems, and this is the oldest lesson in that work. A hazard model and a threat model are different documents. Substituting one for the other feels like diligence and is not.

Independence has a physical address

Cloud provider documentation calls availability zones independent, and the word has a physical meaning.

Availability zones are separated by distance sufficient to decorrelate the hazards they were designed against. Far enough apart that one flood reaches only one of them. That distance is chosen against a lower bound too. Synchronous replication needs single-digit millisecond latency for most workloads, which puts the zones tens of kilometres apart rather than hundreds. Zones in a region are therefore in the same metropolitan area by construction.

AWS engineers hard against the obvious shared dependencies: zones are designed to draw on different substations, and interconnect over redundant dedicated metro fibre. The correlations that survive are the ones above those isolation boundaries. Same weather system. Same regulatory jurisdiction. Same airspace. Same conflict zone. Same adversary, with the reach to select more than one target inside a footprint measured in tens of kilometres.

This is not a criticism of the design. Synchronous replication across continental distances is physically possible and commercially available. Speed-of-light latency makes it an unacceptable trade for most workloads, so metro-scale separation was the correct answer to the hazards it was chosen against. It is a criticism of how the resulting guarantee gets described downstream, where a count of zones is reported as a count of independent failure domains and the metro-scale qualifier drops out.

What Byzantine fault tolerance does and does not cover

Computer science solved adversarial failure decades ago, in one specific version.

Leslie Lamport, Robert Shostak and Marshall Pease formalised the Byzantine generals problem in 1982, and the state machine replication work that followed gives you systems that operate correctly while some fraction of participants behave arbitrarily, including maliciously. That is a genuine adversarial model, and it underpins everything from flight control computers to consensus protocols.

It models arbitrary faulty behaviour, not merely lying, and the adversary in those models generally does get to choose which participants to corrupt within the stated bound. The theory is further along than that: there is a substantial literature on mobile Byzantine adversaries, adaptive corruption, targeted node removal and graph connectivity under attack.

What is missing is the translation of that theory into facility-level architecture and continuity exercises. Byzantine tolerance protects consensus among nodes that misbehave; almost nobody has taken the adaptive-adversary models and used them to decide which buildings their workload should not be in simultaneously. The nearest practical discipline is red teaming, and it aims almost entirely at software and models rather than at facilities and failover paths.

What a defender can actually do

Nothing here depends on believing anything about AGI or about state competition, which is why it is the most useful of the four in this series.

Write the assumption down. Somewhere in your resilience documentation there is a statement about zone independence. Add the clause that says it holds against uncorrelated failure and does not hold against an adversary selecting aim points. That single sentence is the whole intervention, because it turns an unexamined premise into a decision someone has to own.

Run one exercise with an adversary in it. Not a random instance kill. Pick the two facilities whose simultaneous loss hurts most, take them together, and then take whatever you failed over to. The useful finding is almost always the second one: the recovery target was chosen for latency. It is in the same metro, on the same grid.

Look at where your dependencies actually are, not where your contracts say they are. Region names are marketing. The physical question is which buildings, in which jurisdiction, reachable by what. Providers engineer against the shared dependencies they can control, so what you are looking for is the correlations above that line: geography, airspace, jurisdiction, and whether a single actor could reach more than one of your sites. An architecture diagram does not show you any of that, and the physical layer AI runs on is more concentrated than the abstractions suggest.

For AI workloads specifically there is an asymmetry worth exploiting. Inference distributes geographically far more easily because independent requests route among regional replicas, though latency, session state and data residency all still cost something. Training has historically been much more tightly coupled, which is why it concentrates. That constraint is being relaxed as power and accelerator scarcity force the issue. If you run both, they need different resilience arguments and they usually get the same one.

Ask what your provider is contractually committed to. For AWS specifically, the Customer Agreement defines war as a force majeure event and service level agreements exclude force-majeure unavailability from the service commitment. What actually happened in March is instructive: Amazon waived usage charges for both affected regions for the whole month, which is a commercial gesture rather than SLA performance. The operational answer is that recovery is your problem. Anyone whose continuity plan reduces to a provider commitment should read the exclusion clause first.

All four are cheap, and they are rarely done because correlated physical risk is nobody’s job. Infrastructure teams own uptime against the failures they have seen, security teams own the software attack surface, and business continuity owns a document nobody has tested against a scenario this specific. The March strikes exposed that gap at every company running in that region.

Most organisations leave physical consequences of AI failure unowned for the same reason, and nobody is assigned to close it.

A last point on scope. Everything above is about facilities you depend on rather than facilities you own, because almost nobody reading this owns one. That makes the problem harder: you are reasoning about correlation inside someone else’s estate, using region and zone labels that were designed to abstract exactly the detail you now need.

The limit of this argument

There is a version of this piece that turns into a vendor pitch for bunker hosting, and that is not the conclusion.

A cloud customer cannot buy immunity from state-level kinetic attack through ordinary data centre controls. States can defend important sites with air defence, hardening and dispersal, but no cloud contract has a procurement line item for it. If a peer military decides your building is a target, your architecture is not the variable that matters. Dennis Murphy, writing from Georgia Tech after the strikes, made the point that commercial facilities are large, relatively fragile and lack dedicated air defences, and may have been targets of opportunity. The extension is mine: air defence is not a cloud SKU.

Three things are inside your control. Knowing which correlated losses would be survivable and which would not. Not discovering during an incident which correlations your provider left in place, because they were never the hazard it designed against. Having decided in advance whether a region going dark for a month is an outage or an extinction event for your product.

The March strikes did not destroy any models. They destroyed availability, which is a different thing entirely, and that distinction is the most useful result of the whole episode.

Sources checked 5 September 2026.