概要
使わない期間の EC2 インスタンスを止めておけば、インスタンスの料金はかかりません。ただし通常の「停止」では、メモリ（RAM）の内容は消えます。メモリ上にキャッシュやセッション、処理途中のデータを持つアプリケーションは、次に起動したときに一からやり直しになります。
休止（ハイバネーション）を使うと、インスタンスを止める前に RAM の内容を EBS のルートボリュームに保存し、次に起動したときに読み戻してプロセスを再開できます。ノート PC のふたを閉じて、開けたら作業の続きから始められるのと同じ考え方です。一方で、休止は起動時に有効にしておく必要があり、ルートボリュームの暗号化やサイズなどの条件もあります。
この記事では、EC2 インスタンスを止める方法（停止・休止・終了）で何が残り何が消えるかを比較し、休止の条件を整理します。実践では、休止を有効にしたインスタンスでメモリ上にファイルを置き、休止と停止でその後の結果が変わることを確かめます。
クラウドおさる猿山の冬ごもりでも、ただ眠るだけだと何を考えていたか忘れてしまうでござる。今日は、頭の中身を帳面に書き残してから眠る「休止」と、ただの「停止」で、起きたときに何が残っているかを確かめるでござるよ。
この記事のメリット
- 停止・休止・終了（と再起動）で、RAM・ボリューム・IP アドレス・課金がどう変わるかを説明できるようになる
- 休止の仕組み（RAM の内容を EBS ルートボリュームに保存して読み戻す）が分かる
- 休止を使うための条件（起動時の有効化・ルートボリュームの暗号化とサイズ・対応インスタンス・RAM の上限）を押さえられる
- 休止できないケース（Auto Scaling グループのインスタンスなど）と、60 日の上限を把握できる
- 「メモリの内容を残したまま止めたい」という要件に対して、スナップショットやインスタンスストアではなく休止を選べるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
インスタンスを止める 4 つの操作
EC2 インスタンスには、止め方・やり直し方が 4 つあります。どれを選ぶかで、残るものが変わります。
| 項目 | 再起動 | 停止 | 休止 | 終了 |
|---|---|---|---|---|
| RAM（メモリの内容） | 消える | 消える | ルートボリュームに保存され、起動時に読み戻される | 消える |
| ルートボリューム（EBS） | 残る | 残る | 残る | 既定では削除される |
| インスタンスストアのデータ | 残る | 消える | 消える | 消える |
| プライベート IPv4 アドレス | 残る | 残る | 残る | なし |
| パブリック IPv4 アドレス | 残る | 新しいアドレスになる | 新しいアドレスになる | なし |
| Elastic IP アドレス | 関連付けが残る | 関連付けが残る | 関連付けが残る | 関連付けが解除される |
| ホスト | 同じホスト | 新しいホストに移ることがある | 新しいホストに移ることがある | なし |
| インスタンスの課金 | 続く | stopping になった時点で止まる | stopping の間は続き、stopped で止まる | shutting-down になった時点で止まる |
停止中・休止中も、EBS ボリュームのストレージ料金はかかります。休止では、保存した RAM の内容も EBS のストレージとして課金されます。
クラウドおさるスナップショットはディスクの写しで、メモリの中身は入らないでござる。インスタンスストアは停止でも休止でも消えるでござる。「メモリの内容を残したまま止める」なら休止、と覚えておくでござるぞ。
休止の仕組み
休止を指示すると、インスタンスは次のように動きます。
- インスタンスが
stopping状態になり、EC2 が OS に休止処理（suspend-to-disk）を指示する - すべてのプロセスがフリーズされ、RAM の内容が EBS ルートボリュームに保存される
- 通常のシャットダウンが行われ、インスタンスが
stopped状態になる
もう一度起動すると、OS がルートボリュームから RAM の内容を読み取り、プロセスのフリーズが解除されて休止前の状態に戻ります。インスタンス ID も変わりません。OS は起動し直していないため、休止前から動いていたプロセスもそのまま続きます。
休止を使うための条件
休止は、どのインスタンスでも使えるわけではありません。主な条件は次のとおりです。
| 条件 | 内容 |
|---|---|
| 有効にするタイミング | 起動時に有効にする。実行中・停止中の既存のインスタンスで後から有効にすることはできない |
| インスタンスファミリー | 休止に対応したファミリー（汎用なら M5・T3・T3a・T4g など）。ベアメタルは非対応 |
| RAM の大きさ | Linux は 150 GiB 未満、Windows は 16 GiB 以下。T3・T3a は 1 GiB 以上を推奨 |
| AMI | 休止に対応した HVM AMI（Amazon Linux 2023 は 2023 年 9 月 20 日以降にリリースされたもの など） |
| ルートボリューム | インスタンスストアではなく EBS（gp2・gp3・io1・io2）。暗号化が必須で、RAM の内容を書き込める大きさが要る |
ルートボリュームの暗号化が必須なのは、休止中にディスクへ書き出したメモリの内容に、機密性の高いデータが含まれる可能性があるためです。
休止の制限
休止には、ほかにも制限があります。
- Auto Scaling グループのインスタンスは休止できない。休止させようとすると、Auto Scaling が停止したインスタンスを異常と判断し、終了して代わりを起動することがある（Amazon ECS で使っているインスタンスも同様）
- 60 日を超える休止はサポートされない。それより長く置くなら、一度起動してから停止し直す
- 休止中のインスタンスは、インスタンスタイプなどの属性を変更できない（通常の停止中なら変更できる）
- インスタンスストアボリューム上のデータは失われる
クラウドおさる休止は「起動するときに休止の札を付けておく」のが前提でござる。動いているインスタンスに後から札を付けることはできぬので、休止を使いたい用途なら、起動の時点で決めておくのでござるな。
実践
休止を有効にした EC2 インスタンスを起動し、メモリ上（/dev/shm）にファイルを置きます。休止してから起動するとファイルと稼働時間が残り、停止してから起動すると消えることを確かめます。
/dev/shm は、Linux がメモリ上に用意するファイル置き場（tmpfs）です。ここに置いたファイルはディスクではなく RAM にあるため、メモリの内容が残ったかどうかを目で確かめる目印になります。
前提条件
- リージョン:
ap-northeast-1（東京） - EC2・Systems Manager の操作権限を持つ IAM ユーザーまたはロールでコンソールにログイン済みであること
以下のリソースが作成済みであることを前提とします。
まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。
| リソース種別 | リソース名 | 内容 | 作り方の参考 |
|---|---|---|---|
| VPC | hib-lab-vpc | CIDR 10.0.0.0/16 | Amazon VPC で仮想ネットワークを構築しサブネットを設定する |
| パブリックサブネット | hib-lab-public-1a | 10.0.1.0/24（ap-northeast-1a）。インターネットゲートウェイへのルートあり、パブリック IPv4 アドレスの自動割り当て有効 | 同上 |
| セキュリティグループ | hib-lab-sg | インバウンドルールなし（Session Manager で接続するため） | 同上 |
| IAM ロール / インスタンスプロファイル | hib-lab-ssm-role / hib-lab-ssm-profile | AmazonSSMManagedInstanceCore をアタッチ | AWS Systems Manager でインスタンスをリモート管理する |
このハンズオンで作成するリソースは以下のとおりです。
| リソース種別 | リソース名 | 内容 |
|---|---|---|
| EC2 インスタンス | hib-lab-instance | Amazon Linux 2023・t3.micro・休止を有効化・ルートボリューム 8 GiB（gp3・暗号化） |
休止中・停止中も、EBS ボリュームのストレージ料金はかかります。検証が終わったら必ずインスタンスを終了してください。
手順 1: 休止を有効にしてインスタンスを起動する
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに EC2 と入力し、「EC2」を選択します。左側ナビゲーションの「インスタンス」を選択し、右上の「インスタンスを起動」をクリックします。以下を設定します。
- 名前:
hib-lab-instance - アプリケーションおよび OS イメージ:
Amazon Linux 2023 AMI（既定のまま） - インスタンスタイプ:
t3.micro - キーペア:
キーペアなしで続行 (推奨されません)（接続は Session Manager で行います） - ネットワーク設定: 「編集」をクリックし、VPC
hib-lab-vpc、サブネットhib-lab-public-1a、パブリック IP の自動割り当て有効化を選択。「既存のセキュリティグループを選択する」を選び、「共通のセキュリティグループ」でhib-lab-sgを選択
「ストレージを設定」で右側の「アドバンスト」をクリックし、「ボリューム 1 (AMI ルート)」を展開して、以下のように設定します。
- サイズ (GiB):
8（既定のまま。t3.microの RAM は 1 GiB なので、OS と RAM の内容を書き込める） - ボリュームタイプ:
gp3 - 暗号化済み:
暗号化済み（既定は暗号化なし） - KMS キー:
(デフォルト) aws/ebs（暗号化済みにしても自動では入らないので、一覧から選びます）
「高度な詳細」を展開し、以下を設定します。
- IAM インスタンスプロフィール:
hib-lab-ssm-profile - 停止 – 休止動作:
有効化（既定は未選択。ルートボリュームが暗号化されている必要がある、という説明が表示されます）
その他の項目はデフォルトのままにして、右側の「インスタンスを起動」をクリックします。
インスタンスの一覧で hib-lab-instance を選択し、下部の「詳細」タブを下にスクロールして、「停止 – 休止動作」が 有効 になっていることを確認します。
手順 2: メモリ上にファイルを置く
インスタンスの状態が「実行中」になってから 1〜2 分待ちます。hib-lab-instance を選択して右上の「接続」をクリックし、「Session Manager」タブで「接続」をクリックします。
開いたターミナルで、次のコマンドを実行します。
echo "banana-$(date +%H%M%S)" > /dev/shm/memo.txt
cat /dev/shm/memo.txt
uptime -s/dev/shm/memo.txt の中身と、OS が起動した時刻（uptime -s の結果）を控えておきます。
Session Manager のタブは閉じて構いません。
手順 3: 休止して、もう一度起動する
インスタンスの一覧で hib-lab-instance を選択し、「インスタンスの状態」→「インスタンスを休止」をクリックします。確認画面で「休止」をクリックします。
インスタンスの状態が「停止中」を経て「停止済み」になったら、「インスタンスの状態」→「インスタンスを開始」をクリックします。状態が「実行中」になったら、手順 2 と同じように Session Manager で接続し、次のコマンドを実行します。
cat /dev/shm/memo.txt
uptime -s手順 2 で置いたファイルが残っており、OS の起動時刻も手順 2 と同じであることを確認します。メモリの内容が読み戻され、OS は起動し直さずに休止前の続きから動いています。
クラウドおさる帳面に書き残してから眠ったので、起きたら書きかけのメモも、眠る前からの稼働時間もそのままでござる。これが休止でござるな。
手順 4: 停止して、もう一度起動する
比べるために、今度は通常の停止を試します。hib-lab-instance を選択し、「インスタンスの状態」→「インスタンスを停止」をクリックします。
インスタンスの状態が「停止済み」になったら「インスタンスを開始」をクリックし、「実行中」になったら Session Manager で接続して同じコマンドを実行します。
cat /dev/shm/memo.txt
uptime -scat は「No such file or directory」となり、起動時刻も新しい時刻に変わっていることを確認します。停止では RAM の内容が捨てられ、OS が一から起動し直しています。
クラウドおさる「止めている間もメモリの内容を残したい」と言われたら休止、「インスタンスタイプを変えたい」なら休止ではなく停止、でござる。休止は起動時に有効にしておく必要がある点も、取り違えやすいところでござるな。
まとめ
| やりたいこと | 選ぶ操作 |
|---|---|
| メモリの内容を残したまま止め、続きから再開したい | 休止（起動時に有効化が必要） |
| 料金を止めたいが、メモリの内容は捨ててよい | 停止 |
| インスタンスタイプなどを変更したい | 停止（休止中は変更できない） |
| OS だけ再起動したい | 再起動（課金は続き、IP アドレスもそのまま） |
| インスタンスを使い終えた | 終了（ルートボリュームは既定で削除される） |
- 休止は、RAM の内容を EBS ルートボリュームに保存してからシャットダウンし、起動時に読み戻してプロセスを再開する
- 休止は起動時に有効にする必要があり、ルートボリュームの暗号化と、RAM の内容を書き込めるサイズが要る
- インスタンスストアのデータは、停止でも休止でも消える。スナップショットにはメモリの内容は入らない
- Auto Scaling グループのインスタンスは休止できない。休止は 60 日までで、休止中はインスタンスタイプを変更できない
- 停止・休止中もパブリック IPv4 アドレスは変わり、EBS のストレージ料金はかかる
参照先
- Amazon EC2 インスタンスの休止 – Amazon Elastic Compute Cloud
- Amazon EC2 インスタンスの休止の仕組み – Amazon Elastic Compute Cloud
- EC2 インスタンスの休止の前提条件 – Amazon Elastic Compute Cloud
- Amazon EC2 インスタンスの休止の有効化 – Amazon Elastic Compute Cloud
- Amazon EC2 インスタンスの状態変更 – Amazon Elastic Compute Cloud
