Within four days, Yandex disclosed serious damage at two data centers and then reported an unavailable cloud availability zone tied to a third site. The sequence began with a drone attack on the night of Oct. 7–8 that seriously damaged the company’s Sasovo facility in Russia’s Ryazan region and forced a complete shutdown. On Oct. 9, Yandex said another data center in Kaluga had been attacked, knocking part of its infrastructure out of service. By Oct. 11, Yandex Cloud was reporting power interruptions in ru-central1-a; its status page said infrastructure at the Vladimir site had been damaged in a UAV attack and that the zone was unavailable.
For a company whose services are used by millions of consumers and hundreds of thousands of businesses, that is more than a physical-security incident. It is a live test of whether cloud resilience still works when multiple facilities in one national footprint are hit within days.
The real question for customers is not whether outages happen. It is whether the redundancy they bought was truly independent enough for this kind of event. “Multi-zone” sounds reassuring on an architecture slide. It matters much more when power, cooling, staff access, replacement hardware, and network paths all become part of the problem at once.
Three sites, one operational question
In an October 9 statement, Yandex confirmed the Sasovo and Kaluga incidents, said Sasovo had been completely shut down, and said part of the Kaluga site’s infrastructure was out of service. The company also said no employees were hurt, emergency services and specialists were working on site, and it could not yet give a reliable restoration timetable.
The third incident pushed the story from facility damage into cloud-availability territory. On Oct. 11, status incident 2136 said infrastructure at the Vladimir site had been damaged in a UAV attack and that availability zone ru-central1-a was unavailable. The notice said the next update would come on Oct. 12 at 11:00 Moscow time.
Independent coverage filled in some of the operational picture. Al Jazeera, citing AFP and Reuters, reported that Yandex was operating in emergency mode, warned that technical-support communications could also be disrupted, and advised customers to activate their disaster-recovery plans. The Kyiv Independent reported that users saw disruption affecting Yandex Go, Yandex Pro, smart-home services, and internal support systems, while noting it could not independently verify the full extent of every reported outage.
That distinction matters. The public record shows a physical incident propagating into cloud unavailability and customer-facing disruption. It does not show a confirmed breach, data theft, credential compromise, or a total collapse of Yandex’s cloud.
When an availability zone disappears
Cloud resilience is usually described in logical layers: regions, zones, replicas, backups, failover. This week’s Yandex sequence is a reminder that those abstractions depend on very physical things.
A strike, fire, or power event can force a facility shutdown. Once that happens, the blast radius can spread well beyond one room of servers. Compute nodes may vanish first, but storage systems, databases, networking gear, identity services, and control-plane operations can all be affected in different ways. Some workloads may fail over automatically. Others may stall because they depend on storage that must be recovered carefully, or because the application was built to survive a server failure rather than the loss of a site.
That is why an unavailable availability zone is such an important signal. It does not prove every Yandex service failed, or that every customer workload went down. It does show that the provider’s problem is no longer hypothetical. Customers are dealing with a real reduction in available infrastructure, not a warning about elevated risk.
The harder question is what sat behind the redundancy promise in the first place. If a customer replicated only inside one region, shared network paths or control-plane dependencies could still make nominally separate deployments fail together. If healthy capacity exists elsewhere, recovery may be possible, but shifting stateful databases, large object stores, AI checkpoints, and live customer traffic is slower, costlier, and more operationally fraught than vendor diagrams imply.
Yandex’s profile makes that especially consequential. It is both a consumer platform and a cloud and AI operator, so the same physical estate can underpin ride-hailing, delivery, commerce, support systems, and model development. Al Jazeera, citing reporting around the incident, said the Sasovo site hosts two of the three supercomputers used to develop Yandex’s AI model. Even without knowing the full condition of that equipment, the point is clear: concentration risk in physical infrastructure can hit customer applications and strategic compute at the same time.
The checklist customers should use now
The most useful takeaway from the Yandex incidents is practical. Customers should treat this as a prompt to ask not whether their provider has zones, but how independent those zones really are.
- Facility resilience: Are replicas in separate buildings with separate power feeds and network paths? What fire protection, cooling redundancy, physical security, and replacement capacity exist if one site is shut down for days rather than minutes?
- Platform resilience: Does multi-zone also mean control-plane independence? Are backups immutable, recent, and stored outside the affected geography? What are the real recovery-point and recovery-time objectives if a zone disappears?
- Customer resilience: Can workloads move using portable images and documented runbooks? What depends on DNS, identity, or support systems that may be impaired during the same event? Have failover procedures actually been exercised?
There are tradeoffs in every answer. Cross-region replication adds cost and latency. Egress fees can make emergency moves expensive. Data-residency rules can narrow the list of places a workload is allowed to go. Force-majeure language may shape liability, but it does not tell a customer how much data could be lost, how long recovery will take, or who absorbs the operational pain of a rushed migration.
That is the broader lesson from Yandex’s week. Redundancy is easy to advertise in software terms and much harder to prove under physical stress. The important difference is not between a provider that promises availability and one that does not. It is between a recovery plan that exists on paper and one that still works when several sites in the same footprint are suddenly unavailable.
By
By
By
By
