Drones Knock Out Yandex's Third Data Center, in Vladimir
Drones struck Yandex's data center in Vladimir, and it is now completely out of action, according to CNews. It is the third of the company's data centers hit by attacks; Yandex has five in total. The day before, the company added a clause to the terms of service for its products that releases it from liability to customers for service outages caused by UAV attacks. - 3 of 5 data centers have been hit. - The Vladimir site is completely unavailable, according to the outlet. - Responsibility for downtime has been shifted onto users through the terms of service.
AI-processed from CNews; edited by Hamidun News
Drones have struck a third Yandex data center, this time in Vladimir. According to CNews, the site is completely out of action. The company has five data centers in total, so three of them, more than half of its infrastructure, have now been physically hit. The day before, a clause was added to the terms of service for Yandex products stating that the company is not liable to customers for service outages during UAV attacks.
What is known so far
The source offers few details, and that is worth keeping in mind. The report contains no public confirmation of the scale of the damage, the recovery timeline, or which services were affected. The phrase "completely out of action" comes from the outlet, not from the operator's technical documentation. So what follows is only what can be considered established based on CNews's account:
- Site: Yandex data center in Vladimir.
- Status: completely out of action.
- Total data centers the company has: 5.
- Already hit by attacks: 3.
- Change to the terms of service: a clause was added releasing the company from liability for service downtime during UAV attacks.
The article does not disclose the dates or locations of the two earlier strikes. It is also unknown which services ran at the Vladimir site, and that determines whether users noticed an outage at all.
The clause in the agreement as a signal
The amendment to the terms of service is more interesting than the strike itself. Almost every cloud and internet service has force majeure language covering natural disasters, power outages, and the actions of third parties. But naming UAVs explicitly shows that the company treats such events not as a one-off risk but as a recurring factor. Lawyers write clauses like this when the likelihood of an event stops being theoretical.
For the average Yandex user, this changes almost nothing: mail, maps, and search do not come with monetary compensation for downtime anyway. For businesses, the picture is different. If a company builds its product on Yandex Cloud or other platform services and counts on an SLA with penalties, a reference to UAV attacks can make those penalties impossible to collect. The details depend on the specific contract: the user agreement and corporate terms do not always match, so this needs to be checked.
Why a data center is so vulnerable
A data center is a large, stationary facility with a known address. It needs heavy power supply, cooling, and network links, and each of these can be disabled without a direct hit on the server halls. Fault tolerance, meanwhile, rests on geographic redundancy: data and workloads are duplicated across sites. When three of five sites are unavailable, the safety margin shrinks to two. Even with good replication, the load on the remaining capacity grows, along with the risk of degradation and the recovery time after the next incident.
There is an engineering side to this as well. Shifting workloads away from a lost site requires spare compute and storage, and with server shortages and restrictions on hardware supplies, those are not unlimited. Replacing lost capacity quickly and at the same scale is hard.
What teams that depend on Yandex should do
First, read the current version of the agreement and the corporate contract: what exactly they say about force majeure and compensation. Then review the architecture. Critical data and backups should sit in at least two independent geographies, and preferably with another provider as well. Failover scripts need to be tested regularly in practice, not kept as a document. A business that loses money during downtime should calculate its acceptable recovery time (RTO) and acceptable data loss (RPO) in advance, and compare them honestly with what the provider can actually deliver. If the gap is large, a multi-cloud setup will cost less than a single bad week without service.
Access Frontier LLMs & Multimodal AI in One Workspace
Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.