Quick Answer: Data center drone attacks are strikes on server facilities using relatively light explosive payloads, which can knock out power, cooling, and servers for months. In October 2026, Ukrainian drones hit three Yandex sites plus facilities for Sberbank and VKontakte, disrupting banking, ride-hailing, and cloud services across Russia. The lesson: concentrated infrastructure fails together.
Most coverage of Ukraine's drone campaign centers on oil refineries and fuel shortages. The quieter story is about data centers. Between October 8 and October 18, 2026, drones struck facilities tied to Yandex, Sberbank, and VKontakte, and Russian users reported lasting disruption to everyday services. Data center drone attacks expose a gap in how most organizations plan resilience: a building full of servers is a soft target, and the more you concentrate in one place, the more a single hit costs.
What Happened to Russia's Data Centers
AP reporting, published through Fortune, describes a sequence that looks more coordinated than a string of random hits. Yandex runs search, cloud storage, payments, and ride-hailing across Russia and many former Soviet states. It operates six data centers. Three of its key facilities were hit over four days, and its drills had only prepared it for losing one.
Here's the timeline as reported:
- October 8: The Yandex data center attack in Sasovo, Ryazan region, hit a site housing two of the company's three supercomputers.
- October 9: A data center in Kaluga was struck.
- October 11: The Vladimir facility was hit.
- October 14: Sberbank's data center and AI hub in Balakovo, Saratov region, was struck.
- Four days later: A VKontakte data center in St. Petersburg was hit.
The companies have been coy about the damage, so the full extent is still unclear. What's documented is the operational effect: interrupted cloud services, disrupted banking, and arbitration courts reportedly cancelling or postponing sessions. Treat any specific recovery timeline as provisional until the operators say more.
The sequence matters more than any single hit. Here's where it gets interesting: a campaign that moves from site to site in quick succession tests whether your failover plans assume one failure at a time.
Why Data Centers Are Softer Targets Than Refineries
Refineries are large, partly hardened, and heavily defended. Data centers are easier in one crucial way. They're built for uptime, not blast resistance. AP notes that lasting damage can come from a drone carrying a relatively light load of explosives. You don't need to demolish a data center. You need to damage the power feed, the cooling plant, or the switchgear between them.
The failure chain usually runs in a predictable order:
- A drone damages an incoming power feed or the switchgear that distributes it.
- Uninterruptible power supplies carry the load for minutes while backup generators start.
- If the same strike hits a chiller or cooling loop, heat climbs fast in a dense server hall.
- Operators shed load or shut racks down to protect the hardware.
- Replacement transformers, specialized parts, and qualified technicians become the bottleneck. That's why recovery can stretch to months.
Step five is the part planners underestimate. Most business continuity plans assume you can get a replacement part in days.
The Uptime Institute's Tier classifications measure redundancy, such as N+1 or 2N power and cooling paths. They are built around the assumption that component failures are random. A coordinated strike across several sites doesn't look like random failure. A facility with 2N power still shares a grid connection, a regional network path, and a local workforce with its twin across town.
Iran's drone strikes offered a preview. AP reports that Iranian drones hit two Amazon Web Services data centers in the United Arab Emirates and one in Bahrain. AWS said it was unable to restore access to the resources and data hosted at two of them. The counter-intuitive lesson: more redundancy inside one building can create false confidence if every copy sits in the same blast radius.
That said, the physics only explain half of the problem. The other half is policy.
The Sovereignty Paradox
Most guidance treats data sovereignty as a control measure. Keep data in-country, and you control access, satisfy regulators, and reduce foreign exposure. That's sound for jurisdiction. It's incomplete for resilience.
Russia's situation shows the trade-off. Moscow's strict digital sovereignty policy requires all data storage at home. Ukraine, by contrast, stored critical data on servers in allied European countries, which limited the damage from Russian attacks. Nick Reiners, senior geotechnology analyst at Eurasia Group, put it plainly: “Because all the infrastructure and all the data is located inside Russia, it's relatively easier to take down.”
Mikhail Klimarev, head of the Internet Protection Society, predicted that many top Russian companies will move computing assets abroad, likely to Europe, and that authorities may ease internet controls as a result. Whether that happens depends on policy still in motion, so treat it as a forecast.
Here's the practitioner's point. Data residency is a jurisdiction constraint, not a resilience strategy. You can satisfy residency rules and still avoid concentration by spreading workloads across facilities separated by distance, grid, and network path. The mistake is treating one country as one failure domain.
This next part trips people up every time. Residency and resilience pull in different directions, so you have to design for both explicitly.
When One Platform Is Everything
Yandex is the clearest illustration. Reiners described it as “kind of like Uber and Amazon and Google and everything rolled into one,” with services “concentrated in just a few data centers.” That concentration makes commercial sense. Running payments, search, geolocation, and cloud on shared infrastructure is cheaper. It also means one strike can paralyze unrelated services at the same moment.
The effects reached ordinary users. Moscow resident Igor Mann couldn't collect a Yandex Market order, and said a VPN didn't help. Taxi driver Pavel Belyavskiy couldn't reach passengers and cancelled rides. Businesses relying on Yandex cloud reported temporary disruptions, and the fallout reached arbitration courts. Alisa, Yandex's virtual assistant, and multimodal AI chatbots also suffered lasting disruption.
Yandex said it restored most key cloud services within days by shifting to other data centers in Russia. That's both reassurance and warning. Failover worked, but only inside the same national footprint, and only after the damage was felt widely.
Why does this keep happening? Teams optimize for cost and latency, then draw failure domains around buildings instead of regions. Yandex's drill covered losing one of six sites. The real event took out three key facilities in four days.
Comparing Resilience Strategies
No option here is free. The table below compares common approaches against the failure modes this attack exposed.
| Strategy | Protects against | Main weakness | Typical recovery pattern |
|---|---|---|---|
| Single site with on-site generators | Grid outages, short power dips | One strike on power or cooling takes the whole site down | Often months if switchgear or cooling is damaged |
| Multiple sites in one country | Single-facility failure, fire, localized outage | Shared grid, shared regulation, and shared air defense gaps | Hours to days if spare capacity exists, as Yandex found |
| Active-active across allied countries | National shutdown orders, regional conflict | Latency, cross-border data rules, higher cost | Minutes to hours, depending on replication design |
| Offline or cold backups | Ransomware, total site loss | Slow restores and stale data | Days to weeks for a full restore |
Use this as a framework, not a benchmark. Measure your own recovery time objective before choosing. Spreading across sites in one country is a reasonable middle ground for most enterprises, but it doesn't protect you from a national-scale event.
How to Protect Your Own Infrastructure
Most readers won't face drones over their facilities. The same logic still applies to correlated failure from regional power events, fiber cuts, or a single cloud region outage. Start here:
- Map dependencies to physical sites, not just to services. Know which applications share a building, a power feed, or a network carrier.
- Write down your failure domains and state which ones your architecture can survive losing.
- Test regional loss, not just single-host failure. Practice losing a whole site under production-like load.
- Keep a copy outside your primary legal and geographic footprint, within the limits of your residency rules.
- Verify restores, not just replication. A perfectly replicated corrupted database is still corrupted.
Physical measures such as standoff distance, perimeter detection, and separate utility feeds reduce risk. They don't eliminate it. Air defense alone isn't a plan. Reiners noted that Russia must cover a vast territory with limited air defenses, which is a national problem most companies can't solve. Focus on what you control. For a step-by-step runbook, see our disaster recovery planning checklist.
Most people stop here, but the hard part is the testing. Writing a failover plan takes an afternoon. Proving it works under load takes weeks.
Frequently Asked Questions
What are data center drone attacks?
Data center drone attacks are strikes on server facilities using drones that carry explosives, often light payloads. Attackers usually target power feeds, cooling systems, and switchgear rather than servers, because damaging supporting infrastructure can take a site offline for months. Ukraine has used this tactic against Russian sites, and Iranian drones hit AWS facilities in the Gulf.
How do you protect a data center from drone attacks?
Start with physical measures: standoff distance, perimeter detection, and power and cooling feeds that don't share a single route. Then design for losing the whole site. Replicate critical services to facilities on separate grids and in separate jurisdictions, and test that failover under load. Air defense helps, but it can't guarantee protection across many sites.
Why are data centers vulnerable to drones?
Data centers concentrate servers, power, and cooling in large buildings that aren't designed to withstand explosives. A relatively light payload can disable the systems that keep servers running. Internal redundancy often shares the same weak points, so coordinated strikes across several sites can overwhelm backup plans built for random component failure.
Does data sovereignty make data centers safer?
Not automatically. Sovereignty rules govern where data lives and who can access it, not how resilient it is. Russia's requirement that all data stay at home left its infrastructure concentrated within reach of Ukrainian strikes, according to AP reporting. Sovereignty and resilience need separate planning, usually across multiple facilities within the permitted jurisdiction.
Final Takeaway
The most useful lesson is simple: a plan that survives one building going dark isn't the same as one that survives losing a region. Data center drone attacks are an extreme case, but the logic applies to any shared failure domain. Map your three most critical services to physical sites this week and count how many share a single one. Then read our breakdown of multi-region failover architecture next, and pass this along to whoever owns your disaster recovery plan.