Yandex Data Center Drone Strike Disables Parts of Its Largest Russian Campus

Yandex suffered a second data center attack in two days when Ukrainian drones struck its 1.4 million-square-foot Kaluga campus. The Yandex data center drone strike completely disabled several modules, according to a company statement. Yandex warned that some services might experience temporary disruptions while it assessed the damage.

The October 9 attack followed a strike that took Yandex’s Sasovo data center offline one day earlier. That sequence matters more than either incident alone. Two facilities supporting cloud services and artificial intelligence workloads were damaged within roughly 48 hours.

The strikes test the basic promise behind distributed cloud infrastructure. Operators spread workloads across facilities so one failure does not become a systemwide outage. However, redundancy offers less protection when several locations face coordinated physical attacks.

What the Yandex Data Center Drone Strike Disabled

The confirmed damage is narrower than some online claims, but it is still operationally significant.

The Kaluga strike damaged part of the facility’s infrastructure and left several data center modules completely out of service. Yandex did not disclose the number of affected modules, their workloads, or the equipment inside them.

The company said it was assessing the full extent of the damage. It also reported no casualties at the facility, according to the statement carried by Russian business media.

Associated Press independently reported Yandex’s confirmation of the damage. Its account said the strike might disrupt some services, although Yandex did not publish a complete customer-impact assessment.

That distinction is important. A disabled module can represent a substantial block of computing, cooling, electrical, and networking capacity. It does not necessarily mean the entire campus stopped operating.

The 1.4 million-square-foot figure describes the planned site area, not the portion destroyed. Claims that the complete campus was knocked offline go beyond Yandex’s public statement.

Kaluga was designed around modular construction. Each module contains server halls and supporting systems that can operate as part of a larger campus. This design helps operators expand capacity in stages and isolate some equipment failures.

Physical separation also limits certain incidents. Fire, electrical faults, or cooling problems in one module do not automatically disable every server hall. A direct attack can still damage shared connections, including power distribution and network paths.

Yandex’s original design called for more than 3,800 server racks. Each rack was assigned a planned load of 15 kilowatts. That would give the campus an equipment footprint far beyond a conventional corporate server room.

The facility was also intended to support both Yandex’s internal systems and Yandex Cloud customers. Those workloads can include storage, virtual machines, managed databases, application platforms, and internal consumer services.

Data Center Dynamics reported that Yandex Cloud’s status information still showed a power outage in one availability zone after the attacks. It also listed increased Object Storage response times across several zones. Object Storage provides scalable storage for files and application data.

Those status signals do not prove every issue originated at Kaluga. The preceding Sasovo outage was already affecting the company’s infrastructure. They do show that Yandex was managing more than isolated building damage.

The Yandex data center drone strike therefore created two separate questions. The first concerns how much Kaluga capacity was physically lost. The second concerns how effectively Yandex could redistribute affected workloads while another major facility was unavailable.

Yandex has not published enough detail to answer either question fully. There is no verified server count for the disabled modules, restoration timetable, or measured service availability following the Kaluga strike.

That verification gap should temper dramatic claims about Russia’s internet being disabled. It should not obscure the confirmed fact that multiple modules at a strategic cloud campus stopped operating.

Why the 1.4 Million-Square-Foot Kaluga Campus Matters

Kaluga matters because Yandex designed it as its largest data center, not merely as another regional server site.

Yandex announced the Kaluga project in September 2022. The company described it as its largest data center by total useful rack load and one of Russia’s largest facilities.

The planned campus covered 130,000 square meters, equal to about 1.4 million square feet. Its more than 3,800 racks were expected to support a combined IT load of roughly 58 megawatts.

The site’s total planned electrical capacity was 63 megawatts. Yandex said that was 1.5 times the capacity of its previous largest data center. These figures came from the company’s original Kaluga specifications, rather than a post-strike inspection.

The specifications show why losing several modules can matter without destroying the complete site. At 15 kilowatts per rack, even one densely populated server hall can represent considerable computing capacity.

Kaluga was planned as a Yandex Cloud availability zone. An availability zone is a physically separated infrastructure location where customers can place workloads. Cloud architects use several zones to reduce dependence on one building.

The company expected Kaluga to host its own services alongside customer systems. That mixed role raises the operational stakes because an infrastructure failure can affect internal applications and outside businesses simultaneously.

Yandex also designed the campus for high energy efficiency. Outside air would cool the server racks throughout the year, reducing the electricity required by conventional mechanical cooling.

The company predicted an annual power usage effectiveness ratio between 1.07 and 1.09. Power usage effectiveness compares total facility electricity with the electricity consumed by computing equipment.

A value close to 1.0 indicates that relatively little power supports cooling and other overhead. That efficient design depends on extensive air-handling equipment, electrical controls, and carefully managed environmental conditions.

Those systems can become liabilities after a physical strike. Servers that escape direct damage may still require shutdowns when cooling, power, smoke control, or water systems become unsafe.

Yandex also promoted Kaluga’s direct connection to high-voltage national transmission networks. It planned private cable lines and substations to improve continuity and reduce dependence on ordinary distribution infrastructure.

That setup protects against common grid failures. It cannot guarantee uninterrupted operation when the facility itself becomes a target.

The phrase “largest data center in Russia” also needs qualification. Yandex described Kaluga as one of the country’s largest and its own largest by planned useful rack load. Other Russian operators measure their facilities using different criteria.

A campus can be considered largest by land area, installed power, operational racks, or completed IT capacity. Public reports do not establish that Kaluga leads every category.

The more defensible conclusion is still consequential. Kaluga represents a hyperscale-class concentration of computing infrastructure built to carry cloud and internal workloads at national scale.

This concentration creates efficiency. Yandex can operate thousands of racks with standardized power, cooling, security, and networking. It also creates a visible physical asset whose location and function are difficult to conceal permanently.

The facility sits in the Grabtsevo industrial park in the Kaluga region, southwest of Moscow. Its scale, power connections, and construction footprint are observable through public records and commercial satellite imagery.

That visibility changes the security model for cloud infrastructure during war. Cybersecurity controls cannot stop an explosive drone from damaging a substation, server hall, or cooling plant.

Two Strikes Turn Redundancy Into the Central Test

The deeper conflict is between cloud redundancy promises and a campaign that can pressure several physical locations in rapid succession.

The Sasovo attack occurred before the strike on Kaluga. Yandex said the earlier incident caused a fire, seriously damaged the facility, and forced it to suspend operations there.

Sasovo reportedly contains tens of thousands of servers. It also hosts Chervonenkis and Lyapunov, two systems associated with Yandex’s artificial intelligence development.

Their presence does not prove that either supercomputer was destroyed. Yandex had not published a detailed damage inventory at the time of reporting.

The company also had not confirmed whether all damaged Sasovo equipment could be restored. That uncertainty already complicated workload recovery before Kaluga was hit.

The Kaluga strike then turned a single-site disaster into a multi-site resilience event. Reuters described it as the second such attack on Yandex in successive days and a widening of Ukraine’s infrastructure campaign.

Ukrainian drone producer Fire Point said FP-1 one-way attack drones were used against Kaluga. A one-way attack drone carries an explosive payload and is not designed to return.

The manufacturer’s account identifies the claimed weapon and operator. It does not provide a complete, independently verified battle-damage assessment.

Ukraine had expanded its long-range campaign against targets inside Russia before these attacks. Earlier operations concentrated heavily on oil refineries, fuel depots, ports, military facilities, and logistics assets.

Data centers add a different kind of target. They host services used by consumers, businesses, public institutions, and software systems. Their destruction can create digital disruption without physically cutting every communications line.

Ukraine presented the attacks as retaliation after Russian strikes damaged Ukrainian data infrastructure. Ukrainian President Volodymyr Zelensky said his country would respond to attacks on its data centers.

That explanation establishes the stated motive. It does not resolve the wider legal and humanitarian questions surrounding dual-use infrastructure.

A dual-use site supports civilian activity while also holding potential military or state value. Large commercial clouds can host ordinary businesses, government applications, communications systems, and artificial intelligence development.

Public reporting has not established which specific Kaluga workloads supported Russian military operations. It has also not shown which disabled modules carried civilian customer data.

This uncertainty matters when assessing both military value and civilian impact. A cloud platform can support thousands of unrelated customers within the same physical infrastructure.

The sequence nevertheless creates a practical warning for operators far beyond Russia. Geographic redundancy works only when backup sites remain available, connected, and provisioned for the displaced load.

A company may replicate data across several availability zones. Applications can still fail if those zones depend on shared control systems, congested networks, or insufficient spare computing capacity.

Failover, the process of moving work to backup infrastructure, also requires planning at the application level. Customers must distribute databases, storage, and application instances before a crisis.

A cloud provider cannot automatically make every customer application resilient. Some customers choose one zone to reduce complexity, latency, or operating costs.

The Yandex case places pressure on both parties. Yandex must keep core services running while repairing physical infrastructure. Its cloud customers must determine whether their own designs survived the provider’s failures.

That is why two attacks matter more than one. A single failure activates redundancy. Repeated attacks test whether the redundant architecture has enough geographic and operational separation to remain credible.

Cloud Resilience Has a Physical Limit

Cloud computing can move workloads between machines, but it cannot make power, cooling, networking, or replacement hardware immaterial.

The industry often describes cloud resources as elastic. Customers can request additional computing or storage without choosing individual servers. The abstraction is useful, but the underlying equipment still occupies buildings.

Every active workload requires processors, memory, drives, switches, electricity, and heat removal. When modules disappear, the remaining infrastructure must absorb those demands or shed lower-priority work.

The first constraint is spare capacity. A provider cannot relocate every workload instantly if healthy sites already operate near their practical limits.

Operators normally reserve capacity for failures and demand spikes. Public information does not reveal how much reserve capacity Yandex maintained before the attacks.

The second constraint is data placement. Replicated information can survive one site’s destruction when current copies exist elsewhere. Data that remains tied to one zone requires restoration from backups or damaged equipment.

The third constraint is network capacity. Redirecting users and moving large datasets can congest links between facilities. Higher latency can also degrade applications even when they remain technically available.

The fourth constraint is operational coordination. Engineers must isolate unsafe equipment, inspect power systems, update routing, prioritize workloads, and communicate with customers.

These tasks become harder during simultaneous incidents. Teams responding to Sasovo would already have been managing service restoration when the Kaluga strike occurred.

The fifth constraint is hardware replacement. Servers are standardized, but large deployments require thousands of components. Sanctions and export controls can complicate Russian access to advanced processors, networking hardware, and replacement parts.

It would be premature to claim that sanctions prevent Yandex from rebuilding. Russian technology companies use inventories, domestic systems, parallel imports, and equipment sourced through intermediaries.

Those routes can still add time, cost, and uncertainty. Damage to ordinary electrical or cooling equipment may be easier to repair than damage to specialized computing clusters.

Artificial intelligence workloads present another complication. Training systems use tightly connected accelerators that function as one large computing environment. Replacing individual machines does not immediately recreate the complete cluster.

Yandex has invested in AI models and services, including the Alice assistant and cloud-based machine learning tools. The company’s AI development therefore depends on sustained access to substantial computing capacity.

The confirmed Kaluga damage does not establish that an AI cluster there was destroyed. The reported presence of two supercomputers at Sasovo makes the combined situation more relevant to Yandex’s AI operations.

Ars Technica reported that the two strikes had affected two of Yandex’s five major data centers. It also linked the campaign to earlier Russian attacks on Ukrainian digital infrastructure.

The number of facilities alone does not measure resilience. Five sites can offer strong protection when workloads and dependencies are distributed properly. They can offer less protection when critical systems remain concentrated.

Yandex previously claimed extremely high continuous operation statistics for the data centers supporting its cloud. Those historical figures reflected ordinary reliability, including equipment and power failures.

Wartime strikes create a different failure class. Reliability engineering usually assumes that independent facilities will not suffer destructive physical incidents within the same short window.

Cloud architects call this a correlated failure. Several components fail because they share a cause, even when the components appear independent during routine operations.

A military campaign can deliberately create correlation. The attacker selects separate sites connected to the same provider, service portfolio, or national infrastructure.

That mechanism is the central reversal in the Yandex story. Geographic distribution remains valuable, but the distribution itself becomes a map of targets when an adversary can reach several locations.

The lesson is not that redundancy failed completely. Yandex continued operating many services despite serious damage at Sasovo and partial losses at Kaluga.

The real test is how much performance degraded, how many customers lost access, and how long constrained operations persist. Yandex had not released those measurements.

What the Damage Does Not Yet Prove

The public evidence supports a serious multi-site incident, but not every claim about destroyed capacity or nationwide outages.

Yandex confirmed the Kaluga damage and the loss of several modules. Major news organizations also reported the company’s statement.

However, the phrase “several modules” lacks a standard public capacity measurement. A module can vary considerably in floor area, rack count, power load, and operational purpose.

No verified imagery has established which Kaluga buildings were hit. Yandex has not disclosed whether the damage reached server halls, substations, cooling equipment, or supporting structures.

The company also has not identified the services hosted in the disabled sections. This prevents a direct connection between physical damage and any individual application outage.

Social media posts claimed widespread failures affecting taxis, delivery services, search, email, and the Alice assistant. Some users may have experienced genuine problems, but anecdotal posts cannot measure national availability.

Internet services can also fail for unrelated reasons. Congestion, application bugs, regional connectivity problems, and defensive shutdowns can overlap with a data center incident.

Status data provides stronger evidence, but it still needs interpretation. A listed outage identifies an affected cloud component or zone. It does not reveal the complete number of customers or failed requests.

The same caution applies to claims about the campus’s completion. Yandex published the design in 2022 and planned an initial opening for 2023. Public sources do not offer a complete module-by-module construction history.

The planned 63-megawatt capacity should not automatically be treated as operational capacity on the attack date. The facility may have reached that level, but Yandex had not published a current utilization figure.

Similarly, more than 3,800 racks represents the announced design. It does not prove that every rack was installed, occupied, and processing active workloads.

The company’s share price fell after reports of the attacks, according to Russian market coverage. A short-term market decline indicates investor concern, not a quantified estimate of infrastructure losses.

Questions also remain about attribution. Yandex described a drone attack, and Ukrainian sources claimed responsibility. Fire Point specifically said Ukrainian forces used its FP-1 drones.

Those statements create a consistent reported account. Independent investigators had not published a comprehensive reconstruction of the Kaluga operation.

The broader description of the strike as retaliation comes from Ukrainian officials. It reflects Ukraine’s stated justification and should not be presented as an independently established operational motive.

Civilian impact remains another unresolved area. Yandex said nobody was injured at the facility. Separate reports mentioned casualties from attacks elsewhere in the Kaluga region without tying them to the data center.

Conflating regional casualty figures with the Yandex site would be inaccurate. The available company statement specifically reported no casualties at its facility.

There is also no public evidence of lost customer data. Service interruption, equipment destruction, and permanent data loss are three different outcomes.

A storage system can become temporarily unavailable while intact copies remain elsewhere. Permanent loss occurs only when all usable copies and backups become inaccessible or destroyed.

Yandex has not reported such a loss. Customers should still verify their own backup and replication arrangements rather than treating provider silence as proof of safety.

The most defensible assessment is therefore limited but serious. Two Yandex sites suffered confirmed physical damage on consecutive days. Sasovo stopped operating, while part of Kaluga was disabled.

Anything beyond that requires additional evidence. The scale of destroyed computing, the effects on AI development, and the restoration schedule remain uncertain.

Three Signals Will Show Whether Yandex Can Contain the Crisis

Service telemetry, repair disclosures, and changes to Yandex’s infrastructure strategy will reveal whether the attacks caused disruption or a lasting capacity problem.

The first signal is Yandex Cloud’s service status. Recovery notices should show whether affected availability zones return to normal and whether storage latency declines.

A quick normalization would indicate that traffic and workloads were redistributed successfully. Continued warnings would suggest capacity, networking, or data-recovery constraints.

The most useful evidence will be service-specific. Aggregate claims that Yandex is “working” or “down” hide differences between search, consumer applications, cloud storage, databases, and AI systems.

Customers should watch for recurring failures after an apparent recovery. A provider can restore basic availability while operating with reduced redundancy and little spare capacity.

That condition leaves services vulnerable to ordinary hardware failures or another attack. It can also produce slower performance during traffic peaks.

The second signal is a detailed damage and restoration assessment. Yandex had said it was still determining the full extent of the Kaluga damage.

An assessment should identify the number of disabled modules, the systems affected, and the expected repair sequence. It should also distinguish repairable equipment from infrastructure requiring replacement.

A published timeline would strengthen confidence that the incident is contained. Repeatedly delayed estimates would point toward deeper electrical, cooling, or supply-chain problems.

Sasovo requires separate attention. If the company restores that facility, Yandex regains geographic capacity while repairing Kaluga. If Sasovo remains offline, the remaining network carries more pressure.

Reports about the supercomputers should also be treated carefully. Confirmation that Chervonenkis and Lyapunov survived would reduce concerns about Yandex’s immediate AI training capacity.

Confirmed destruction would have a different implication. Rebuilding a large accelerator cluster requires more than restoring ordinary cloud servers, particularly under technology export controls.

The third signal is a change in physical infrastructure strategy. Yandex can add defenses, distribute capacity across smaller locations, or move critical workloads farther from the conflict’s reachable zone.

Each option carries tradeoffs. Hardened buildings and air defenses increase costs without guaranteeing protection. Smaller sites reduce concentration but create more facilities to operate and secure.

Greater geographic distance can lower strike risk. It can also increase network latency and place capacity farther from Yandex’s largest user and business markets.

Yandex reportedly removed or obscured data center information from its mapping service after the attacks. Concealment can reduce casual visibility but offers limited protection for large industrial sites.

A hyperscale facility requires land, power lines, substations, fiber connections, construction activity, and cooling infrastructure. Commercial satellite imagery and public planning records can expose those features.

The more consequential response would involve architecture rather than maps. Yandex must decide how much infrastructure should remain concentrated near Moscow and adjacent regions.

Cloud customers face their own decision. They should identify whether applications span independent zones and whether backups can be restored outside the primary provider.

That review does not require assuming Yandex will suffer another strike. It treats war as an infrastructure condition that can invalidate normal reliability assumptions.

The Yandex data center drone strike is therefore not just a story about damaged buildings. It is a live test of how commercial cloud architecture performs during a deliberate campaign against its physical foundations.

The strongest evidence will come from measured recovery, not dramatic images or claims from either side. Watch Yandex’s status telemetry, its repair timetable, and any redesign of its availability-zone network.

If services stabilize while Sasovo and Kaluga recover, Yandex will have demonstrated that its distributed systems absorbed an extraordinary shock. Persistent constraints would expose a harder reality about concentrated computing.

Cloud infrastructure can make individual servers interchangeable. It cannot make major campuses, electrical capacity, or specialized AI hardware instantly replaceable.

For businesses using any cloud in a conflict-exposed region, the practical question is immediate: can critical operations survive when the backup location becomes the next target?