コンピューティング・ 2026-05-18

EC2 Hibernation 機能の仕組みと使い所完全ガイド

EC2 の Stop と区別される第 3 の状態「Hibernation（休止）」を整理。RAM 内容を EBS に書き戻して停止 → 起動時にプロセス・メモリ状態ごと復元する仕組み、Linux 150 GiB / Windows 16 GiB といった前提条件、暗号化必須・60 日制限・Auto Scaling 非対応などの制約、現場で生きるユースケース 5 つまでまとめる。

#AWS #EC2 #Hibernation #休止 #コスト最適化 #コンピューティング

EC2 を「止めるけど次回はすぐ作業を再開したい」— その間にあるのが Hibernation（休止）。Stop と Terminate の中間に位置する第 3 の状態を、現場の使い所と一緒に整理する。

1. 概要（端的に）

EC2 Hibernation（休止）は、インスタンスの RAM 内容を EBS ルートボリュームに書き戻してから停止し、次回起動時にメモリ状態ごと復元する機能。ノート PC を閉じたときの「スリープではなく休止状態（suspend-to-disk）」と同じ発想で、OS・プロセス・ロード済みのライブラリ・JIT 最適化済みの JVM ヒープまで「そのまま」凍結できる。

通常の Stop が「電源を切るだけ（RAM は揮発）」なのに対し、Hibernation は 「次回起動でログイン直後の状態に戻る」 のが本質的な違い。長いブートアップやウォームアップが必要なアプリケーションでこそ真価を発揮する。

2. Stop / Hibernate / Terminate の関係

Amazon EC2 の停止系アクションは 3 つあり、それぞれ揮発するものと永続するものが違う。

Stop / Hibernate / Terminate の比較

評価項目	Stop	Hibernate 推奨	Terminate
RAM 内容	失われる	EBS に保存 → 復元	失われる
実行中プロセス	すべて終了	フリーズして復元	すべて終了
次回起動時の状態	通常ブート	直前の状態を復元	不可（再作成）
インスタンス自体	保持	保持	消滅
ルート EBS	保持	保持（拡張）	既定で削除
EC2 課金	停止	停止	消滅
EBS 課金	継続	継続（RAM サイズ分も）	削除されれば停止
パブリック IP	解放	解放	解放
事前準備	不要	起動時に有効化必須	不要

Hibernate は『状態保持つき Stop』。起動時の有効化忘れに注意。

特に重要なのが 「Hibernation は起動時にしか有効化できない」 という点。既存の停止中インスタンスに後付けでオンにすることはできない。

3. 仕組み：どうやって RAM を保存しているか

休止操作の裏側で起こっていることを順に追うと、Hibernation の特性が見えてくる。

休止トリガー：マネジメントコンソールで Stop - Hibernate 実行、または aws ec2 stop-instances --hibernate
OS への通知：ハイパーバイザーがゲスト OS に suspend-to-disk を要求
メモリダンプ：OS が全プロセスを凍結し、RAM 全域を EBS ルートボリューム上のスワップ／予約領域へ書き出す
EBS 暗号化：書き出される内容は 必ず KMS で暗号化 される（強制）
シャットダウン：通常の電源 OFF と同じ手順で停止
再起動時：起動シーケンスの初期段階で OS がスワップ領域を検出 → RAM へ書き戻し → 凍結を解除してプロセス再開

ポイントは EBS ルートボリュームに RAM サイズ分の余裕が必要 ということ。たとえば RAM 32 GiB のインスタンスなら、ルートボリュームに少なくとも 32 GiB 以上の空きを確保しておかないと休止に失敗する。多くの構築ガイドが「ルートボリュームは RAM の 2 倍を推奨」と言っているのはこれが理由。

4. 利用するための前提条件（チェックリスト）

AWS の公式前提条件ページに従って、休止を使うための条件を整理する。

4-1. インスタンス側

項目	条件
インスタンスファミリ	対応ファミリのみ（後述）／ベアメタルは不可
RAM サイズ	Linux 150 GiB 未満／Windows 16 GiB 以下／Spot 100 GiB 未満
仮想化タイプ	HVM のみ（PV は不可）
AMI	休止対応 AMI（Amazon Linux 2/2023・Ubuntu・RHEL・Windows Server 各種公式 AMI は対応）
ブートモード	UEFI Secure Boot 有効では不可

4-2. ストレージ側

項目	条件
ルートボリューム	EBS のみ（インスタンスストアは不可）
ルートボリューム暗号化	必須（KMS で暗号化された EBS を起動時にアタッチ）
ルートボリュームサイズ	RAM 内容を保存できる容量（実質 RAM サイズ＋OS／アプリ領域）

4-3. 起動時オプション

--hibernation-options Configured=true を 起動時に明示 する必要がある。CloudFormation なら HibernationOptions プロパティで宣言できる。

aws ec2 run-instances \
  --image-id ami-xxxxxxxx \
  --instance-type m6i.large \
  --key-name my-key \
  --block-device-mappings 'DeviceName=/dev/xvda,Ebs={VolumeSize=30,Encrypted=true}' \
  --hibernation-options 'Configured=true'

4-4. 対応インスタンスファミリ（抜粋）

汎用・コンピューティング最適化が中心。AWS Graviton 系（M6g/M7g/M8g、C6g/C7g/C8g、T4g など）も 2024 年から対応した。

カテゴリ	対応ファミリ（例）
汎用	M3〜M8（M5a/M5d、M6a/M6i/M6g、M7a/M7g/M7i、M8a/M8g/M8i 等）／T2・T3・T3a・T4g
コンピューティング最適化	C3〜C8（C5d、C6g/C6i/C6gn、C7g/C7i/C7gn、C8g/C8i 等）
メモリ最適化	R3〜R8 系の一部（公式ドキュメントで都度確認）

対応ファミリ・インスタンスサイズは頻繁に拡張されるため、本番設計時は公式前提条件を必ず最新で確認すること。

5. 操作手順（最短ルート）

5-1. マネジメントコンソールから

起動ウィザード → 「Advanced details」→ 「Stop - Hibernate behavior」を Enable
ルートボリュームを 暗号化済み EBS に設定（RAM サイズ＋α 以上の容量を確保）
インスタンスを起動して任意の作業を実施
「Actions」→「Instance state」→「Hibernate instance」

5-2. CLI から

# 休止
aws ec2 stop-instances --instance-ids i-0123456789abcdef0 --hibernate

# 起動（通常の start で OK。状態が復元される）
aws ec2 start-instances --instance-ids i-0123456789abcdef0

5-3. CloudFormation で宣言する場合

Resources:
  MyHibernatableInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-xxxxxxxx
      InstanceType: m6i.large
      HibernationOptions:
        Configured: true
      BlockDeviceMappings:
        - DeviceName: /dev/xvda
          Ebs:
            VolumeSize: 30
            Encrypted: true
            VolumeType: gp3

6. 現場で生きる活用パターン 5 つ

6-1. 長時間ウォームアップが必要な分析・ML ワークロード

JVM の JIT 最適化、Python のモデル事前読込、巨大インメモリキャッシュの構築— 数分〜数十分かかる「準備」を、休止 → 復帰で 数秒スキップ できる。検証用 EC2 や個人開発環境で特に効く。

6-2. 開発者個人用 EC2 の「使わない夜はサスペンド」

クラウド IDE や踏み台として開発者ごとに 1 台 EC2 を割り当てている場合、夜間〜週末は休止しておくと EC2 課金は停止しつつ、開いていたエディタ・ターミナル・実行中のプロセスは全部生き残る。朝起動すれば「昨日の続き」から再開できる。

6-3. Spot Interruption に備える「セーフネット」

EC2 Spot Instances は突然中断される可能性があるが、Hibernation を組み合わせると 中断通知から 2 分以内に休止 → 別容量で再開 という運用が可能になる。バッチ処理や CI ジョブで「中断されてもチェックポイントから再開」しなくて済むメリットは大きい（Spot Hibernate は RAM 100 GiB 未満などやや厳しい条件あり）。

6-4. ライセンス制約があるソフトの状態保持

商用ソフトでセッション初期化やライセンス認証に時間がかかる場合、Hibernation で「ライセンス検証済みの状態」を凍結しておけば、起動のたびに認証手続きを走らせずに済む。Windows + 重い CAD／EDA ツールでよく使われる。

6-5. デモ・ハンズオン環境の即時起動

ハンズオン研修用に 30〜40 台同時に起動する EC2 を、前夜に「環境構築済み」の状態で休止しておき、当日朝一斉に start することで、ブート＋セットアップ時間を完全にスキップできる。

7. 制約・注意事項

7-1. 60 日制限

休止状態のまま放置できる期間は 最大 60 日。それを超えると AWS 側で再開できなくなるリスクがあるため、月次で「起動 → 停止 → 起動」サイクルを回すジョブを仕込んでおくのが定石。

7-2. 仕組み上できないこと

項目	状況
Auto Scaling 配下	EC2 Auto Scaling で起動するインスタンスは不可
ECS が使うインスタンス	クラスターメンバーとしては不可
インスタンスストア起動	ルートが Instance Store の場合は不可
ベアメタル	不可（仮想化されていないため）
暗号化なし EBS	不可（KMS 暗号化が強制）
UEFI Secure Boot	Secure Boot 有効では不可

7-3. パブリック IP は維持されない

Stop/Hibernate どちらも パブリック IPv4 は解放 される（Elastic IP を割り当てている場合のみ維持）。状態は復元されるが、外部接続経路は別途設計が必要。

7-4. メモリは EBS 上に書かれている

RAM の内容が 暗号化されているとはいえ EBS に物理的に存在する ことを忘れない。本番系で機密データを扱う場合は KMS のキーポリシー・キーローテーション・スナップショット権限まで含めて監査範囲に入れる。

8. メリット・デメリット

メリット

OS・プロセス・JVM ヒープ等の「ウォームアップ済み状態」を維持できる（起動が爆速）
Spot Interruption に対する救命策として組み込める
開発者個人用 EC2 を夜間休止することで EC2 課金のみ停止できる
AMI を焼き直さずに「初期化済み環境」を保てる
休止操作は OS の標準的な suspend-to-disk なのでアプリ改修が不要

デメリット

EBS の容量分（RAM サイズ分を含む）の課金は休止中も継続する
起動時にしか有効化できず、既存インスタンスに後付け不可
Linux 150 GiB／Windows 16 GiB のメモリ上限と、対応ファミリの制約がある
Auto Scaling / ECS など「動的に作って壊す」基盤と相性が悪い
ルート EBS の暗号化が強制で、KMS の運用設計が前提になる
休止状態のまま 60 日を超えるとサポート対象外になる

9. ベストプラクティス

ルートボリュームは RAM サイズの 2 倍以上を目安に確保する — RAM 領域に加え OS・アプリ・スワップ予約が同居するため、ギリギリで切ると休止が失敗する。
暗号化 KMS キーは『EC2 用』として分離管理 — 既定の aws/ebs キーで始めて構わないが、本番では業務ごとの CMK に切り替えると監査・ローテーションがしやすい。
60 日対策のスケジューラを必ず仕込む — EventBridge で月次に start-instances → stop-instances --hibernate を回す Lambda を組んでおく。
Elastic IP を割り当てる — クライアントから接続される運用 EC2 で休止を使うなら、復帰後の IP 変化を避けるために EIP で固定する。
Spot × Hibernate は『中断耐性つき安価ジョブ』として割り切る — フル冗長な本番ではなく、CI、バッチ、検証環境で活かす。
Auto Scaling との競合に注意 — ASG 配下では Hibernation は使えない。スポットフリート・起動テンプレート・EC2 Image Builder と組み合わせる別パターンで設計する。
ログを CloudWatch で監視 — Stop - Hibernate の失敗イベントは見落とされがち。CloudTrail/CloudWatch でアラートを仕込んでおくと運用が安定する。

10. Stop vs Hibernate の使い分け早見表

シーン	推奨	理由
業務時間外に EC2 を止めてコストを下げたい	Stop	単純で安価。EBS 容量も RAM ぶん追加不要
開発者個人 PC 替わりの EC2、明日の続きをやりたい	Hibernate	エディタ・実行中プロセスをそのまま維持
Spot で動かしている長時間バッチ	Hibernate	中断時にチェックポイント不要
Auto Scaling 配下で需要に応じて増減	Stop / Terminate	Hibernate は ASG では使えない
大量データを RAM に読み込んだ ML 推論サーバ	Hibernate	読み込み時間を完全スキップ
ECS / EKS のクラスターメンバー	Stop / Terminate	Hibernate は不可

11. 関連用語

Amazon EC2 — Hibernation はインスタンスの停止アクションの一種
Amazon EBS — RAM ダンプの保存先（容量＋暗号化が要件）
EC2 AMI — 休止対応 AMI を選択する起点
EC2 Spot Instances — Spot Interruption の救命策として連携
EC2 Auto Scaling — Hibernation との非互換に注意
Elastic IP — 復帰後の IP 維持に必須
AWS KMS — ルート EBS 暗号化キーの管理元
EC2 Image Builder — Golden AMI 戦略との比較対象

12. 関連サイト

AWS 公式

参考記事

🎓 試験での出題傾向

試験	重要度	主な出題パターン
CLF	低	Stop と Terminate の違いを問う中で Hibernation の存在を確認する程度
SAA	中	Spot Interruption への対策、起動時間最小化アーキテクチャの選択肢
DVA	中	開発者向けに「状態保持つき停止」の概念と CLI／CFn 設定
SOA	高	制約（RAM 上限・暗号化必須・ASG 非対応・60 日制限）と運用設計

特に SOA / SAA では「長時間のウォームアップが必要なアプリを Spot で安く動かしたい」「ML 推論サーバの再起動時間を最小化したい」シナリオで、Hibernation・Auto Scaling・Spot・Golden AMI のどれを選ぶか問われる。「重い起動コストをスキップしたい → Hibernation／自動で増減させたい → Auto Scaling／OS イメージ自体を最適化したい → Image Builder」と覚えておくと判断がブレない。