---
title: "Compute Engineのゾーンを変更するには移動が必要である | grasys blog"
url: "https://blog.grasys.io/post/shirota/movezone-gce/"
description: "こんにちは、shirotaです。 今回はCompute Engineのゾーン移動をテーマに書きたいと思います。 例えば、開発の用途で使用しているインスタンスを営業時間帯のみ起動して利用している場合など、 夜間停止して翌朝に起動しようとしたらプラットフォーム側で物理的なキャパシティが不足していて起動エラーになることがあ…"
---

# Compute Engineのゾーンを変更するには移動が必要である

-   ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[shirota](/authors/shirota/)
-   公開日：2026年7月8日
-   カテゴリー：[Tech](/categories/tech/)
-   タグ：[#Compute Engine](/tags/compute-engine/)[#Google Cloud](/tags/google-cloud/)

![Compute Engineのゾーンを変更するには移動が必要である](/_astro/hero.65eU8GDR_Z1OSD19.webp)

こんにちは、shirotaです。

今回はCompute Engineのゾーン移動をテーマに書きたいと思います。  
例えば、開発の用途で使用しているインスタンスを営業時間帯のみ起動して利用している場合など、  
夜間停止して翌朝に起動しようとしたらプラットフォーム側で物理的なキャパシティが不足していて起動エラーになることがあります。

このような場合、対処方法としては状況の改善を待つ、マシンタイプを変更して利用するといった方法がありますが、利用しているゾーンを移動することで解決する場合もあります。

しかし、インスタンスのゾーン変更は、設定変更して起動して完了！…というわけにはいかず、インスタンスを別のゾーンに再作成する必要があります。  
なので、移行ではなく、移動なんですね。  
公式ドキュメントもmigrationではなくmoveが使われているのも、そういうニュアンスなのかなと思いました。

本記事では実際にゾーンの移動をしてみて感じた留意点なども書きたいと思いますので、最後までお付き合いいただければ幸いです。

移動に使用するインスタンスは以下の内容で用意しました。

1.  外部ディスクがアタッチされている
    
2.  外部IPアドレスは静的IPアドレスを使用している
    
3.  マシンタイプはE2 Mediumを使用している
    
4.  asia-northeast1-aを利用している
    
5.  ディスクはゾーンディスク
    

gcloud CLIを使用して情報を見てみます。

Bashcontent\_copy

```
gcloud compute instances list \
  --filter="name=shirota-test" \
  --format="table(name:label=VM_NAME,zone.basename():label=ZONE,machineType.basename():label=MACHINE_TYPE,networkInterfaces[0].networkIP:label=INTERNAL_IP,networkInterfaces[0].accessConfigs[0].natIP:label=EXTERNAL_IP,disks[0].source.basename():label=BOOT_DISK,disks[1].source.basename():label=EXTERNAL_DISKS)"

VM_NAME       ZONE               MACHINE_TYPE  INTERNAL_IP  EXTERNAL_IP   BOOT_DISK     EXTERNAL_DISKS
shirota-test  asia-northeast1-a  e2-medium     10.0.0.194   xx.xxx.xxx.xx  shirota-test  shirota-test-data
```

そして、移動の要件は以下の通りです。

1.  VM、ディスクの名前が変わらないこと
    
2.  外部IPアドレスが変わらないこと
    
3.  内部IPアドレスが変わらないこと
    
4.  asia-northeast1-bを利用していること
    

ゾーンを移動しつつ、リソースの名前とIPアドレスを変えないことで、DNSの変更や接続情報の変更が生じずに新しいゾーンでインスタンスを利用できることを目的としています。

## 留意事項

・今回使用するリソースはTerraformで管理しており、作業のなかでもリソースの作成や削除に利用しています。  
Terraformを使用した作業は本質的な部分ではないため、割愛しておりますので、あらかじめご了承ください。

・インスタンスが停止していることを前提としています。  
もし別の理由で起動中のインスタンスを移動する場合は、インスタンスの利用を止めずに作業するとデータの不整合などの問題が生じますのでご注意ください。

それでは、インスタンスの移動を始めたいと思います！

## 作業

(1). スナップショットの作成  
早速今回の肝となる作業です。  
インスタンスにアタッチするディスクは同じゾーンにある必要があるので、スナップショットを作成して移動先のゾーンにディスクを作成する必要があります。  
ブートディスクとアタッチディスクの両方のスナップショットを作成します。

Bashcontent\_copy

```
gcloud compute snapshots create snapshot-shirota-test \
  --source-disk=shirota-test \
  --snapshot-type=STANDARD \
  --source-disk-zone=asia-northeast1-a
```

Bashcontent\_copy

```
gcloud compute snapshots create snapshot-shirota-test-data \
  --source-disk=shirota-test-data \
  --snapshot-type=STANDARD \
  --source-disk-zone=asia-northeast1-a
```

(2). 内部IPアドレスを静的IPアドレスへ昇格  
Terraformで静的IPとしてリソースを作成します。  
移動元のインスタンスで使用している内部IPアドレスは自動的に払い出されたアドレスを使用しています。  
そのため、インスタンスの削除を行うとIPアドレスが解放されて、ほかのリソースが使用できるようになります。  
静的IPアドレスに昇格させることでほかのリソースへ自動で払い出すことを防止します。

(3). インスタンスの削除  
Terraformで削除します。  
同じ名前でインスタンスとディスクを作成するため、移動元のリソースは先に削除します。

(4). ディスクの削除  
Terraformで削除します。  
ブートディスクはインスタンスの削除の際に一緒に削除される設定になっているので、  
今回は外部ディスクのみ削除します。

(5). スナップショットから外部ディスクを作成  
Terraformで作成します。  
外部ディスクをスナップショットから移動先のゾーンを指定して再作成します。

(6). 移動先のゾーンでインスタンスを作成  
Terraformで作成します。  
ブートディスクのスナップショットからインスタンスを再作成します。  
移動先のゾーンのほか、外部IPアドレスと内部IPアドレスに移動元で利用していたIPアドレスを指定します。  
また、先ほど作成した外部ディスクをこのタイミングでアタッチします。

(7). 確認  
リソースの名前とIPアドレスはそのままにゾーンをaからbへ移動することができました。  
移動のあとはインスタンスに接続して、プロセスの状態やディスクのマウント設定などを確認します。  
また、gcloudCLI を利用してSSHやバックアップなどを行なっている場合、ゾーンの指定を変更する必要があるので、バッチ処理などを一通り確認します。

Bashcontent\_copy

```
gcloud compute instances list \
  --filter="name=shirota-test" \
  --format="table(name:label=VM_NAME,zone.basename():label=ZONE,machineType.basename():label=MACHINE_TYPE,networkInterfaces[0].networkIP:label=INTERNAL_IP,networkInterfaces[0].accessConfigs[0].natIP:label=EXTERNAL_IP,disks[0].source.basename():label=BOOT_DISK,disks[1].source.basename():label=EXTERNAL_DISKS)"

VM_NAME       ZONE               MACHINE_TYPE  INTERNAL_IP  EXTERNAL_IP   BOOT_DISK     EXTERNAL_DISKS
shirota-test  asia-northeast1-b  e2-medium     10.0.0.194   xx.xxx.xxx.xx  shirota-test  shirota-test-data
```

(8). スナップショットの削除  
ディスクの再作成に利用したスナップショットは他に利用用途がなければ削除します。

## まとめ

最後に今回の作業を通して感じたことをまとめてみたいと思います。

### ゾーン移動を試す価値はあるのか

インスタンスが起動できない状態というのは、予定していた業務や運用に影響がでるため、一刻も早く起動したいところです。  
もちろん、リージョン全体でリソースの逼迫状況が深刻化している場合は、ゾーンを移動したとしても起動できる保証はありません。しかし、今回見てきたようにゾーンの移動自体はそれほど複雑な作業ではないため、「初手のアプローチ」として検討するのはアリだと思います。

### ゾーン移動に伴う影響には注意が必要

一方で、ゾーン移動を行う際に気になったのが、「移動したあとの、他の処理への影響」です。  
ゾーンを明示的に指定して実行している処理がある場合は、全て変更する必要があるため、注意が必要です。

### スムーズな対応には日頃からの備えが大切

スピード感を持って対応するには、リソースをIaCで管理しておく、また要件を整理しておくことが大切です。  
例えば、ロードバランサーを利用してバックエンドにインスタンスを配置している構成では、インスタンスの外部IPアドレスは考慮しなくてよいかもしれません。構成に沿った要件を整理しておくことで、いざという時に迅速に対応に進むことができます。

今回、必要になる状況は少ないかなぁ…と思いつつここまで書きましたが、ゾーン移動の検討が必要になった際に、こちらの記事が少しでもお役に立てば幸いです。  
最後までお読みいただきありがとうございました。

## 参考

[Move a VM instance between zones or regions](https://docs.cloud.google.com/compute/docs/instances/moving-instance-across-zones)

## この記事を書いた人

[![](/_astro/noicon.CTHOhNiB_Z24aAgM.webp)](/authors/shirota/)

### [shirota](/authors/shirota/)

shirotaのプロフィールと執筆記事をご覧いただけます。

[プロフィールと記事一覧](/authors/shirota/)