Moving an instance between zones

This page describes how to move a VM instance between zones, either by using the projects.moveInstance API or manually, through a series of steps. If a zone is unavailable or deprecated, you can use this method to move your instances to another zone.

Whenever possible, you should move an instance automatically using the projects.moveInstance API. If you cannot use the API, you can still move your instance manually using the following steps:

  1. Create snapshots of persistent disks attached to the original instance.
  2. Create copies of the persistent disks in the destination zone.
  3. For external and internal IP addresses:
    • If you are moving an instance across zones within the same region, and you want to preserve its ephemeral IP address, temporarily promote the ephemeral IP address that is assigned to the instance to a static IP address and then assign it to the new VM instance you create in the destination zone.
    • If you are moving an instance across regions, you must pick a different IP address for the VM instance.
  4. Create and boot up a new instance in the destination zone. If you are moving across regions, you must also pick a new subnetwork for the new instance.
  5. Attach the new persistent disks to your new instance.
  6. Assign an external IP address to the new instance. If necessary, demote the address back to an ephemeral external IP address.
  7. Delete the snapshots, original disks, and original instance.

Before you begin


Before you move your instance, you must meet the following requirements:

  • There must be enough quota in your project for new snapshots and to promote any ephemeral external IP addresses.
  • In your destination region, there must be enough quota for the new instance and disks. For example, if you have three disks attached to the instance you want to move, you need enough quota to create three temporary persistent disk snapshots and three new disks. After you create your new disks, you can delete your temporary snapshots.
  • The persistent disks that are attached to the instance you want to move are not attached to more than one instance.
  • If your instance includes GPUs, verify that the GPUs you want to use are available in your target zone. For a list of GPUs and the zones that they are available in, see GPUs on Compute Engine.

Note that while your VM is moving it will be shut down and then restarted after the move. After you move your instance, update any existing references that you have to the original resource, such as any target instances or target pools that are pointing to the earlier instance.


When possible, use the moveInstances API to save yourself some work, but there are some scenarios where using the moveInstances API is not an option. Specifically, the following scenarios require a manual move:

  • The VM is currently in a TERMINATED state.
  • You want to move your instance between regions, such as between us-west1-a and asia-south1-b, and your VM belongs to a subnetwork. You must perform the move manually and select a new subnetwork for your instance.
  • The instance has local SSDs attached to it or has GPUs that are not available in the destination zone.
    • Local SSDs are meant for temporary storage, and data on local SSDs is not preserved through manual instance terminations, which you would need to do as part of moving your instance. If you need to preserve local SSD data, replicate it by using a durable storage option like persistent disks.
    • If your desired GPUs are not available in the destination zone, either choose a new zone that does offer the same GPUs or choose new GPUs in the destination zone.
  • The VM is using a Shielded VM enabled image, such as Debian 10.

Regardless of whether you are making a manual or automatic move, you must meet the requirements to be able to move the instance successfully.

Resource properties

During the move, some server-generated properties of your instance and disks will change.

Properties that change for instances

Property name Changes
Internal IP address A new internal IP address is usually assigned, but it is possible that the instance keeps the original internal IP address.
External IP address If the instance is moving between zones in the same region, the external IP address remains the same. Otherwise, pick a different external IP address for the VM instance.
CPU platform Depending on the available CPU platform in your destination zone, your instance might have a different CPU platform after it has been moved. For a full list of CPU platforms in each zone, see Available regions and zones.
Network/subnetwork If your instance belongs to a subnetwork and you are moving an instance across regions, you must pick a new subnetwork for your instance. Instances moving across zones in the same region retain the same subnetwork.

Properties that change for disks

Property name Changes
Source snapshot The source snapshot of the new disk is set to the temporary snapshot that is created during the move.
Source snapshot ID The source snapshot ID is set to the temporary snapshot's ID.
Source image The source image field is empty.
Image ID The image ID is empty.
Last detached timestamp The last detached timestamp is empty.
Last attached timestamp The last attached timestamp changes to the timestamp when the new disk was attached to the new instance.

Properties changing for both instances and disks

Property name Changes
ID A new resource ID is generated.
Creation timestamp A new creation timestamp is generated.
Zone resource URLs All zone resource URLs change to reflect the destination zone. The following list shows the resource URLs that change:
  • An instance's source disk URL
  • An instance's machine type URL
  • Self-link URLs
  • Zone URLs
  • Disk type URLs
  • Any URLs of instances listed in a disk's users[] list

Moving an instance automatically

Before you move an instance, ensure that you review the requirements and limitations.


Make sure that your instance is running. Then, using the gcloud tool, run the compute instances move subcommand to move your instance.

For example, to move an instance called example-instance-1 with all its attached persistent disks from us-central1-b, where it is currently running, to us-central1-f, its new region, run the following command:

gcloud compute instances move example-instance-1 \
    --zone us-central1-b --destination-zone us-central1-f


In the API, make a POST request to the moveInstance API with a request body that contains the targetInstance and the destinationZone. For example:

   "targetInstance": "zones/us-central1-b/instances/example-instance-1",
   "destinationZone": "zones/us-central1-f"

Moving an instance manually

Whenever possible, move an instance automatically using the moveInstance API, which handles all the steps for moving an instance for you. However, if you cannot use the API, you can perform the move manually.

The following example describes how to move an instance myinstance with two persistent disks, mybootdisk and mydatadisk, from europe-west1-a to us-west1-b. The example instance looks like the following:

gcloud compute instances list
myinstance europe-west1-a n1-standard-4 RUNNING

To move the instance to another zone:

  1. Identify the disks that are associated with the instance that you want to move.

    Go to the disks page

    In this example, you find the following 2 associated disks for the myinstance instance:

    • A boot disk called mybootdisk
    • A data disk called mydatadisk
  2. Set the auto-delete state of mybootdisk and mydatadisk to false to ensure that the disks are not automatically deleted when the instance is deleted.

    gcloud compute instances set-disk-auto-delete myinstance --zone europe-west1-a \
        --disk mybootdisk --no-auto-delete

    If the state was updated, gcloud compute returns the response Updated [...]. If the auto-delete state was already set to false, then gcloud compute returns:

    No change requested; skipping update for [myinstance].
  3. (Optional) Save your instance metadata.

    When you delete your instance, the instance metadata is also removed. You can save that information in a separate file, then reapply the instance metadata to the new instance.

    Describe your instance's metadata like so:

    gcloud compute instances describe myinstance --zone europe-west1-a

    Save the contents to a separate file.

  4. Create backups of your data.

    As a precaution, create backups of your data while the persistent disks are still attached to the instance by using persistent disk snapshots. Before you take a snapshot, ensure that your snapshot is consistent with the state of the persistent disk by clearing your disk buffers.

    After you clear your disk buffers, create the snapshots:

    gcloud compute disks snapshot mybootdisk mydatadisk \
        --snapshot-names backup-mybootsnapshot,backup-mydatasnapshot \
        --zone europe-west1-a

    To verify that the snapshot is created, run gcloud compute snapshots list.

  5. (Optional) If you're moving an instance across zones within the same region, and you want to preserve its ephemeral internal or external IP address, promote the internal or external IP address to a static IP address, which you can reuse later.

  6. Delete your instance.

    Deleting your instance will shut it down cleanly and detach any persistent disks.

    gcloud compute instances delete myinstance --zone europe-west1-a

    gcloud prompts you to confirm the deletion:

     The following instances will be deleted. Any attached disks configured to
     be auto-deleted will be deleted unless they are attached to any other
     instances or the --keep-disks flag is given and specifies them for keeping.
     Deleting a disk is irreversible and any data on the disk will be lost.
      — [myinstance] in [europe-west1-a]

    Do you want to continue (Y/n)?

    Because you turned off the auto-delete state for the disks earlier in this process, enter Y to continue and ignore the warning.

  7. Next, create another snapshot of both the boot disk and the data disk.

    gcloud compute disks snapshot mybootdisk mydatadisk \
        --snapshot-names mybootsnapshot,mydatasnapshot \
        --zone europe-west1-a
    Created [.../mydatasnapshot].
    Created [.../mybootsnapshot].
  8. (Optional) Delete your persistent disks.

    If you plan to reuse the names of the persistent disks for the new disks, you must delete the existing disks to release the names. Deleting your disks also saves on persistent disk storage costs.

    If you do not plan to reuse the same disk names, you don't need to delete them.

    gcloud compute disks delete mybootdisk mydatadisk --zone europe-west1-a
  9. Create new persistent disks in us-west1-b from the snapshots you created. First create the boot disk.

    gcloud compute disks create mybootdiskb --source-snapshot mybootsnapshot \
        --zone us-west1-b
    Created [.../mybootdiskb].
    NAME        ZONE           SIZE_GB TYPE        STATUS
    mybootdiskb us-west1-b     100     pd-standard READY

    Then create the data disk.

    gcloud compute disks create mydatadiskb --source-snapshot mydatasnapshot \
        --zone us-west1-b
    Created [.../mydatadiskb].
    NAME        ZONE           SIZE_GB TYPE        STATUS
    mydatadiskb us-west1-b 4000    pd-standard READY
  10. Recreate your instance in us-west1-b.

    • If you had opted to save your instance metadata in a file, for example myinstance.describe, you can use it to set the same metadata on your instance.

    • If your instance had a static external IP address, you can reassign that address to your new instance by specifying the --address [ADDRESS] option. If you are moving an instance across regions, you must pick a different external IP address for the new VM instance.

    • If your instance had a static internal IP address, you can reassign that address to your new instance by specifying the --private-network-ip ADDRESS option. If you are moving an instance across regions, you must pick a different internal IP address for the new VM instance.

    • If your instance included GPUs, add GPUs to the instance using the --accelerator option.

    • If the instance uses a specific subnet, add the --subnet [SUBNET_NAME] flag.

    For a complete list of additional flags, see gcloud compute instances create.

    gcloud compute instances create myinstanceb --machine-type n1-standard-4 \
        --zone us-west1-b \
        --disk name=mybootdiskb,boot=yes,mode=rw \
        --disk name=mydatadiskb,mode=rw
    Created [.../myinstanceb].
    myinstanceb us-west1-b     n1-standard-4 RUNNING
  11. (Optional) Delete your persistent disk snapshots.

    After you confirm that your virtual machines are moved, save on storage costs by deleting the temporary snapshots that you created.

    gcloud compute snapshots delete mybootsnapshot mydatasnapshot

    If you no longer need your backup snapshots, delete those snapshots as well:

    gcloud compute snapshots delete backup-mybootsnapshot backup-mydatasnapshot

What's next