Before dawn on 1 March 2026, drones struck two Amazon Web Services data centres in the United Arab Emirates. The strikes disabled two of the three availability zones in the UAE region (ME-CENTRAL-1) and one zone in Bahrain (ME-SOUTH-1); a second wave of disruption hit Bahrain weeks later. AWS reported structural damage, power loss, fire, and water damage from suppression systems. For roughly 17 hours, around 60 AWS services degraded or went dark — and with them, Emirates NBD, First Abu Dhabi Bank, ADCB, Careem, Snowflake, and a long tail of payments and enterprise platforms across the region. The Islamic Revolutionary Guard Corps claimed responsibility, and at the end of the month named a list of US technology firms it considered “legitimate targets.”

There is a war behind those facts, with human costs that a compliance note is not the place to weigh. Our remit is narrower and specific: we advise the companies that have to keep operating through it. And from that seat, 1 March was not merely an outage. It was a live demonstration of a governance problem that the Gulf’s cloud-and-AI ambition has been carrying, unmodelled, for years.

Redundancy is not resilience when the zones share a threat

The standard answer to cloud availability is the multi-AZ deployment: keep replicas in separate data centres within a region, so the failure of one zone is absorbed by the others. It is sound engineering against the failure modes it was designed for — a fire, a power fault, a flooded floor in a single building.

It assumes those buildings fail independently. On 1 March they did not. Two of three zones went down inside the same window, from the same cause, and the redundancy model that most architectures quietly depend on failed with them. The lesson is not that multi-AZ is wrong; it is that correlated risk breaks it. When your availability zones sit inside the same threat radius, they are not three independent bets. They are one.

Concentration risk is the quiet default of every cloud strategy. The Gulf strike is what it looks like when the default is tested.

The data-localisation trap

Here is where an availability problem becomes a governance problem.

When the zones went down, the textbook response was immediate: fail over to another region. Move workloads and data somewhere the drones are not.

For a great deal of Gulf data, that instruction is not available — because the law forbids it. GCC states have built data-localisation mandates that require sensitive public-sector and regulated data to be stored inside national borders. Localisation was a deliberate sovereignty strategy, and on its own terms it succeeded. But sovereignty and resilience pull in opposite directions in a crisis: the same rule that keeps your data in-country also concentrates it there, and removes the one lever — geographic failover — that business-continuity plans lean on hardest.

This is the tension every regulated operator in the region now has to resolve on paper, before the next event, not during it:

  • Which of your data cannot legally leave the country? That subset has no cross-border failover. Its continuity has to be solved inside the jurisdiction — multiple providers, sovereign cloud, on-premise fallback — or it is not solved at all.
  • Which data can move, and where to? For everything not bound by localisation, a genuine multi-region posture is available. Most organisations have never drawn the line between the two, so in a crisis they treat all of it as if it were stuck.
  • Does your provider even offer in-country diversity? Localisation limits providers to a handful of physical sites per market. “Multi-region” may not exist as an option for data that must stay put.

This is third-party risk — with a dimension your programme never modelled

Strip away the geopolitics and 1 March is a concentration-and-third-party-risk event of the most ordinary kind: a critical vendor, a single point of dependency, an outage that cascades into your operations. What is new is the failure mode. Business-continuity and TPRM programmes model cyber intrusion, provider insolvency, misconfiguration, and region-wide cloud faults. Very few have ever modelled physical, kinetic damage to the data centre itself — and fewer still have modelled it happening to two zones at once.

That gap is now visible, and it is the work:

  1. Map your concentration honestly. Not “we use AWS,” but which workloads, in which zones, in which region, with what recovery path if two of three zones are gone. If you cannot draw this in an afternoon, that is the finding.
  2. Reconcile residency against failover. Classify data by whether it can legally leave the jurisdiction, and design continuity for each class separately. The localised class needs an in-country answer.
  3. Test business continuity against infrastructure loss, not just cyber. Run the tabletop where the data centre is physically gone, not merely breached. Recovery-time objectives written against a soft failure are fiction against a hard one.
  4. Put an exit and a second provider on the table. Concentration risk is only manageable if leaving, or splitting, is a real option you have priced and rehearsed — not a clause no one has ever exercised.
  5. Own it at board level. Under NIS2 and the region’s own resilience expectations, continuity of critical services is a management-body responsibility. After 1 March, “we assumed the cloud would stay up” is not a defensible position.

The ambition is not going away — the question changed

None of this means the Gulf’s AI build-out stops. Analysts expect the strategic projects to continue; the sovereign commitment to becoming an AI hub is deeper than any single quarter of disruption. What has changed is the question being asked of it. For two years the question was how fast can we build. Since 1 March, for anyone accountable for operating on top of that infrastructure, it is how well can we survive a bad day — and whether the sovereignty rules that made the region attractive have quietly concentrated the risk they were meant to control.

That is not a geopolitical question. It is a governance one, and unlike the war, it is answerable now.

If you operate on GCC cloud infrastructure and want an honest read of your concentration and residency exposure, that is exactly the kind of scoping we do in a first conversation.