Data centers are military targets now. Not in theory, not in a tabletop exercise. In practice.
CNBC reported that Yandex, the company most people call the Google of Russia, shut down one of its key data centers after a Ukrainian drone strike. The facility in Sasovo, in the Ryazan region, caught fire, and Yandex said it stopped operating entirely. Nobody was hurt. Some services went down with it.
That didn't come out of nowhere. Russia has spent months hitting Ukrainian telecom and data infrastructure, because if you knock out the carriers you knock out communications, and that has obvious military value. Ukraine's answer was basically: fine, two can play. Earlier this year, reports out of the Gulf described Iranian strikes damaging AWS facilities in Bahrain and the UAE badly enough that some customer data was reportedly lost for good.
A few years ago, if you said data centers would get hit in a war, people rolled their eyes. I know, because I was one of the people saying it.
Replication doesn't help if everything burns
The AWS story is the one engineers should sit with. Cloud providers organize the world into regions. Inside a region, your data gets copied across racks and across separate facilities, so if a rack dies or one building goes dark, you're fine. That model works great for hardware failure, power outages, a backhoe cutting a fiber line.
It does not work when an attacker takes out several facilities in the same region at once. If the primary goes, the replica goes, and the backup goes, it doesn't matter how elegant your replication strategy was. You designed for things breaking randomly. War doesn't break things randomly. It breaks them on purpose, in clusters.
We already solved this once, then forgot
I used to run telephone systems. The old phone network routed everything through central offices. Lose a central office and a huge chunk of calling capacity vanished instantly, because there was nowhere else for the traffic to go.
The whole point of ARPANET and later TCP/IP was to kill that weakness. Build a network where any node can die and traffic just finds another path. A friend of mine was a network engineer whose company had gear in the basement of the World Trade Center. On 9/11 he watched the towers fall on TV, then watched his dashboards as traffic rerouted around the dead equipment in real time. The protocol did exactly what it was built to do.
Then the Cold War ended and we relaxed. We kept the distributed protocols but went right back to building centralized infrastructure. Giant facilities. A handful of providers. A few hyperscale regions carrying a ridiculous share of the world's workloads. Same single points of failure we spent decades engineering away, just with nicer branding.
The people building this have never thought about war
Think about the families that come from a long line of veterans. Generation after generation of people who put their lives on the line for this country, and a lot of them who never made it home. The adults in those families understood violence. It wasn't abstract to them. It was something you planned for.
That's rare now. Only a tiny slice of Americans have ever worn a uniform, and that includes the architects designing our infrastructure. Smart people, 35 or 40, kids and a mortgage. The idea of a deliberate attack on their facility, or a mass casualty event, just isn't part of how they think.
I see it when I talk to startup founders. I'll ask about their counterintelligence posture and they laugh, like I asked whether they've prepped for alien invasion. It's not a joke question. It's the question the next decade is going to ask whether they like it or not.
Resilience is built for the threats you imagined
Look at a hyperscale data center next to a single drone and your gut says one hit can't take the whole thing down. These buildings are packed with redundancy: backup power, failover cooling, fire suppression.
But that redundancy was designed around the risks people pictured when the building went up. Equipment failure, yes. A storm, sure. Someone aiming at the weakest shared system on the site, not so much. There was a case in the US Southwest where a small problem tripped the fire suppression system, it went off across the whole facility, and the entire data center went down. One minor issue, total outage, because the protection itself had no compartments.
That's the pattern. You rarely have to destroy a data center to stop it. You only have to hit whatever everything else depends on: power intake, cooling, the network handoff. Add the fact that some new facilities are going up fast in fabric-skinned industrial structures to save time, and you start to see how much of this was optimized for speed and cost, not for a bad day.
And you can't easily retrofit any of it. These are billion-dollar capital projects. Realizing in 2026 that your building isn't hardened doesn't mean you can harden it.
What to actually do about it
You can't harden Amazon's buildings. You can stop pretending they're invincible.
- Know where your stuff physically lives. Write down which regions and providers run your apps, databases and backups. If you can't point to it on a map, you don't understand your risk.
- Treat a whole region as one failure. Multi-AZ is not disaster recovery. Keep a copy of critical data in a second region, ideally on a different continent, and test restoring from it.
- Keep one backup outside your main provider. Different cloud, different account, different credentials. If your provider has a very bad week, you still have your data.
- Write down your geopolitical exposure. If a region sits near an active conflict or a shipping chokepoint, that belongs on your risk register next to ransomware and outages.
- Have a plan for when Zoom and Slack are gone. Lots of companies went remote, shrank their offices, and now can't operate without a few SaaS tools. Agree in advance on a fallback channel and a phone tree.
- Run the drill. Pick a Friday and ask: our primary region is gone, what happens? Time how long recovery really takes. The first run is always ugly. Better now than for real.
- Ask your vendors the awkward questions. Where are your facilities, how do you fail over across regions, and when did you last test it? Vague answers are an answer.
- Teach your developers the cloud is a building. Somewhere there's a physical machine running their code, with a power line and a cooling loop. Engineers who picture that make better decisions.
Over there won't stay over there
Americans have always had two oceans as a moat, so whatever happens abroad feels like it stays abroad. But first the Gulf, then Ukraine, now Russia. Europe's facilities are a lot closer to the fighting than Virginia's. And the global economy runs on all of it.
We hear constantly that data is the new oil. Fine. Then expect it to be targeted like oil. The people attacking shipping lanes know exactly what they're doing, and the infrastructure that carries our data is just as exposed.
I don't think this gets better. I think it gets worse. The only real question is whether you planned for it before it happened to you.
So tell me: do you know where your infrastructure physically sits? And does your team?