先に要点
AWS を使い始めたころにやりがちなのが、stop のつもりで terminate してしまった という事故です。
見た目の操作は近いのに、意味はかなり違います。
まず安心材料から言うと、何もかも終わり とは限りません。
ただし、terminated になった EC2 インスタンスをそのまま起動し直す ことはできません。
復旧できるかどうかは、EBS ボリュームや AMI、スナップショット が残っているかで決まります。
今回は、AWS で EC2 を停止ではなく終了してしまったときに、何が戻せて何が戻せないのか、どこから確認するのが現実的かを整理します。
まず確認したいのは、本当に「終了」なのか
最初にやるべきことは、インスタンスの状態確認です。
AWS の EC2 ライフサイクル説明でも、stopped と terminated はまったく別の状態として整理されています。
stopped なら再度 start できますが、terminated はそれで終わりです。
つまり、最初の分岐はこうです。
stopped だった場合
- そのまま起動を試せる
- ルートボリュームも通常は残っている
- 設定やデータもそのまま戻ることが多い
terminated だった場合
- そのインスタンス ID のまま再起動はできない
- 何が残っているかを別に確認する必要がある
ここを混ぜると、起動ボタンが出ない なんで戻らないのか と混乱しやすいです。
終了したインスタンス本体は戻らない
ここははっきり押さえた方がよいです。
AWS の CloudWatch アラームアクションの説明でも、terminated instance cannot restart と明記されています。
つまり、一度 terminated になったインスタンス自体は、あとから start できません。
なので、復旧の考え方は 同じインスタンスを戻す ではなく、
- データが残っていれば新しく作る
- 設定が残っていれば作り直す
- 何も残っていなければバックアップから戻す
に切り替える必要があります。
一番大事なのは EBS が残っているかどうか
復旧できるかどうかで最重要なのは、EBS ボリュームの扱いです。
AWS の公式ドキュメントでは、インスタンス終了時に EBS ボリュームが消えるか残るかは、各ボリュームの DeleteOnTermination 属性で決まると説明されています。
ここで分けて考える必要があります。
ルートボリューム
OS やアプリ本体が入っていることが多いルートボリュームは、デフォルトで DeleteOnTermination = true になっていることがあります。
この場合、インスタンス終了と同時に消えます。
つまり、終了したけどルートボリュームは当然残っているはず と考えるのは危険です。
データボリューム
別でアタッチしていたデータ用 EBS は、DeleteOnTermination = false にしていれば残ることがあります。
この場合、新しい EC2 に付け直してデータを救える可能性があります。
何が残るかをどう判断するか
terminated になったあとに、まず見るべきなのはこの3つです。
AWS の Preserve data when an instance is terminated のドキュメントでも、終了時にボリュームが削除されるか保持されるかを Delete on termination 列で確認する流れが案内されています。
つまり、EC2 コンソールで見る順番としては、
- Instances
- Storage タブ
- どのボリュームがぶら下がっていたか
- Volumes 側にその ID がまだ残っているか
の順が自然です。
ルートボリュームが消えていたらどうするか
ルートボリュームが消えていた場合、そのインスタンスの OS ディスクはそのままでは戻りません。
ただし、次のどれかがあればまだ救えることがあります。
1. AMI がある
AMI があれば、その時点の構成をもとに新しい EC2 を起動し直せます。
アプリや設定が AMI に含まれていれば、かなり助かります。
2. スナップショットがある
スナップショット があれば、新しい EBS を作って別のインスタンスに付ける道があります。
完全に元通りとは限りませんが、データ救出や手動復元の足掛かりになります。
3. 構成管理やデプロイ手順がある
サーバー設定を手作業でしか持っていないと復旧が重くなります。
逆に、セットアップ手順、IaC、デプロイスクリプトがあれば、インスタンス自体は作り直しやすいです。
追加 EBS が残っていたらどうするか
追加データボリュームが残っていたら、かなり状況はよくなります。
この場合の考え方はシンプルです。
たとえば、アプリ本体は作り直しても、アップロードファイルや一部データが EBS 側に残っていれば、被害をかなり減らせます。
Auto Scaling 配下だった場合は見え方が変わる
ここは少し注意です。
もしその EC2 が Auto Scaling Group 配下だった場合、終了後に 似た新しいインスタンス が自動で起動することがあります。
このとき、見た目としては 戻ったように見える ことがありますが、同じインスタンスではありません。
つまり、
- 元の terminated インスタンスは戻っていない
- Auto Scaling が新しい個体を作っているだけ
です。
この場合は、新しいインスタンスが起きているか と 必要なデータが外部化されていたか を見る方が大事です。
そもそも復旧できないものもある
AWS の termination 動作説明では、終了時に RAM の内容や instance store のデータは失われると整理されています。
ここは復旧前提で考えない方が安全です。
特に注意したいのは次のものです。
- RAM 上だけにあった処理中データ
- instance store に置いていた一時ファイル
DeleteOnTermination = trueで消えたルートボリューム
つまり、EC2 にしか置いていなかったもの は、terminated 事故にかなり弱いです。
再発防止でやるべきこと
ここは記事としてかなり大事です。
復旧だけで終わらせると、また同じ事故が起きます。
1. Termination Protection を有効にする
AWS では DisableApiTermination、つまり termination protection を使えます。
これを有効にしておくと、誤操作による terminate を防ぎやすくなります。
2. Stop Protection も検討する
最近は stop protection もあります。
AWS の stop protection ドキュメントでは、誤停止だけでなく、条件次第で terminate 操作の防止にも関わることが整理されています。
3. ルートボリュームの DeleteOnTermination を確認する
本当に残したいルートボリュームなら、終了時に削除されない設定を事前に確認しておくべきです。
AWS 公式でも、root volume を終了後も保持する設定方法が案内されています。
4. AMI とスナップショットを定期的に取る
事故が起きてから 何も残っていなかった がいちばんつらいです。
少なくとも、復旧に必要な時点のスナップショットや AMI を取る習慣があると、被害がかなり変わります。
5. データを EC2 の中だけに閉じ込めない
アップロードファイル、DB、重要データをインスタンス内部だけに置く構成は危険です。
EBS、S3、RDS、EFS など、インスタンスの寿命と切り離せる場所へ逃がしておく方が安全です。
まとめ
AWS で EC2 を停止ではなく終了してしまったときは、まず stopped なのか terminated なのかを分けて確認することが大事です。
結論を短くまとめると、こうです。
- terminated になったインスタンス本体はそのまま起動し直せない
- 復旧できるかは EBS、AMI、スナップショットが残っているか次第
- ルートボリュームは
DeleteOnTerminationによって消えていることがある - 再発防止には termination protection とバックアップが重要
慌てて どうにか元のインスタンスを起動する より、何が残っているかを冷静に確認して、新しく作り直す 方向で考える方が現実的です。
関連で読むなら、EC2 の基本は EC2とは？AWSの仮想サーバーを初心者向けに整理、EBS の扱いは EBSとは？EC2のディスクをどう考えるべきか、AMI の考え方は AMIとは？EC2起動テンプレートの意味 がつながります。
参考情報
- AWS EC2 User Guide: How instance termination works
- AWS EC2 User Guide: Preserve data when an instance is terminated
- AWS EC2 User Guide: Keep an Amazon EBS root volume after an Amazon EC2 instance terminates
- AWS EC2 User Guide: Enable stop protection for your EC2 instances
- AWS EC2 User Guide: Amazon EC2 instance state changes
- Amazon CloudWatch Docs: Stop, terminate, reboot, or recover an EC2 instance