EC2インスタンスのライフサイクルと状態管理

インスタンスの状態遷移

EC2インスタンスは、起動から終了まで以下の状態を遷移します。

状態	説明	EC2課金
pending	起動準備中。AMIからインスタンスを作成している段階	なし
running	実行中。インスタンスが使用可能な状態	あり
stopping	停止処理中	なし（ハイバネーション準備中は課金あり）
stopped	停止済み。インスタンスは存在するが実行されていない	なし
shutting-down	終了処理中（削除準備中）	なし
terminated	完全に削除済み。復元できない	なし

重要: インスタンスが停止中（stopped）でも、アタッチされたEBSボリュームには引き続き課金が発生します。完全にコストを抑えたい場合は、インスタンスを終了（terminate）する必要がありますが、デフォルトではルートボリュームのEBSも削除されるため注意が必要です。

---

停止（Stop）と終了（Terminate）の違い

停止（Stop）

• インスタンスの実行を一時的に停止する
• EBSボリュームのデータは保持される
• 再開（Start）すると新しいホストに配置される可能性がある
• パブリックIPアドレスは解放される（Elastic IPは保持）
• プライベートIPアドレスは維持される

終了（Terminate）

• インスタンスを完全に削除する
• デフォルトでルートボリュームに設定されたEBSも削除される
• 一度終了したインスタンスは復元できない
• DeleteOnTermination属性を無効にすることで、インスタンス終了時にEBSボリュームを保持可能

終了保護

誤ってインスタンスを終了してしまうことを防ぐため、「終了保護」を有効にできます。有効にすると、APIやコンソールからの終了操作がブロックされます。

---

ハイバネーション（休止）

ハイバネーションを使うと、インスタンス停止時にメインメモリ（RAM）の内容をルートEBSボリュームに退避し、次回起動時にメモリを復元して停止前と同じ状態で再開できます。

メリット

• 起動時間を大幅に短縮できる（OSやアプリケーションの初期化が不要）
• メモリ上のセッション情報やキャッシュが維持される

利用条件

• ルートボリュームがEBSで、暗号化されている必要がある
• ルートボリュームの容量がRAMサイズ以上であること
• インスタンスの詳細設定で「停止-休止動作」を有効にする必要がある
• 対応するインスタンスタイプに限りがある（M系、C系、R系など多くのタイプで利用可能）

---

インスタンスの再起動

再起動（Reboot）は、停止→起動とは異なる操作です。

• 再起動ではインスタンスは同じホスト上に留まる
• パブリックIPアドレスやプライベートIPアドレスは変更されない
• インスタンスストア上のデータは保持される（停止の場合は消失する）

---

リカバリとベストプラクティス

EC2インスタンスの障害に備え、以下の対策を実施することが推奨されます。

自動復旧

• CloudWatchアラームを設定し、システムステータスチェックの失敗時にインスタンスを自動復旧できる
• 復旧後のインスタンスはIPアドレスやインスタンスID、メタデータが元のインスタンスと同一

バックアップ戦略

• AMIやEBSスナップショットを定期的に取得する
• DLM（Data Lifecycle Manager）を利用してスナップショットの取得をスケジューリングする
• 定期的にリカバリプロセスをテストする

高可用性の確保

• 重要なアプリケーションは複数のAZにデプロイする
• Auto Scalingグループを利用してインスタンスの自動置換を行う
• Elastic IPやENIの付け替えでフェイルオーバーを実現する

---

起動に失敗するケース

stopped状態からの起動が失敗する主な原因には以下があります。

• EBSボリューム数の制限を超過している
• EBSスナップショットが破損している
• 暗号化されたスナップショットの復号に必要なKMSキーへのアクセス権がない
• インスタンスストア型AMIに必要なパーツが欠損している

---

参考リンク

• AWS公式 インスタンスのライフサイクル
• AWS公式 ハイバネーション