Yandex Data Center Attacks: What the Outages Mean for Resilience

What happened to Yandex data centers

The sequence, as reported, covers four days:

• Sasovo, Ryazan region, 8 October. Yandex Cloud reported power problems in zone ru-central1-b. According to iStories, citing RBC and the company, a fire affected part of the site and its work was fully stopped, with no injuries. The Record reported that Yandex warned the ability to create new cloud resources "may currently be limited," and that NetBlocks saw Yandex's network fall to about 70% of normal levels.
• Kaluga, 9 October. In its message, quoted by RBC, Yandex wrote that an attack hit another of its data centers, several modules were completely knocked out and recovery times were very hard to estimate.
• Vladimir, 10 to 11 October. SecurityLab quotes Yandex confirming that a drone attack damaged the Vladimir data center, which was then shut down. Yandex Cloud moved to an emergency mode, called the remaining configuration unstable, and said compute capacity remained only in zones ru-central1-d and ru-central1-e. Yandex Go taxi ordering failed in Russia, and the Kyiv Independent reported similar disruption in Serbia, Kazakhstan, Belarus and Armenia.

Who carried out the strikes is a separate question. Yandex does not name a party. The Record describes the Sasovo strike only as a reported Ukrainian drone attack, notes that Ukraine's military had not commented and that it is unclear whether the data center, the machine-tool plant that houses it, or both were the target. Ukrainian President Zelensky said on 8 October that Ukraine always responds in kind to Russian strikes on its data centers. Treat attribution as media reporting, not a confirmed finding.

How many Yandex data centers were damaged?

Three. Sasovo and Vladimir were stopped completely, and Kaluga lost several modules, according to T-Journal's summary of Yandex statements. The total number of large Yandex data centers is reported differently: The Register says Yandex has five Russian data centers and three were hit, while the Moscow Times says three of six. We found no published total from Yandex, so read the answer as "three of five or six".

What changed between 11 and 18 October

• 11 to 12 October. Yandex described its cloud as operating in a limited mode and said it could not give a precise restoration timeline. NetBlocks put Yandex Cloud connectivity at 30% of normal on 11 October, a different date and measure from the 70% figure for 8 October above (The Register).
• 11 to 14 October, services return. From the evening of 11 October Yandex reported Alice, search, maps, taxi and mail coming back. Yandex Pay partly restored transfers and payments on 13 October, and bulk download in Yandex Disk was still switched off on 14 October (T-Journal).
• 13 October, fees waived. Yandex Cloud usage from 8 to 31 October is not billed, Yandex 360 fees are waived for personal plans, and Yandex Pay waived late fees. The company's shares fell by 77 billion rubles (5.4% of market value) over two trading days (Moscow Times). Waived fees are not an SLA payout, and we found no announcement of SLA compensation.
• 14 October, other operators hit. A Sberbank data center in the Saratov region was attacked overnight; Sber said staff were unharmed and services ran normally (T-Journal).
• 18 October. VK's press service confirmed a drone attack on a VK data center in the Leningrad region and said VK services were available as usual, while users reported disruptions (URA.ru).

Recovery estimates. Yandex has given no restoration date. Outside commentators differ widely: a Moscow State University deputy director quoted by T-Journal expected the core of client services to stabilise in two to three weeks, which is his estimate, not Yandex's. We found no report that zones ru-central1-a or ru-central1-b had returned to service.

What about Yango? Yango is Yandex's international ride-hailing and delivery brand, which grew out of Yandex Taxi and is run from Dubai, per Wikipedia. We found no credible report of Yango disruptions outside Russia. The reported foreign disruptions concern Yandex Go, for example in Serbia, Kazakhstan, Belarus and Armenia. Whether Yango's servers depend on the affected data centers has not been disclosed, so we claim neither impact nor its absence.

Were cyberattacks ever the cause?

The famous cyber incident is the 2021 DDoS. In a joint post, Yandex and Qrator Labs reported that load grew to almost 21.8 million requests per second on 5 September 2021, an application-layer attack using HTTP pipelining from a botnet made mostly of MikroTik routers, named Mēris. Yandex said it neutralised the attack and prevented a denial of service, with services not affected. That account comes from the two companies involved, so independent confirmation of the peak is thin.

Other widely discussed incidents were not infrastructure failures: the September 2022 taxi traffic jam was a flood of fake orders, and the code and data leaks were attributed to insiders. The pattern matters. A cyberattack on a provider this size is mostly absorbed by layered defences, while a kinetic strike hits a layer no firewall touches. If you want the background on attack types, read our DDoS attack definition and the guide to DDoS protection for small businesses.

Why most outages come from inside

The best-documented large Yandex outage of recent years was not an attack. On 30 March 2025, according to Yandex's own postmortem, a fault at a substation disconnected both 110 kV power lines at once. The diesel units were not sized to take the full load, restarting systems after the blackout was a manual process that needed an engineer on site, and re-energising the substation needed approval from the grid dispatcher. The zone took roughly 11.5 hours to recover.

That matches the industry picture. The Uptime Institute's 2025 outage analysis says power remains the leading cause of impactful outages, IT and network problems reached 23% of them in 2024, and about two-thirds of publicly reported outages over nine years involved third-party providers. For most operators the likelihood ranking is therefore internal faults first, third-party failures second and deliberate attacks third. Only the last gets the headlines.

What it means for security

First, the threat model now includes physical strikes on data centers, which you cannot defend against yourself. What you can control is exposure: know where your provider's sites are, what they sit next to, and how many of your services depend on a single building.

Second, cyber controls still matter, but for different reasons. The leaks associated with Yandex were insider problems, which is why least privilege and access logging are cheaper than any perimeter tool. Third, monitor outbound traffic and provider status, because during a regional failure you will see symptoms (timeouts, rising latency, failed deploys) long before an official statement. Our monitoring guide shows how to alert on them, and the breach response guide covers what to do when you cannot tell an outage from an attack.

DDoS protection: volume versus application layer

Yandex Cloud's documentation draws a useful line. Its basic DDoS Protection covers layers 3 and 4, such as SYN floods and UDP amplification. It is not designed to protect against higher-layer attacks that use valid TCP connections and HTTP requests, which needs the extended, partner-provided protection (the service is offered with Curator, formerly Qrator). In other words, even a giant provider separates volume from application logic.

The same split applies to you. Volumetric floods are a capacity problem: Cloudflare reported a record 31.4 Tbps attack in its Q4 2025 report, which lasted 35 seconds and was mitigated automatically, a scale no single VPS can absorb, so buy that from a provider with the capacity (see volumetric attacks). Application-layer floods are a logic problem you own: rate limiting, caching, a WAF and graceful degradation. For current attack numbers, see our DDoS report for small businesses.

One more lesson sits in the same week. On 8 October 2026 Curator had a 34-minute network failure that made sites of large Russian media slow or unreachable, and Curator attributed it to human error during a configuration change, with no confirmed link to the Yandex incident, per SecurityLab. A DDoS protection provider is itself a dependency, so you need a rehearsed way around it.

What it means for resilience

Yandex's own guidance is that customers should build multi-zone architectures, and its postmortem calls the loss of one data center the baseline case. October shows the limit of that advice: three sites in four days left only two of the cloud's general-purpose zones with compute. Multi-zone protects against a failed building. It does not protect against several failures in one provider, against capacity pressure on the survivors, or against provider-wide limits.

Those limits appeared quickly. After the first strike, SecurityLab reports, quota management was switched to manual to preserve capacity for critical systems, and Yandex recommended that affected customers move to other providers. Treat the lessons as requirements:

• Do not rely on creating resources during a disaster. Keep a warm standby, prebuilt images and infrastructure as code that can run at a second provider.
• Read the SLA as a financial tool. Yandex Cloud's Compute SLA sets 99.95% for a single VM, offers 10% to 30% compensation depending on the shortfall, and excludes DDoS and circumstances beyond Yandex's control. How it applies to these events is a legal question we cannot answer.
• Keep backups outside the provider. A copy in the same zone or account is not a copy. Follow the 3-2-1 rule with one copy elsewhere, as in our backup strategy guide.
• Test power and cold start. Yandex's postmortem says it will keep running drills that simulate losing a data center. If you own or colocate hardware, check that generators can take full load and that restarts do not depend on a single person.
• Use a zone-evacuation tool. Yandex describes Zonal Shift as a way to cut load balancer traffic to a zone quickly. The principle applies anywhere: practise draining a failed location before you need it.

A 15-minute exposure check for your own servers

Use the quick-win list above as a first pass, then record the answers in one table: service, provider, zone, backup location, DDoS provider and bypass plan. Any row where two critical services share a zone, or where the backup lives with the production data, is your first fix. Add a low-cost second provider for the most important service, set DNS time-to-live low enough to switch, and schedule one failover rehearsal per quarter. The VPS security checklist is the baseline to complete before this, and the ransomware protection guide covers the backup side in more depth.

If you run a plain VPS at one provider, the practical minimum is simple: encrypted off-provider backups, a documented rebuild procedure and a tested way to restore service elsewhere.

What we still do not know

As of 18 October 2026 we found no detailed official postmortem and no official restoration timeline, and the state of customer data in the damaged zones and of Yandex's supercomputers has not been publicly confirmed (Yandex has not commented on the latter, per T-Journal). The mapping of zones to cities (for example ru-central1-b to Sasovo) comes from media reports, not Yandex documentation. RBC, as relayed by other outlets, reported that Yandex added force majeure wording covering drone attacks to its user agreement, which Yandex described as standardising its terms. We could not open the original, and it is not shown to apply to Yandex Cloud contracts. Reports of a further attack near Vladimir on 16 October were not confirmed by Yandex, and an alleged earlier strike in May 2026 and counts of affected services remain unverified. We will update this page when Yandex publishes its own analysis.