What happened
Yandex Cloud’s restoration recommendations page, updated November 2, 2026, says a new availability zone for platform customers opened on October 23. It is in a new location, but appears in the management console under the old name, ru-central1-a. The company says this naming choice is intended to speed restoration and preserve customer-side automations configured for that zone.
Access to the new zone is being granted gradually. Yandex says information on obtaining access was sent through its mailing list. Resource-recovery quotas are currently limited; the company recommends starting with the services most critical to the business and says customers can contact support to request an emergency quota increase. Resource creation elsewhere in the cloud infrastructure may also be restricted because of platform operating constraints. Current quota balances can be checked in the management console.
The page describes several recovery mechanisms. Customers can move virtual machines to the new ru-central1-a zone using Yandex’s documented VM zone-change process. If VM backups exist, they can be restored in a working zone. Disk snapshots can be exported to S3-compatible storage through a console form after access is granted; the resulting bucket contains a manifest, and the yc-nbs-export-unpack utility can assemble the disk image as a .raw file or write it to a block device. The page also provides an alternate route using a working VM to attach and copy disks. It warns that VM disk snapshots and Cloud Backup backups cannot be transferred to Yandex BareMetal; data transfer there must happen at the operating-system or application level.
The operational and billing status is mixed. Yandex says key platform services have been restored, though some still operate with restrictions. Unavailable resources are not charged, even if they mistakenly appear in billing details. Account balance top-ups are available again. The company says all Yandex Cloud services in Russian Federation availability zones were free for existing customers from October 8 through October 31; charging resumed November 1, 2026, at 00:00 Moscow time. Users are told to disable or delete resources they are not using in working zones.
What the archive adds
An earlier Field Note on Yandex Cloud’s accelerated placement of data and services described the provider’s cross-provider recovery response after damage. This is a new operational fact in that known recovery story: a replacement zone, its naming continuity, and its access and quota constraints.
Trend signal
This update supports agent security moves to runtime boundaries only weakly: reliability and controlled recovery depend on infrastructure boundaries and operator procedures, not model behavior. The source is about cloud service restoration rather than agent runtime security, so it does not establish the pattern directly.
Why now
The recommendations page was updated November 2 and says ordinary billing resumed November 1 after a temporary free period from October 8 through October 31. The replacement zone had opened on October 23, with access still rolling out and recovery quotas limited. The timing makes the document relevant to customers deciding which resources to restore and which unused resources to shut down as charging resumes.
Why it matters
For teams running AI workloads, the announcement is a reminder that recovery plans need to account for zone identity as well as physical location. Keeping the console identifier unchanged may preserve automation, but it should not be mistaken for continuity of capacity: access is gradual, quotas are limited, and resource creation may remain constrained. Teams should identify the workloads that matter most, validate that their backups and disk snapshots are usable through the available recovery path, and test any assumptions about networking and billing.
The source also makes recovery mechanics concrete. A team with saved snapshots can restore in a working zone or export data through a bucket, while BareMetal requires a separate data-transfer approach. These are actionable distinctions for infrastructure owners, including teams whose model endpoints, retrieval systems, or agent services depend on cloud-hosted compute and data.
Limits and uncertainty
The page does not identify the new location, state its capacity, quantify affected customers or data, or promise when access and quotas will become unrestricted. It describes Yandex’s recommendations, not independent verification of recovery outcomes. The stated restoration of key platform services is qualified by continuing restrictions, and the page’s instructions do not guarantee that any particular customer’s VM, snapshot, network path, or automation will work without changes. Nor does the source provide a deadline for the end of the temporary limitations.
Reader takeaway
The new zone is a practical recovery route, not evidence that ru-central1-a capacity is fully back. Preserve the familiar zone identifier in your mental model, but plan around gradual access, limited quotas, and the specific migration path available for each resource type. Recheck which resources are running now that charging has resumed.
Open question
How quickly will Yandex Cloud expand access and recovery quotas, and will the company publish a clearer account of capacity and customer restoration status?