After Yandex's shutdowns, who pays for AI-cloud standby capacity?

Yandex's data-center shutdowns raise a commercial question about the gap between compute sold during normal operations and business that can be restored during an incident. A customer buying inexpensive compute still needs to fund interruption risk, recovery time and data protection. A cloud operator retaining standby resources must decide how to charge for them and keep their cost affordable. One incident cannot establish the optimal redundancy ratio, but it shows why normal utilization alone cannot value the service.

On October 11, Yandex updated its statement to say the Vladimir data center had stopped operating after an attack. Sasovo had already stopped completely, while part of Kaluga's infrastructure had failed. The same day, fintech head Pirogov said account records had copies across sites and checks found no lost records, although some users still could not check balances, make payments or transfer money, with no precise recovery time available.^[1][2] Data integrity is a management statement. Commercially, preserving records and restoring transactions require different acceptance tests.

Three facility conditions do not establish a financial loss

Source: Yandex's October 9 announcement and October 11 update. Event times follow the company's local descriptions.^[1]

The announcement does not disclose GPU counts, workload composition, affected MW, repairability or impairment charges for each facility. The payments statement cannot establish data outcomes across every company product. Revenue and capital expenditure therefore need separate estimates. Temporary capacity rentals and staffing may first increase cash outflows; repairs or replacements may involve capital expenditure; revenue loss and churn depend on service interruptions, invoices and renewals. Multiplying the number of shutdown sites by an assumed revenue figure would not answer those questions.

Losses across services also may overlap for the same customer. A delayed transaction completed later has different economics from an order permanently transferred elsewhere. An asset's carrying-value loss and cash spent on replacement equipment can relate to different periods and accounting measures. Public information does not establish Yandex's actual loss or whether its previous redundancy was insufficient. No undisclosed revenue base is assumed here.

Data copies must be tested with a working business

Yandex's public-cloud documentation identifies VMs and disks as zonal resources. It lists four ordinary Russia-region zones—a, b, d and e—and a separate BareMetal m zone. Its regional documentation says resources and data are isolated between Russia and Kazakhstan.^[3][4] These are product boundaries, not an incident postmortem. They do not map the affected facilities to particular zones or establish the public-cloud architecture used by Yandex Pay.

For an investor or buyer, recovery capability needs to answer three questions: how far back the recovered data can be, how long until service works again and how much critical business the recovered environment can handle. The first two are commonly described as the recovery point objective, RPO, and recovery time objective, RTO. The third requires resources, networking and dependencies to be tested together. Microsoft's continuity guidance separately discusses objectives, plans and exercises.^[5] A backup file does not demonstrate that a customer can transact within the promised time.

AWS's general architecture guidance notes that copied data does not ensure the required compute type will be available at failover. Azure Site Recovery similarly requires the target region to support the needed VM types and have sufficient capacity.^[6][7] These explain the value of reserving resources; they do not establish a missing configuration at Yandex. If a postmortem shows sufficient standby compute, analysis should move to the dependency, switching or checking process actually identified.

AI workloads also require compatibility. Training recovery needs usable checkpoints and an appropriate cluster. Inference needs model loading, acceptable network latency and the surrounding services that receive and process requests. A recovery buyer should accept a complete task. Proving that servers can boot does not prove that task has resumed. These are general operating requirements, not asserted causes of Yandex's interruption.

In a four-site scenario, tolerating one failure requires 33.3% extra compute

This is an idealized Atlas scenario, not Yandex's architecture, GPU or MW count, or financial guidance. Normal demand is 100 interchangeable compute units distributed evenly across N identical sites. The system must support all demand after any K sites become unavailable, with N greater than K. Network, software and switching are assumed frictionless. Capacity per site = 100 / (N − K); total capacity = 100 × N / (N − K); normal total utilization = (N − K) / N.

Source: Atlas assumptions and calculations. Normal demand is 100 units in every row. The model covers steady-state compute under ideal conditions, excluding replication, peaks, switching time and common-cause failures.

The four-site case's 33.3% refers to additional compute capacity, not the increase in total campus CAPEX. With equal annual holding cost per compute unit, the resource cost index rises from 100 to 133.3. Land, power, networking, software and staff costs need not move proportionately. Performance loss across zones may require more effective capacity; shared power, network or control failures can prevent the evenly distributed system from restoring all business.

The table explains the utilization-reliability tradeoff. A system tolerating one of four sites becoming unavailable can deliberately operate at 75% total utilization. The same utilization could also reflect weak leasing. The number alone cannot distinguish the two. Paid recovery commitments, ownership of standby resources and exercise records determine whether the spare capacity protects revenue or consumes capital without a buyer.

Standby resources can earn revenue if they can be reclaimed in time

An operator's recovery costs include ongoing data and network replication, compatible compute holding or opportunity cost, switching automation and exercises, and incident-time expansion and repair. Customers may pay through a reliability premium, reservation fees or their own secondary environments. A landlord collects rent, a cloud company sells service and an application handles end-user transactions. Their responsibilities differ; the landlord does not automatically reimburse all downstream business loss.

Standby capacity need not remain idle all year. AWS discusses allowing development and testing environments to use reserved capacity, then reclaiming it for recovery, while preserving deployment and exercise requirements.^[6] Interruptible test or offline jobs can earn revenue and share cost. That revenue must be reduced by variable expenses, the cost of reclaiming resources and the risk of delaying critical recovery before it counts as an improvement in disaster-recovery economics.

One standby pool cannot fully guarantee simultaneous recovery for several noninterruptible customers. Complementary workloads in normal operations do not establish complementary needs during a disaster: a common event can make everyone request recovery at once. Contracts need recovery priority, guaranteed capacity, reclaim timing and tests. Higher utilization accompanied by less deliverable recovery capacity can improve apparent efficiency while increasing breach and churn exposure.

For capital providers, standby capacity earns a lasting return only if incremental charges cover incremental cost. More reliability does not automatically create more profit. If customers will not pay, expenses reduce margins and cash. Demonstrable recovery that protects renewals, reduces exits or supports a premium can change the outcome. This Russian incident is not used to estimate China's disaster-recovery market or any supplier's orders.

SLA credits and customer business losses are asymmetric

Yandex's current Compute SLA lists a general service level of 99.95% and a GPU Cluster level of 99.5%. The GPU provision defines a particular unavailability event as loss of high-speed bus connectivity between running cluster VMs for at least five minutes due to problems on Yandex's side.^[8] That is not payment success, model-task completion or end-to-end application availability. Percentages measuring different things cannot directly rank products.

The universal SLA provides compensation against future service fees rather than a cash payment, with caps and exclusions including force majeure.^[9] The relevant legal entity, service contract and incident cause must be evaluated for each customer. This article determines neither claim eligibility for this incident nor actual compensation. Yandex Pay's management statement cannot be equated with a public-cloud contract.^[2][9]

Customers should consequently budget separately for service and recovery purchases, and for losses in their own business during an interruption. A credit based on the cloud invoice may be much smaller than an application's lost contribution profit. The operator may also incur repairs, additional operation and retention expenses far beyond the credit. Using a compensation percentage as the total incident loss misreads both sides' exposure.

To compare recovery strategies within one analysis period, estimate avoided business contribution loss, avoided recovery expense and changes in applicable compensation, then subtract incremental standby, replication and exercise cost. Contribution loss should account for variable costs saved during interruption; deferred transactions completed later differ from permanent losses. Without support for event probability, duration and churn, use conditional scenarios rather than an arbitrary probability to declare a positive investment return.

Tiered protection can be more economic than hot standby for every workload

The strongest counterargument is that an extreme event does not establish underinvestment in everyday architecture. Maintaining the highest level of remote hot standby for all business can tie up too much capital and add software complexity. Deferring offline analytics or some training while protecting transactions, critical inference and their dependencies can be a rational commercial choice. Objectives should follow business loss and recovery commitments, rather than the number of data centers.

China already has a defined tiered policy setting. The 2022 national government-data-system guideline describes primary and backup arrangements including two locations and three centers for the national government platform, with different protection for critical business, important local data and full remote data.^[10] That applies to the specified government system, not a uniform configuration obligation for every commercial AI campus. The transferable purchasing approach is to contract for protected workloads, recovery capacity, RPO, RTO and exercise acceptance instead of merely buying standby racks.

Over the coming weeks, service recovery records, account-integrity statements and actual compensation can change the Yandex assessment. Over 3–12 months, examine the constraints identified in a postmortem, available standby resources and measured recovery times. Over 12–24 months, compare expenses, CAPEX and renewals with the economic return from greater reliability. If adequate reserves demonstrably absorbed the workload, concern about a capacity shortfall should fall instead of expanding an unproven loss estimate.