Yandex said Friday that a drone attack damaged infrastructure at its data center in Kaluga, Russia, disabling several modules as the company assessed the full extent of the damage. The report makes Kaluga the second Yandex data center reported damaged in two days, but does not establish a service outage tied to this incident or damage to AI computing equipment there.
Yandex warned that some services could be disrupted, but did not name any affected services or provide a repair timeline in the reports reviewed. The company’s public cloud status page continues to attribute an availability-zone outage to a fire at its Sasovo data center, not to the Kaluga damage.
The Kaluga report follows Thursday’s fire at Sasovo, which led Yandex to suspend operations at that site. Our earlier report on the Sasovo incident covered the cloud disruption and the uncertainty about equipment there.
What damage has Yandex reported in Kaluga?
Yandex said damage to infrastructure at its Kaluga data center left several modules disabled and that it was still assessing the damage, DatacenterDynamics reported. Meduza also reported the company’s account of the disabled modules. Yandex did not give an exact number or describe what equipment they contained.
That leaves basic operational questions unanswered. The reports do not say how much capacity was lost, whether the modules handled customer workloads, or whether a service has been confirmed as affected by the Kaluga incident. The company’s warning describes a possible effect, not a confirmed list or scale of interruptions.
DatacenterDynamics lists five large Yandex data centers in Russia: Vladimir, Sasovo, Ivanteevka, Mytishchi and Kaluga. Its report places Kaluga about 480 kilometers from Sasovo. The two reports therefore concern distinct facilities, with incidents reported on successive days.
The count of sites does not show how much spare capacity Yandex can draw on, or whether workloads can move between facilities without interruption. The reports reviewed do not provide figures for available capacity or a detailed account of how the Kaluga modules were used. Yandex has described workload transfers in response to Sasovo’s outage, but has not specified a comparable response for Kaluga.
Which Yandex services are known to be affected?
Yandex’s cloud status page says the ru-central1-b availability zone remains unavailable because of the Sasovo fire. Yandex’s status update says it shifted workloads to other zones and warned that creating new resources could be limited.
Those status details concern Sasovo. They do not show that Kaluga caused, extended or worsened the ru-central1-b outage. The reporting reviewed here also does not identify a separate service interruption linked to the Kaluga damage.
For cloud customers, the distinction matters: a warning that disruption is possible is not the same as a confirmed interruption to a named service. Yandex has not said which systems were housed in the disabled Kaluga modules or whether workloads associated with them were moved. Nor do the available reports establish how much capacity at other sites could take on additional work.
The two incidents raise questions about how the company maintains cloud continuity when infrastructure at separate sites is damaged. But the information available does not show that the Kaluga damage compounded the Sasovo outage or that customers experienced a second, related disruption.
Free newsletter
Get the morning briefing
Start each day with the AI stories that matter and why — a short, free email from our newsroom.
What is known about responsibility for the Kaluga attack?
Yandex attributed the Kaluga damage to a drone attack. The Associated Press characterized the incident as a Ukrainian strike, but the accounts reviewed do not include a direct confirmation from Ukraine that its forces carried out this specific operation.
Kaluga Governor Vladislav Shapsha reported Ukrainian drone activity in the regional capital and several municipal districts. He did not identify Yandex’s data center as a target. Shapsha also reported nine people injured in the region, but the cited accounts do not connect those injuries to the facility.
DatacenterDynamics reported a broader statement by Ukrainian President Volodymyr Zelenskyy that Ukraine was responding in kind to Russian strikes on Ukrainian data centers. The report did not present that statement as confirmation of responsibility for the Kaluga incident. The available accounts establish Yandex’s report of damage and AP’s characterization, but leave the specific attribution and intended target unconfirmed by a direct Ukrainian statement in the sources reviewed.
What does the damage mean for Yandex’s AI compute?
The Kaluga reports do not establish that the disabled modules contained AI-training hardware or that any AI system was affected. They also do not identify the modules’ function, so the infrastructure damage alone cannot show whether the incident reduced Yandex’s capacity to train or run AI models.
Separate Reuters reporting, carried by ThePrint, places two of Yandex’s three supercomputers used to develop its AI model at Sasovo. Yandex had not said whether those systems were damaged in the Sasovo incident. That reporting concerns the earlier site; it does not place the supercomputers in Kaluga.
The distinction is important because the two data-center incidents have different known effects. Yandex has reported disabled modules in Kaluga, while the condition of the supercomputers at Sasovo remains unclear in the cited reporting. Neither account establishes a specific loss of AI-training capacity at Kaluga.
Yandex operates multiple large facilities in Russia, but the number and locations alone do not reveal how much computing capacity is available elsewhere or how quickly equipment can be restored. The company’s ongoing assessment will need to clarify what was damaged in Kaluga, whether any services were actually disrupted there and when the disabled modules might return to operation.
Comments
Comments are written by readers. They are not reporting or opinion from AI News.
Share your view on this story. Criticise ideas and public records, not other readers.
Comments appear once a moderator approves them.
Community guidelines
More in our terms and privacy policy.
Comments close on October 16, 2026.
No comments yet. Start the conversation.