Drone strikes shut two Yandex data centers and degrade Russia’s cloud

8, 9 and 11 October 2026. Three Yandex data centers are hit by drones over three nights: Sasovo on the 8th, Kaluga on the 9th, Vladimir on the 11th. Two down. The Sasovo and Vladimir sites have stopped operating completely; Kaluga runs degraded. “Emergency mode.” Yandex’s status page calls the situation “emergency” and recommends customers use “any other alternative disaster-recovery plans.” Why it matters: for the first time at this scale, a major cloud’s availability is interrupted not by a software fault or a cyberattack, but by physical strikes on its buildings.

An outage unlike any classic incident

The scenario matches none of the usual cloud incidents. No misconfiguration, no dependency cascade, no ransomware: drones physically damaged data centers. Yandex confirms three sites hit, no injuries, and service disruption for its customers — some of whom can no longer access files stored on Yandex Disk. The BBC attributes the attacks to Ukrainian forces, in a conflict where digital infrastructure has become a military target in its own right.

Client-side symptoms resemble a storage outage: users have reported, since 8 October, missing thumbnails on their backups and HTTP 302, 504 and 500 errors when downloading previously uploaded files. The status page lists Console, API, IAM, Container Registry, databases, S3 storage and Kubernetes as available with performance or availability issues; Compute, AI Studio and security services are “partially available,” and Monium remains offline. Yandex gives no reliable restoration timeline and does not say whether any data has been irreversibly lost.

What this changes for cloud architecture

Cloud resilience has long been framed in terms of logical redundancy: multiple availability zones within a region, synchronous replication, automatic failover. The Yandex episode is a reminder that this redundancy does not protect against a threat that hits the building — power, cooling, structure — nor against a threat that targets several sites in the same region within days.

Yandex is often called “Russia’s Google,” and a large share of the country’s internet infrastructure — government and private sector alike — runs on its services. When two of three data centers in a region fall, internal “redundancy” no longer suffices: what makes the difference is the customer’s ability to fail over outside the region, or even outside the provider. Yandex’s own guidance concedes it: “we consider the remaining resource configuration to be unstable,” and it urges customers toward “other disaster-recovery plans.”

The architectural lesson is threefold. Geography is an availability parameter: replicate across distant regions, not just across zones within one region. The provider is a single point of failure: a multi-cloud strategy, however minimal, prevents one vendor from taking down an entire perimeter. Recovery testing must include the physical: a disaster-recovery plan that assumes the provider stays reachable and its staff stay operational does not survive a crisis that also hits its buildings and teams.

What three downed data centers mean in practice

The three sites are not side rooms. Yandex is Russia’s leading cloud provider, and its data centers host both consumer services — Yandex Disk, messaging, mapping — and enterprise workloads. When Sasovo and Vladimir stop and Kaluga runs degraded, an entire region’s compute capacity vanishes at once. The symptoms reported by customers make it concrete: from 8 October, backups lose their thumbnails, downloads fail with HTTP 500, and services like Monium stay offline for days.

The comparison with past physical incidents is instructive. In March 2021, the fire at OVHcloud’s Strasbourg data center destroyed a whole site and some of its data, a reminder that “logical” redundancy does not always survive the loss of the building. The difference with Yandex is one of degree, not kind: this is not an accident, but repeated targeted strikes on several sites in the same region within four days. A recovery plan that replicates within the same region — or assumes the provider stays operational — does not cover this scenario. The only defense that holds is geographic dispersion and the ability to fail over to a provider or infrastructure beyond the reach of the same event. For enterprises that used Yandex Cloud as a single provider, the outage is also a compliance event: regulators in several jurisdictions now expect evidence that critical workloads can survive a provider-level failure, not just a zone failure.

Why the “data center war” will not stay an isolated case

The episode is part of a broader shift. Since the start of the conflict, digital infrastructure — cables, substations, data centers — has moved from “target of opportunity” to strategic target. Ars Technica published a piece the same day with an explicit headline: “Russia was not ready for the data center war it started with Ukraine.” The conclusion reaches beyond the conflict: data centers are now critical infrastructure on par with power grids, and their physical protection is an availability policy, not mere real-estate logistics.

For a CISO or SRE outside a conflict zone, the consequence is quieter but real: site-loss scenarios — fire, flood, physical damage, sabotage — must be folded back into continuity plans, with tested failover thresholds, out-of-region backups and a deliberate dependence on multiple providers. The Yandex outage is the clearest reminder in years that “the cloud” is first concrete, kilowatts and people, before it is APIs.

The practical signal is in Yandex’s own wording. “We consider the remaining resource configuration to be unstable” and “the platform’s operating mode is emergency” are not marketing phrases — they are a provider telling customers that its internal redundancy is exhausted and that no restoration timeline can be promised. That is the moment a disaster-recovery plan stops being theoretical: if your only copy of a database, or your only failover path, lived on Sasovo or Vladimir, there is no “later” in which to recover it. Operators should read this as a reminder to keep backups in a different provider and a different region, to rehearse failover that does not depend on the primary provider’s own control plane, and to treat “the cloud is always on” as an assumption that physical geography can invalidate in a single night.

Verdict

If you run production workloads on a single cloud — and especially if your backups live in the same provider as your workloads — reassess your exposure now: replication to a distant region or a second provider, even partial, changes the outcome of a site loss entirely. If you operate a critical service, test a scenario where your provider is itself unavailable, not just one of its zones: that is the scenario Yandex just lived, and most recovery plans do not cover it. If you depend on a national or regional provider, question its physical resilience — geographic redundancy, power autonomy, crisis plans — as rigorously as you question its logical SLAs. The lesson in one line: a cloud is never more reliable than the building that houses it, and a building can be struck.

References

• BleepingComputer — Yandex confirms service outage as users lose access to cloud files (12 October 2026)
• The Record — Ukraine strikes third Yandex data center, disrupting digital services across Russia (12 October 2026)
• Ars Technica — Russia was not ready for the data center war it started with Ukraine (October 2026)
• BBC News — coverage of the Yandex data center attacks (October 2026)