The cloud is a building. It sounds like a place with no address, somewhere up in the sky where your files float safely forever. In fact it’s a warehouse full of servers on a particular street in a particular country, plugged into a local power grid, cooled with local water, and sitting under the same sky as everything else.
This year, somebody aimed at the warehouse.
On March 1, 2026, Iranian drones struck two Amazon Web Services data centers in the United Arab Emirates, part of Iran’s retaliation for the US and Israeli campaign against it. A facility in Bahrain was damaged too. In September, AWS posted the update nobody in the industry had ever had to write: it can’t restore the data and resources hosted only in its Bahrain region. Whatever customers kept there, and nowhere else, is gone.
I’ve said for a while that a state-funded attack from somewhere like Russia or Iran was a likelier threat than a rogue AI. I also said it wouldn’t necessarily arrive as a cyberattack. This one arrived on a drone.
What happened to the AWS data centers in the Middle East?
The timeline runs from a missile campaign to a permanent outage, in about six months.
From the first drone strikes on AWS in the Gulf to the September notice that Bahrain is lost.
Iran’s first strikes hit the UAE directly. In Bahrain, a nearby strike caused structural damage, cut power and soaked equipment with water from the fire suppression system. On March 31, Iranian state media named American technology companies as targets, among them Microsoft, Google, Apple, Meta, Oracle and Nvidia. On April 1 another drone hit an AWS facility in Bahrain, and the next day Iranian state media claimed a strike on an Oracle data center in Dubai.
That second Bahrain hit took out a second availability zone and the whole region went offline.
On September 15, AWS confirmed the losses. In the UAE, one of three availability zones is gone. In Bahrain, the damage spread across several zones and, in AWS’s words, exceeded what the region’s redundancy design could withstand. AWS said most customers in both regions had moved out before the losses became permanent, using backups where they had them.
Read the last four words of that again.
Why are data centers military targets now?
A backup that lives in the same blast radius isn’t a backup.
Because they’re big, expensive, fixed and fragile, and because hitting one hurts everybody inside it. Jason Vogt and Nina Kollars made that case in June for West Point’s Modern War Institute. A data center depends on the local power grid, water supply and fiber lines, each of them a target of its own. Damage one site and you harm the operator plus every bank, payment platform and business that rents space there, all from a single strike.
A Georgia Tech analysis called the Gulf attacks the first time a country deliberately struck commercial data centers in wartime. Earlier attacks on data centers came through the network. These came through the roof.
The targets are getting bigger. AI training needs enormous power, and companies are building what Vogt and Kollars call digital megacampuses: an 11-gigawatt site in Texas, a 7.2-gigawatt, 13,000-acre site in Montana, a proposed 40,000-acre campus in Utah with its own gas pipeline. They point to new data center hubs in southern Taiwan and in Johor, Malaysia, next to Singapore’s undersea cable hub, as places where a future conflict could turn. I covered the chip and power side of that race in AI data centers and geopolitics.
Europe isn’t out of it. With power expensive and space tight in the south, new construction is moving north: a $10 billion project outside Stockholm, an 840-megawatt Google campus in Norway, new sites in Finnish Lapland. The same analysts warn that Russia could treat those northern sites as targets for sabotage short of open war.
Their conclusion is blunt: data centers are now key terrain, the military term for ground worth fighting over.
Has Ukraine attacked Russian data centers?
Yes, this month, and the Gulf stopped being a one-off.
On October 8, a drone strike set fire to a Yandex data center in Sasovo, about 300 kilometers southeast of Moscow. Yandex, Russia’s answer to Google, said operations there were “completely halted.” One of its cloud availability zones went down, and the company told customers it couldn’t restore service in the near future and to look at other ways to get running again. It confirmed a second data center had been hit. Ukrainian press reported President Zelensky saying Russia had attacked Ukrainian data centers and that Ukraine always answers in kind.
It kept going. By mid-October, according to The Moscow Times, three straight rounds of strikes had disabled half of Yandex’s data centers. On the night of October 13, drones hit a Sberbank data center under construction in Balakovo on the Volga, a project of about $1.4 billion meant to house Russia’s biggest supercomputer. Sberbank said its banking services kept running. Russia, for its part, said it struck a Ukrainian data center the same night.
Two wars, two sets of combatants, and the same target. Whatever side you’re on, the lesson for anyone storing files is identical.
Isn’t the cloud supposed to back itself up?
Partly. What it leaves out just cost people their data.
A cloud provider builds each region out of availability zones, separate buildings with separate power, a few miles apart. That protects you from a fire, a flood or a failed power feed in one building. It doesn’t protect you from a war that hits several buildings in the same city. Bahrain proved it.
The providers also run on what they call shared responsibility. They keep the service running. Extra copies of your data in another region, or with another company, are your job. Plenty of customers learned that this year from a status page.
I learned it years ago from a data center of my own. I ran IT operations for a retailer, and during our worst outage the disaster recovery site was down the same day our backups turned out to be no good. We were out for three days. I wrote about why recovery has to be planned and tested in disaster recovery is part of the transformation, and the Gulf strikes are the same lesson at a scale nobody wanted to see.
The cloud is a building on a street in a country, and this year somebody bombed it. Keep a copy of your book somewhere else. – Richard LoweShare on X
Could a data center attack take my website down?
It could, if your site and its only backup sit in the same place. My own site runs with a host that uses Google Cloud in a single region. If that region went dark for a week, the site would go dark with it, and there isn’t much a small business can do about that short of paying for a second hosting setup somewhere else.
What I can control is the copy. The site backs itself up every night to Backblaze, a different company in a different part of the country. If the host’s region burned down tomorrow, I’d lose some days rebuilding on new hosting. I wouldn’t lose twenty years of writing.
That’s the trade every author with a website should make on purpose. Downtime is annoying and temporary. Lost content is permanent. Ask your host where your site lives and where its backups go. If both answers name the same place, fix that first. My website backup guide walks through the setup.
How should a writer back up a manuscript?
Writers don’t run regions, but we do keep the only copy of things that can’t be replaced. A half-finished novel, a client’s interview recordings, ten years of articles. The old rule still holds: three copies, on two kinds of storage, with one far away. So where does your novel live right now?
Keep one copy where you work. The file on your own computer is the fast one, the copy you open every morning.
Store one with a different company. If your manuscript lives in one cloud service, back it up to another. I use Backblaze for my computer, and my website backs up to Backblaze too, so no single company holds everything.
Put one somewhere far away. Different region, different country if you can. The Bahrain customers who survived had copies outside Bahrain.
Test a restore. Once in a while, pull a file back from the backup and open it. A backup you’ve never restored is a hope, and hope is a terrible recovery plan.
Most of this costs a few dollars a month. If you lose a book you spent two years writing, you’ve lost two years.
My take
The cloud never meant safe. It meant somebody else’s building. I watched a disaster recovery site fail on the worst day of my career, and the Bahrain customers just watched an entire region fail on theirs. The ones who came through had copies somewhere else. Keep your manuscripts in at least two companies and two places, and restore a file now and then to prove the copy works.
Your files live in a building
Check where your work lives today. If every copy of your manuscript sits with one company in one region, add a second copy with a different provider this week, and test it. The Disaster Recovery Hub has more on planning for the bad day, and if you lead a security or IT team with stories like these, here’s how I write books with security leaders.
Somewhere in Bahrain there’s a building full of servers that won’t be coming back, and some of the files that lived there had no other home. Give yours one.
The household version of disaster recovery: how to set up backups that outlive whatever destroys the originals, and what to do in the first hour when something goes wrong.
