On October 23, we opened a new availability zone for our tech platform’s customers, where you can launch your computing resources previously hosted in the ru-central1-a zone.

The zone is in a new location, but will appear in your console with the old name
ru-central1-a. This is necessary to quickly restore power and preserve the automations configured on your side.

Quotas for resource recovery in the new zone are currently limited, so we recommend started the launch with your most business-critical services. we will gradually expand the resources, and for an emergency quota increase, you can contact the support service.

You can check the current quote balance in the Yandex Cloud management console.

Due to restrictions on the platform’s operations, the creation of new resources in the cloud infrastructure may be limited.

Resources that are currently unavailable are not charged and will not be taken into account when calculating consumption. They may appear by mistake in the billing account details, but they will not be charged.

Top-ups of account balances are available once again. You can check your current balance in Yandex Cloud Billing: select your billing account and open the Account page. If you have already topped up your balance, you can check it in the Payment History section in the left-hand panel. It shows the date, status, and amount of the payment. For more details, read the instructions.

We remind you that during the period from October 8 to October 31, the use of all Yandex Cloud services in all availability zones of the Russian Federation was free for existing customers.

Starting November 1, 2026, at 00:00 (Moscow time), services will be charged. Please check that the resources you are not using in working zones are disabled or deleted.

If you created backups of a VM, you can restore them in a working Yandex Cloud zone following the instructions.

You can move a VM to the new availability zone following the instructions.

You can upload a disk snapshot to an S3‑compatible storage by using the form in the console. Requests will be processed automatically, so the export will take less time.

How to do it:

1. Prepare the bucket and the access keys for it.
2. Fill out the form. In it, specify the snapshot and the bucket parameters.
3. Wait for the export to complete. A folder with the manifest.json file will appear in the bucket.
4. Assemble the disk image using the yc-nbs-export-unpack utility. The result will be in the form of a .raw file or will be written to a block device.

For more details, see the instructions.

If it’s more convenient for you to export the data via a working VM, use one of the methods below.

Exporting previously created snapshots via a working VM

Create a disk and specify the previously created snapshot that you want to copy as its content.

Connect this additional disk to your desktop Compute Linux VM.

Connect via SSH to this VM in the cloud and copy the additional disk to the local VM using the command:

ssh <username>@<VM_IP_address> "sudo dd if=/dev/sdb status=progress | gzip -c" > sda.img.gz

The resulting compressed disk image will be saved to the folder on the local machine where the SSH session was started.

Exporting data from VM disks

If you need to export data to a Linux-based Compute VM.

Connect via SSH to this VM in the cloud and copy the data from the disk to the image:

ssh <username>@<VM_IP_address> "sudo dd if=/dev/sdb status=progress | gzip -c" &gt; sda.img.gz

The resulting compressed disk image will be saved to the folder on the local machine where the SSH session was started.

Use the instructions, which will help you transfer data from a disk image or section of a running VM. Using an auxiliary VM, you can save a copy of the disk or partition to an S3 storage provided by a third‑party provider. For more details, read the instructions.

The console displays the correct status of the load balancer target groups and instance group. You can delete resources (instances, nodes, and VM groups) in unavailable zones by following the instructions.

Target resources in ru-central1-a are once again available via the network, but the VMs themselves remain in the STOPPED status. If you want to return traffic to the zone gradually and in a controlled manner:

1. Disable traffic reception in the ru-central1-a zone:

   yc load-balancer network-load-balancer disable-zones <balancer_ID> --zones=ru-central1-a
   

2. Start the VM and check that the relevant target groups are connected to the load balancer.

3. Enable traffic reception in the zone:

   yc load-balancer network-load-balancer enable-zones <balancer_ID> --zones=ru-central1-a
   

Read more in the instructions.

The load balancers that were configured to be deployed in a subnet in ru-central1-a were forcibly switched to the zonal-shift mode for this zone. Traffic reception was temporarily disabled.

Starting November 2, once pricing has launched, we will disable the Zonal Shift mode for your load balancers, and they will be able to process traffic in the zone again.

If you do not plan to use load balancers in the ru-central1-a zone, you must disable them yourself following the instructions.

If you do not need to receive traffic in the ru-central1-a zone, delete the balancer allocation in this zone entirely by updating the setting in the Allocation using the Receive traffic option.

Route announcements in ru-central1-a are disabled.

• You can configure new announcements yourself using the instructions.
• Previous announcements can be restored form a configuration backup. To do this, write to the support service and specify the Cloud Router ID. We will restore the routes and announcements to the state in which they were configured before the incident.

We added the option to manage Cloud Interconnect via Terraform.

To play video immediately after loading, select a channel → Channel settings, enable Show video in player before processing is complete save the changes.

The source file will be played back without transcoding until the processing is complete. This feature works if the browser supports the file format. Read more in the instructions.

Such clusters will be in a disabled state. You can start them manually via the management console. Please note that the cluster is started together with its node groups.

If such a cluster had node groups in the available zones and they are still running, the node groups themselves will remain enabled, and after the cluster is launched, they will connect to it and continue working.

VM groups for node groups are operating in zonal incident mode, and their nodes are in a disabled state.

To put the node group back into operation:

1. Find out the ID for the VM group:

   yc managed-kubernetes node-group get <node_group_ID> --format=json | jq -r '.instance_group_id'
   

2. Enable the zone for the VM group:

   yc compute instance-group enable-zones --zones ru-central1-a <VM_group_ID>
   

After that, stopped VMs will be started in fixed-size groups, and new ones will be created in groups with auto-scaling.

Operations are fully functional for basic and highly available clusters, all of whose master hosts are located in available zones.

We do not recommended carrying out operations other than deletion, relocation, and working with node groups on clusters whose master hosts are located in the ru-central1-b zone. For such clusters, you must first, following the instructions, relocate from ru-central1-b to another available zone. This can be done according to the instructions or by editing the cluster in the management console.

To increase the available resources in a cluster, we recommend you consider creating BareMetal node groups in Managed Service for Kubernetes^®. Such groups can be created via the Cilium cluster UI on Kubernetes^® version 1.35. If your cluster meets these requirements, BareMetal node groups can be an additional way to expand its resources.

If you need new computing resources, consider creating external nodes with other providers.

Create a new instance from a backup following the instructions. Before creating it, request a quota via the support service.

Do not use the restore of the current instance. In this case, a new instance is created in the same zone as the original one, so the operation will fail.

Currently, quotas and free computing resources are limited in the zones. We do not recommend stopping and updating instances: they may not restart after that.

If the instance opens and you can work with it, but it has an Error status in the console, contact the support service. We will correct the status.

Most likely, the instance’s quota in the zone is insufficient. Write to the support service and we will try to help you as quickly as possible.

By default, all managed database hosts in ru-central1-a are stopped. Clusters fully located in this zone are in the STOPPED status. Running hosts in other zones continue to serve requests.

Before starting to work, check the cluster status, host and shard placement, the presence of active replicas, and the type of disks.

Hosts launched in ru-central1-a will operate fully and can become masters if the service and cluster configuration support such a role. Take this into account in your work.

Clusters with hosts only in ru-central1-a or ru-central1-a and ru-central1-b remain stopped, but will become available for launching.

When you are ready to resume work, open the cluster in the Yandex Cloud management console and click Launch or use the CLI.

If the whole cluster in stopped, launch it first, then proceed with actions on individual hosts.

For PostgreSQL and MySQL, this scenario applies when there is a working master in the available zones. For StoreDoc and Valkey, a working master is required in the corresponding replica set or shard.

For ClickHouse, Apache Kafka, OpenSearch, local or NRD disks, use the individual scenarios below.

The basic procedure is: delete the stopped host from the ru-central1-a zone → add a new one → check synchronization → update the connections.

Before deleting, make sure that the minimum number of hosts required for your service and configuration is retained.

1. Delete the stopped host in ru-central1-a and wait for the operation to complete successfully.

2. Add a new host in the required available zone, including in ru-central1-a. Specify the role required and, if the cluster is sharded, the same shard.

3. Wait for the addition to complete successfully, then check the host’s availability and data synchronization.

4. If the applications were connecting directly to a remote host, update the connection addresses.

The ALIVE status alone does not confirm that synchronization has completed.

Launching an individual stopped host with local disks in ru-central1-a can be done by contacting the support service. This rule also applies to the ClickHouse scenario described below.

When replacing a host, the order is as follows: add a new host → check synchronization → update direct connections → delete the stopped host.

Delete a stopped host only after you have successfully added a new one and confirmed that it is ready.

If the cluster has three hosts and its configuration requires at least three, you need to add a fourth host with local disks before deleting it. For sharded clusters, take the minimum number of hosts in each shard into account.

A shard was only located in ru-central1-a and had no replicas

Restart the existing host. Do not delete it to create a new one: this shard has no other replica to recover data from.

For a host with network disks:

1. Open the cluster in the management console → Hosts.

2. In the menu for the required host, select Restart and confirm the action.

3. Wait for the operation to complete, check the host’s availability, that tables are present, and that queries are being executed.

You can also use the CLI:

yc managed-clickhouse host restart <host_name> \
  --cluster-name=<cluster_name>

A shard has a working replica in another available zone

Before making a replacement, check the table engines: the synchronization procedure described applies to the ReplicatedMergeTree family. Data from tables without replication is not transferred automatically.

If there is non‑replicated data on the old host, coordinate the recovery with the support service before changing the cluster composition.

We recommend the following procedure for a replacement:

1. Add a new host to the same shard.

2. Wait for the addition to complete and check synchronization.

3. If applications connected directly to the old host, update the connection addresses.

4. Delete the stopped host and wait for the operation to complete.

Read more about migrating ClickHouse hosts.

Restoring and launching stopped hosts in ru-central1-a is possible by contacting the support service.

If data is only stored on a host in ru-central1-a, contact the support service to recover it. This rule also applies when MANAGER hosts are located in other zones.

A cluster fully deployed in ru-central1-a is started from the STOPPED status in the usual manner.

For a running cluster with a group of hosts in several zones, including ru-central1-a:

1. Delete ru-central1-a from the list of zones of the host group. Click Save and wait for the operation to complete.

2. Add ru-central1-a back. Click Save and wait for the operation to complete.

If, having deleting the zone, exactly two hosts with the MANAGER role remain, the service will return an error, and the cluster modification operation will not be created.

To carry out the restoration:

1. Via the CLI add a separate temporary group consisting of one host with the MANAGER role. It will not be possible to create such a group via the console UI.

2. Wait for the group creation to complete successfully.

3. Delete ru-central1-a from the main group again and add the zone back. After each action, wait for the operation to complete successfully.

4. Check that there are three working hosts in the main group with the MANAGER role once again.

5. After completing all operations, we recommend deleting the temporary group.

This procedure also applies to the main group with combined roles DATA + MANAGER roles.

After recovery, check the cluster status and shard distribution.

If there is not enough quota to add a host, request an increase.

Contact the support service if the operation is unavailable, ends in an error, the host limit has been reached, or synchronization cannot be confirmed.

Provide the cluster ID, host name, action performed, and error text. If the operation was created, include its ID.

You can use Data Transfer to export data from any database. We described how to prepare databases for migration in the documentation.

When creating fault‑tolerant (HA) clusters, we recommend distributing hosts and resources in working zones.

When creating zonal clusters, we recommend selecting resources in the ru-central1-a or ru-central1-d zones. When creating new clusters in Yandex Data Processing, Yandex Managed Service for Apache Spark^™, and Yandex Managed Service for Trino, we recommend you not use intermittent capacities and disable autoscaling. Use a fixed cluster size. We recommend you move all data from HDFS and local drives to S3. For more details, read the instructions.

Data from YDB can be exported locally with the ydb tools dump command. Export to Yandex Object Storage is available with the ydb export s3 command, write restricitons to S3 have been lifted.

Previously created copies of YDB data in Object Storage can be restored to existing databases or to independently deployed YDB installations. Data from an Object Storage bucket is loaded into a running YDB database using the ydb import s3 command. The local copy is loaded using the ydb tools restore command.

Two more ranges have been added from which DataLens can connect to your data sources:

• IPv4: 130.193.60.16/28
• IPv6: 2a02:6b8:c32::f83d:a987:0/112

If you connect to external databases, allow these ranges in the firewall settings. Then the connections will continue to work without interruptions. The full list of addresses can be found in the documentation.

For correct and stable operation of speech recognition (STT) and speech synthesis (TTS), switch to API v3.

We recommend using synchronous mode, but it may be delayed. Asynchronous mode works only from 00:00 to 06:00 (Moscow time).

For generative search in the internet, we recommend using the Responses API and Web Search Tool instead of the Yandex Search API generative response. Instructions can be found in the documentation.

Join the community chat, where we quickly answer questions: Telegram.

The service processes newly uploaded files as usual. All previously unprocessed data has been processed. The functionality for recalculating Pro tags and assistants has been restored.

Use the DeepSeek V4.1 Flash model.

If you receive a 403 error when trying to log in to your workspace, delete the workspace and create a new one.

We have restored MCP and related plugins.

New users should contact the support service to increase their quota before launching the service for the first time. It may take time to process the request.

Join the AI2Business community chat in Telegram where we quickly answer questions.

Use an external model by default. If you need a local one, select it in the platform interface according to the instructions.

Join the community chat where we quickly answer questions: Telegram, VK.

We recommend creating a service account (or several) in the Yandex Cloud catalog, and granting it rights to manage resources and create authorized keys (or other types of keys if necessary) to use it to manage infrastructure via CLI/Terraform.

Example command:

yc resource-manager cloud add-access-binding --cloud-id=<...> --service-account-id=<...> --role=<...>

To manage access to third-party cloud platform resources centrally and securely, we recommend setting up single sign-on (SSO) via Yandex Identity Hub.

Typical pretexts used by fraudsters include: “your data is damaged — log in to recover”, “your account blocked as the result of a failure”, “enter your details to receive compensation for downtime”, “urgent migration — open this attachment”.

We never ask for passwords, 2FA codes, API keys, card details, or remote access via email.

How to recognize fraudsters

• Sender: A real address can only be on the @yandex.cloud domain.
• Links: Hover before clicking; HTTPS ≠ security. Instead of clicking on a button in an email, open the site manually.
• Urgency: Phrases like “you must confirm within 24 hours” are sign of an attack.
• Attachments: Do not open .exe, .js, .zip with a password, or .docm files.

What you should do

1. Only check the status of platform components on the status board and the console.
2. When in doubt, do not click. Check our official channel.
3. Mark suspicious emails as spam.

If you have already entered data

1. Change your password.
2. Log out of all sessions.
3. Check your mail forwarding rules.
4. Report the incident to the support service via the console.