When the Cloud Burns: The AWS Strikes, Kinetic Warfare, and What Every Board Needs to Ask Now
PRE-FLIGHT METRICS CARD
FULL ARTICLE
On Tuesday morning, two weeks after the strikes, I got a message from a CISO at a mid-tier New Zealand financial services firm. "We spent eighteen months moving to AWS," she wrote. "We picked the NZ region specifically for data sovereignty. And then we watched AWS burn in the Gulf on a Monday morning and realised: the same company runs both sites. If their Gulf facilities are military targets, what does that mean for our risk profile?"
I told her: it means the cloud was never immaterial. It was always a building. And buildings burn.
On 1 March 2026, Iranian Shahed-136 drones struck three Amazon Web Services data centres in the United Arab Emirates and Bahrain, according to CNBC's reporting on 3 March.[1] Two of three availability zones in AWS's ME-CENTRAL-1 region went offline. Structural damage, fire, power disruption, and water damage from suppression systems were confirmed. Banking, payments, government services, and AI workloads across the Gulf collapsed. The Uptime Institute confirmed this as the first verified military kinetic attack on hyperscale cloud infrastructure in history.[2]
The entire value proposition of cloud computing rests on a single abstraction: that your data is "in the cloud," somewhere, everywhere, untethered from physical constraint and immune to the events that happen to specific buildings at specific addresses. On 1 March 2026, that abstraction came down with the buildings.
The question for every New Zealand organisation running workloads on AWS, Azure, or Google Cloud is not whether this particular scenario will repeat. The question is whether your board has read the clause in your cloud contract that covers it. Or whether you have a contract clause that covers it at all.
The Week the Cloud Became a Battlefield
Let me be precise about the sequence of events, because the facts are stranger than any framework.
On 28 February 2026, US and Israeli forces launched operations against Iran. Two days later, Iran's Islamic Revolutionary Guard Corps struck back. According to Bloomberg's reporting on 5 March, two AWS facilities in the UAE received direct hits from Shahed-136 drones; one in Bahrain was damaged by the blast from a nearby explosion.[3] The IRGC explicitly stated the Bahrain facility was targeted because it hosted US military compute infrastructure.[4]
The cascade was immediate. Emirates NBD, First Abu Dhabi Bank, Abu Dhabi Commercial Bank, the payments platforms Hubpay and Alaan, data cloud provider Snowflake, and ride-hailing platform Careem all reported disruptions.[5] Consumer banking, food delivery, ride-hailing, and government services across the Gulf went dark. As of 11 March, multiple AWS services in the affected region remained unavailable or degraded.[6]
Then came the detail that reframed the entire event.
Multiple news organisations, including Fortune in reporting by Jeremy Kahn on 9 March, reported that the US military had used Anthropic's Claude model, running on AWS infrastructure, for intelligence assessments, target identification, and battle simulations during the conflict.[7] The Pentagon's Joint Warfighting Cloud Capability and Joint All-Domain Command and Control networks run on the same commercial infrastructure that serves banking, healthcare, and ride-hailing. The AI model used for military targeting was running on the same servers hosting civilian banking data. Iran targeted the military compute. Civilian customers were collateral.
The retaliatory strikes followed. Opinio Juris, citing Holistic Resilience airborne-strike mapping, reported that US and Israeli forces struck at least two data centres in Tehran, one connected to the IRGC.[8] Data centres are now demonstrably military targets on both sides of a live conflict.
This is the new landscape. Infrastructure that was "civilian" at 8 a.m. can be "military" by 9 a.m. if the right workloads are co-located on the right servers.
The Hosting Loophole Made Kinetic
In the Space Mafia framework, the Hosting Loophole describes the gap between where data is processed and who bears the consequences. Civil organisations store data in commercial cloud infrastructure, unaware that the same physical racks process workloads for intelligence agencies, defence contractors, or military AI systems. The "loophole" is the absence of meaningful separation between civilian and military use at the hardware layer.
The AWS Gulf strikes are the Hosting Loophole materialised in concrete and fire. Civilian organisations chose AWS Gulf facilities to comply with sovereign data localisation mandates requiring data to remain physically within national jurisdictions. Those mandates concentrated data in the same metropolitan area as US military AI workloads. The compliance strategy created the exposure. The protection mandate produced the vulnerability.
The Space Mafia framework introduced the Three Clocks model to describe the triple tension between physics, regulation, and commercial ambition in orbital infrastructure. The AWS strikes warrant a fourth clock, applied now to terrestrial digital infrastructure:
The Physics Clock. Shahed-136 drones travel at approximately 185 km/h. From launch decision to infrastructure impact, the warning window is measured in minutes. No enterprise disaster recovery plan in the Gulf had accounted for this rate of physical escalation against cloud infrastructure.
The Compliance Clock. Sovereign data localisation mandates forced organisations to host data inside specific geographic regions. Once those regions became active conflict zones, those same organisations faced a new dilemma: migrate data across borders in violation of the regulations that mandated localisation, or hold position and accept extended outage. Compliance law had no war clause.
The Industry Clock. The Gulf Cooperation Council's substantial AI investment commitments, made during diplomatic engagements in 2025, assumed commercially stable infrastructure.[9] That assumption is now under active reassessment. Investment continues; the risk calculus has shifted.
The Conflict Clock. The interval between geopolitical escalation and infrastructure destruction is measured in hours. Operation Epic Fury launched on 28 February. AWS was struck on 1 March. Organisations accustomed to planning in weeks and quarters now face risk that crystallises overnight.
None of these four clocks appeared in standard enterprise cloud risk assessments before 1 March 2026. All four should appear in every such assessment going forward.
The redundancy failure. Multi-Availability Zone architecture is cloud engineering's answer to resilience. The design assumption is that if workloads are spread across three physically separate zones within a region, any single zone can fail without service interruption. The threat model is natural: floods, earthquakes, fires in a single facility.
The threat model is not synchronised kinetic strikes across multiple facilities in the same metropolitan blast radius.
When two of three availability zones in ME-CENTRAL-1 were struck simultaneously, the redundancy architecture provided no protection.[10] Customers without cross-region replication faced extended downtime and potential data loss. Multi-AZ is not multi-region. Multi-region is not multi-provider. And none of those architectural choices address the question of whether your cloud provider's global infrastructure is currently being targeted by a state adversary.
If you have been following the Zero Trust Thursday series, the architecture that failed in the Gulf last week maps precisely to the Lethal Trifecta: the combination of sensitive data access, exposure to untrusted workloads, and the ability to communicate externally. Every compromised AWS facility in the Gulf contained all three. This is what the insider threat architecture looks like when it is built of concrete and copper, not just configuration files. The governance question is identical: what is sharing compute with your data, and what are the consequences of that co-location?
The legal and insurance vacuum. The legal framework for what happened does not exist in any useful operational sense.
The Just Security analysis by Professor Michael Schmitt, published 13 March, identifies the core problem under International Humanitarian Law (IHL): if AWS facilities were being used for military purposes, they qualify as "military objectives" and are therefore legitimate targets under the laws of armed conflict.[11] The simultaneous hosting of civilian banking, health, and government data creates disproportionate collateral harm. But IHL's dual-use doctrine was not written for shared commercial cloud infrastructure hosting hundreds of thousands of civilian tenants.
Standard commercial property and business interruption insurance policies frequently exclude acts of war. The TechPolicy.Press analysis from Mahmoud Abuwasel, published 13 March, invokes the Cuba Submarine Telegraph Company precedent from 1897: when a sovereign state deliberately destroys private infrastructure during wartime, historical precedent makes private-sector claims against belligerents extraordinarily difficult to pursue.[12] Specialised war risk policies exist. They are complex, expensive, and heavily contested by underwriters when claims arise. Most organisations in the Gulf were not holding them.
The Opinio Juris analysis from Professor Luke Moffett at Queen's University Belfast characterised the strikes as likely to qualify as war crimes given the civilian population affected.[13] That legal question may take years to resolve. Your business continuity gap exists now.
The data sovereignty paradox completes the picture. The same sovereign localisation mandates that forced organisations into the region may have been violated by emergency cross-border data migrations during the outage. Compliance law created the concentration. Emergency response may have violated the law that created it. There is no clean exit from this architecture.
NZ Context: From Gulf to Auckland
AWS has invested NZ$7.5 billion in New Zealand, launching the Asia Pacific (New Zealand) Region in September 2025, with three availability zones in Tāmaki Makaurau (Auckland).[14] New Zealand organisations running workloads on AWS include Kiwibank, AMP New Zealand, NZ Post, One New Zealand, TVNZ, the University of Auckland, Wellington City Council, Vector, Sharesies, and MATTR.[15] The New Zealand government operates under a cloud-first policy, with a memorandum of understanding with AWS for cloud skills training at scale.
The AWS Gulf strikes do not directly threaten New Zealand's Auckland-based infrastructure. Auckland is not a conflict zone. The argument is not about immediate physical risk. It is about provider-level systemic risk.
AWS is a single global organisation. Its reputation, financial stability, operational capacity, and supply chain are global. Sustained military targeting of its facilities in other regions is not a localised event. It is a material risk to the provider itself. Every NZ organisation on AWS is co-locating on infrastructure owned and operated by a company that has now been demonstrated to serve military AI workloads alongside civilian banking data. The Hosting Loophole is not a Gulf problem. It is an architectural characteristic of hyperscale commercial cloud.
The GBSI Act dimension. New Zealand's Ground-Based Space Infrastructure Act carries a compliance deadline of 29 July 2026. The Act governs NZ-based satellite ground stations and tracking facilities: exactly the kind of infrastructure that connects terrestrial data centres to orbital systems. If data centres are classified as legitimate military objectives under IHL when they host defence workloads, ground stations that support military satellite operations face an identical dual-use classification question.[16] NZ organisations approaching the GBSI Act compliance deadline should assess whether their infrastructure has characteristics that could attract this classification under the dual-use doctrine as applied in the Gulf conflict.
This is not a direction to non-compliance. It is an observation that the IHL dual-use doctrine now has a live precedent, and compliance planning should account for it.
The CLOUD Act and Te Tiriti. The AWS strikes sharpen the CLOUD Act sovereignty question this series has tracked since its opening article. US-based cloud providers remain subject to American law wherever they operate. During the Iran conflict, US military AI ran on AWS. If NZ data transiting AWS infrastructure was processed on servers simultaneously serving military AI workloads, the CLOUD Act does not merely create a jurisdictional risk; it creates a physical co-location risk.
For organisations holding data on behalf of iwi or whānau, kaitiakitanga, the principle of guardianship and stewardship of taonga, requires that data be protected from exposure it was never consented to. The rights affirmed in Te Tiriti o Waitangi include sovereignty over taonga held in digital form. When the platform holding that data is demonstrably dual-use military infrastructure, the question of data sovereignty moves from theoretical to operationally urgent.
Four questions every NZ board should ask this week.
First: does your cloud architecture account for kinetic military risk to your provider's global infrastructure? If your disaster recovery plan addresses floods and earthquakes but not provider-level military targeting, it is incomplete.
Second: does your business continuity and cyber insurance policy cover service disruption caused by military strikes on your provider's infrastructure in other regions? Standard policies typically do not. Verify this week, not next quarter.
Third: if your cloud provider's facilities are targeted in a sustained military campaign, what is your migration path, and which provider are you migrating to? Note that the three major hyperscalers all serve US military workloads to varying degrees. A migration plan that lands you on a provider with the same dual-use exposure profile does not resolve the risk.
Fourth: have you assessed what NZ-owned sovereign cloud alternatives (SiteHost, Catalyst Cloud) would mean for your dual-use exposure profile? These providers are beyond the reach of US military contracting and the CLOUD Act. That architectural choice now carries a risk weight it did not carry on 28 February 2026. The sovereignty premium may now be justified on pure risk grounds, not just compliance grounds.
Forward Look: What Comes Next
The submarine cable dimension adds a second layer. Reporting from Fortune and Kentik's analysis by Doug Madory notes that 17 submarine cables pass through the Red Sea, carrying the majority of data traffic between Europe, Asia, and Africa.[17] With both the Strait of Hormuz and the Red Sea in active conflict zones simultaneously, both principal global internet transit routes face disruption risk. Madory described the simultaneous closure of both choke points as a globally disruptive event without modern precedent.[18]
The "Don't Look Up" satellite vulnerability findings from this series' second article acquire new significance. The entire data transit path, from orbital connectivity through submarine cable to terrestrial data centre, is now physically vulnerable across all three layers simultaneously.
This creates a business case for orbital compute that is simultaneously more compelling and more complex. If terrestrial data centres are legitimate military targets, the economic rationale for processing workloads in space strengthens. But the TechPolicy.Press analysis notes explicitly that the same dual-use vulnerability follows workloads into orbit.[19] Orbital infrastructure that serves military clients is orbital infrastructure that adversaries can target. The governance gap that Space Mafia identifies does not close by moving the compute higher. It follows the compute wherever it goes.
For readers following the Gen AI Tuesday series: last month we examined why the AI model generating the most commercial enthusiasm was delivering measurable EBIT outcomes for only a minority of the enterprises deploying it. That same model was simultaneously being used for military targeting in a live conflict. The governance gap is not about the model's capabilities. It is about the accountability structures around its deployment and the transparency of what else is running on the same infrastructure. The Heaven Vector is not guaranteed by intent. It requires architecture, governance, and the willingness to refuse certain use cases even when refusal carries commercial cost.
The insurance markets, the legal frameworks, and the enterprise risk registers are all running behind events. Zachary Kallenborn at King's College London, speaking to Fortune, described physical attacks on data centres as likely to become more frequent as AI becomes more strategically significant.[20] That trajectory is already established.
The lesson from the buildings in the Gulf is not that AI is dangerous. It is that unaccountable deployment of AI, without transparency about what else is running on the same hardware, creates liabilities that no standard enterprise risk framework currently captures. Boards that wait for the frameworks to catch up may be waiting in the dark.
Closing
The cloud was never immaterial. It was always concrete, steel, and copper at a specific address. On 1 March 2026, that address appeared on a military target list. That is no longer a hypothetical.
The question I am asking every board I advise this week is straightforward: does your cloud provider's facilities map overlap with any active or emerging military conflict zone? If you do not know the answer, your disaster recovery plan is built on an assumption that 1 March 2026 has already invalidated.
What question are you asking yours?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Space Mafia examines the sovereignty implications of orbital compute infrastructure.
I acknowledge the role of AI tools, such as Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, which assisted in drafting, editing and reviewing. They accelerated the process, but the first draft, revisions, vision, voice and final decisions were mine alone.
References
[1] CNBC, "Amazon says drones hit 3 of its Middle East data centers amid Iran conflict," 3 March 2026.[2] Uptime Institute, confirmation as first military kinetic attack on hyperscale cloud infrastructure, March 2026.[3] Bloomberg, "How Amazon Data Centers Became a Casualty of Iran War," 5 March 2026.[4] CNBC; CBS News, "Amazon says drones struck three of its Middle East data centers," 3 March 2026.[5] Tom's Hardware, "Iranian drone strikes hit three AWS data centers in the UAE and Bahrain," March 2026.[6] AWS Health Dashboard, service disruptions ME-CENTRAL-1 and ME-SOUTH-1, 1-11 March 2026.[7] Fortune, Jeremy Kahn, "Iranian drone attacks on Amazon's Gulf data centers a harbinger of new tactics," 9 March 2026.[8] Opinio Juris, Prof. Luke Moffett, Queen's University Belfast, "AWS in the Cross-Hairs: Data Centres as Targets," 12 March 2026; citing Holistic Resilience airborne-strike mapping.[9] Rest of World, "Amazon Fire in UAE: The End of the Gulf's Safe AI Promise?" March 2026.[10] AWS Health Dashboard; CNBC; Tom's Hardware, March 2026.[11] Just Security, Prof. Michael Schmitt et al., "Iranian Attacks on the Amazon Data Centers: A Legal Analysis," 13 March 2026.[12] TechPolicy.Press, Mahmoud Abuwasel, "The Legal and Policy Fallout from Data Center Strikes in the Middle East War," 13 March 2026.[13] Opinio Juris, Prof. Luke Moffett, "AWS in the Cross-Hairs: Data Centres as Targets," 12 March 2026.[14] AWS, "Now Open: AWS Asia Pacific (New Zealand) Region," September 2025.[15] AWS New Zealand Region launch announcements and customer references, September 2025.[16] Ground-Based Space Infrastructure Act (NZ); Just Security IHL dual-use analysis, 13 March 2026.[17] Fortune, Jeremy Kahn, 9 March 2026; Kentik, Doug Madory analysis, March 2026.[18] Kentik, Doug Madory, as reported by Fortune, 9 March 2026.[19] TechPolicy.Press, Mahmoud Abuwasel, 13 March 2026.[20] Fortune, Jeremy Kahn, 9 March 2026; citing Zachary Kallenborn, King's College London.