Yandex Data Centres Hit by Drone Strikes: A Physical Outage

Al Jazeera and The Record reported that drones struck Yandex data centres at Sasovo in the Ryazan region overnight on October 7 and 8, in the Kaluga region on October 9, and in Vladimir overnight on October 10 and 11, 2026. Al Jazeera attributed the strikes to Ukraine, and Ukraine's president described them as a response to Russian strikes on Ukrainian data centres.

Yandex said operations at the Vladimir site were completely suspended and the remaining resource configuration was unstable, and it advised customers to activate disaster recovery plans, according to reports. Services including Yandex's voice assistant, music, video conferencing, smart home, and cloud compute, storage, and database services were disrupted, along with taxi and banking apps reported across Russia, Kazakhstan, Kyrgyzstan, Uzbekistan and Armenia.

The extent of physical damage, the duration of outages, and how many customers lost data or workloads had not been reported in detail. Claims of more than 80 platforms disrupted trace to a Ukrainian-side count repeated by several outlets, and were not independently verified.

Cloud architecture typically assumes availability zones fail independently and regions are rarely lost entirely. Physical attacks, fires, floods, and power failures can take out multiple facilities in a region, especially when they are geographically close. Designs that rely on zones within one region may not survive a regional event.

Advising customers to activate disaster recovery plans assumes they have plans and that those plans work. Regular failover exercises to a separate region, with realistic data and traffic, are the only way to know recovery will succeed under pressure.

Critical workloads should replicate data to geographically separate regions, ideally far enough apart to avoid shared risks. Recovery time and recovery point objectives should be defined and tested, and dependencies such as DNS, identity, and secrets must also be available in the recovery region.

Customers relying on a single provider for compute, storage, and managed services face correlated failure. Multi-cloud or hybrid strategies add complexity but can be justified for critical services, especially in regions with elevated physical or geopolitical risk.

Data centres are increasingly treated as strategic infrastructure in conflicts. Organisations operating in or depending on infrastructure near conflict zones should factor physical threats into risk assessments and location choices.

When a provider reports facility loss, responders need quick answers: which workloads ran there, which have replicas elsewhere, and what manual steps recovery requires. Maintaining an inventory that maps workloads to regions and zones makes those answers immediate.

Provider status pages may lag or understate impact. Customers should monitor their own services, communicate with their users independently, and avoid waiting for provider confirmation before invoking recovery.

Strikes reported on October 9 at Sasovo, October 10 in Kaluga, and October 11 in Vladimir, 2026.

Regions are physical places. Replicate across distant regions, test failover, and map workloads so recovery starts in minutes, not days.

The specific conflict is local, but the lesson is general: concentrated physical infrastructure can fail together. Wildfires, floods, grid failures, and accidents have taken down facilities elsewhere. Any organisation should know whether its critical workloads would survive the loss of an entire region.

Recovery often fails on hidden dependencies: a DNS zone hosted in the affected region, identity services or secrets stores without replicas, container registries in one location, or deployment pipelines that cannot run when the primary region is down. Map these dependencies and test recovery with the primary region fully unavailable.

When a provider loses a facility, users experience your outage, not the provider's. Post status updates early, explain what is affected, and give expected recovery steps. Waiting for the provider's root cause before communicating leaves users guessing.

Define recovery time and recovery point objectives per service, and test that your architecture meets them with the primary region unavailable. Many teams discover during real events that their objectives assumed a partial outage, not a full regional loss.

Damage extent and outage duration had not been fully reported by Yandex or by independent sources at the time this was written.

Review your own regional failover plan this quarter.