先に要点
- Termination Protection は、EC2 インスタンスを誤って終了しにくくするための基本設定です。
- AWS では
DisableApiTermination属性で表され、コンソール、CLI、API からの terminate 操作に対して効きます。 - ただし、すべての終了経路を防げるわけではありません。OS 側の終了動作設定、AWS の予定イベント、Auto Scaling 配下の挙動は別で考える必要があります。
- なので、Termination Protection は大事ですが、EBS 設計、スナップショット、AMI、バックアップの代わりにはなりません。
AWS を使い始めると、この EC2 はうっかり消せないようにしておきたい という場面がすぐ出てきます。
そのとき真っ先に出てくるのが Termination Protection です。
名前からすると 終了を完全に防げる設定 に見えますが、実際には少し範囲があります。
便利なのは確かですが、何を防げて何を防げないのかを混ぜると、保護していたのに終わった という誤解につながります。
今回は、Termination Protection を EC2 の誤終了を防ぐ基本設定 として整理しつつ、Stop Protection との違い、Auto Scaling 配下での注意点、設定しても安心しきれない理由まで整理します。
Termination Protectionとは何か
Termination Protection は、EC2 インスタンスに対して誤った terminate 操作をしにくくする設定です。
AWS の公式ドキュメントでは、DisableApiTermination 属性を有効にすることで、EC2 API を直接呼ぶ場合だけでなく、EC2 コンソールなど別インターフェース経由の終了操作も防ぐと説明されています。
つまり、まずの理解としてはこうです。
対象
1台の EC2 インスタンス
インスタンスごとに設定します。
目的
誤終了を防ぐ
手動や API 経由の誤終了を防ぎます。
正体
属性の値
DisableApiTermination = true
本番機や重要サーバーでは、かなり基本の安全策です。
何を防げるのか
Termination Protection が特に効くのは、日常的な誤操作です。
たとえば次のようなケースです。
- コンソールで stop のつもりが terminate を押す
- CLI で対象インスタンスを取り違える
- 自動化スクリプトが誤って terminate を投げる
この種の事故は、分かっている人でも普通に起きる のがやっかいです。
だからこそ、Termination Protection は 高度な設計 というより、まず入れておくべきガードレールとして価値があります。
何を防げないのか
ここが一番大事です。
AWS の公式ドキュメントでも、Termination Protection は万能ではないと明記されています。
特に押さえたいのは次の3つです。なお、スポットインスタンスには、そもそも Termination Protection を設定できません。
1. インスタンス内からの終了動作
ドキュメントでは、インスタンス内からの OS シャットダウンで InstanceInitiatedShutdownBehavior=terminate になっている場合、Termination Protection では防げないと説明されています。
つまり、外からの terminate を止める設定であって、OS 内部からの終了動作までは別物です。
2. AWS 側の予定終了イベント
AWS のメンテナンスや基盤都合で発生する terminate イベントまでは防げません。
この意味でも、Termination Protection は 人間の誤操作防止 には強いですが、インフラ側の全終了パターンを止める盾 ではありません。
3. Auto Scaling 配下の終了
Auto Scaling グループの配下にあるインスタンスは、スケールインや、異常と判定されたときの置き換えで終了されることがあります。AWS の公式ドキュメントでも、Termination Protection ではこれらの終了を防げないと明記されています。
この場合は、Termination Protection だけで ずっと残す という考え方が合わないことがあります。
Auto Scaling の文脈では、終了を防ぎたいなら別途 instance scale-in protection やグループ側の設計を見た方が自然です。異常なインスタンスの置き換えを一時的に止めたいときは、ReplaceUnhealthy プロセスを一時停止する方法も公式に案内されています。
Stop Protectionとは何が違うのか
最近は Stop Protection もあるので、ここも混ざりやすいです。
Stop Protection は、その名の通り 誤停止 を防ぐための設定です。
AWS の stop protection ドキュメントでは、DisableApiStop で stop 操作を保護できると整理されています。
このドキュメントによると、Stop Protection を有効にすると、コンソール・CLI・API からの誤った terminate も防げます。ただし DisableApiTermination が自動でオンになるわけではなく、Stop Protection をオフにしたときは、Termination Protection の設定で terminate できるかどうかが決まります。また、インスタンスストアがルートボリュームのインスタンスと、スポットインスタンスには Stop Protection を設定できません。
違いをざっくり表にするとこうです。
| 設定 | 主に防ぐもの | 主な属性 |
|---|---|---|
| Termination Protection | terminate | DisableApiTermination |
| Stop Protection | stop（コンソール・CLI・API からの terminate も防ぐ） | DisableApiStop |
つまり、消されたくない と 止められたくない は別です。どちらも重要なサーバーなら、両方考えた方が自然です。
Auto Scaling 配下では何に注意するか
Auto Scaling を使っているときに 重要だから Termination Protection を入れておこう と考えると、少し噛み合わないことがあります。
なぜかというと、Auto Scaling は必要に応じてインスタンスを終了・置き換える仕組みだからです。
スケールインや古い構成の置き換えを止めすぎると、グループ全体の運用意図とぶつかることがあります。
AWS の Auto Scaling ドキュメントを見ると、どのインスタンスを優先的に終了するかは termination policy や scale-in protection の考え方で整理されています。
なので、Auto Scaling 管理下では次の2つを分けて考える方が大事です。
1台を守る
その1台を絶対消したくないのか
特定のインスタンスを残したい、という目的です。
グループを守る
グループ全体として安定稼働したいのか
グループ全体の安定稼働を優先したい、という目的です。
Termination Protection を有効にしても安心しきれない理由
ここは少し厳しめに言うと、設定して終わりだと思うと危ないです。
Termination Protection は役立ちます。
でも、事故時に本当に効くのは次のような別の層です。
たとえば、誤終了そのものは防げても、別経路の終了や障害でインスタンスを失うことはあります。
そのとき、バックアップもなく、データが全部インスタンス内だけだと結局つらいです。
だから、Termination Protection は 最初の防波堤 ではあっても、最後の安全装置 ではありません。
どんなインスタンスなら特に入れておきたいか
実務で優先度が高いのは、たとえば次のようなものです。
優先度が高い
1. 本番の単一インスタンス
運用が止まる
2. 踏み台や管理サーバー
台数は少なくても、消えると運用が止まりやすいサーバーです。こういうものは誤停止・誤終了ともに防ぎたいことがあります。
誤操作の影響が大きい
3. 手作業が多い環境
IaC や完全自動化がまだ整っていない環境ほど、1回の誤操作ダメージが大きくなります。そういう環境では、まず手動事故を減らすだけでも価値があります。
どう設定すべきかの考え方
考え方としては、かなりシンプルです。次の4つを順に確認します。
この4つを見ると、とりあえず入れるべきか と 他の対策も同時に必要か が整理しやすいです。
特に、直近の AWSでEC2を停止ではなく終了してしまったときはどうする？まず確認すべきこと とつなげて見ると、設定する理由がかなり腹落ちしやすいはずです。
Termination Protectionのよくある質問
Q. Termination Protection と Stop Protection の違いは？
A. Termination Protection は terminate(完全削除) を防ぐ、Stop Protection は stop(一時停止) を防ぐ。Stop Protection を有効にすると、コンソール・CLI・API からの terminate も防げますが、DisableApiTermination は自動では有効になりません。消されたくないサーバーは Termination Protection も明示的に有効にしておくと、Stop Protection を外したときにも守りが残ります。
Q. 設定方法は？
A. EC2 Console → インスタンス選択 → Actions → Instance settings → Change termination protection → Enable。CLI なら aws ec2 modify-instance-attribute --instance-id i-xxx --disable-api-termination で有効、--no-disable-api-termination で無効になります。起動時に「高度な詳細」で有効にしておくこともできます。
Q. 全インスタンスに有効化すべき？
A. 本番、ステージング、重要システムは推奨。テスト・検証・短期インスタンスは無効化でも OK。重要度別に有効化方針を決める のが現実的。
Q. Auto Scaling では効きますか？
A. Auto Scaling Group が Scale-in 操作で terminate する場合、Termination Protection の影響は限定的。Instance Scale-In Protection を別途設定する必要があります。
Q. CloudFormation で削除を防ぐには？
A. DeletionPolicy: Retain を CloudFormation テンプレートに記載。スタック削除時もリソースを保持。UpdateReplacePolicy: Retain も併用すると、置き換え時も保持。
Q. IAM 権限で terminate を制限する方法は？
A. IAM ポリシーで ec2:TerminateInstances を Deny、または特定 IAM ユーザーのみ Allow。管理者のみ terminate 可能、開発者は stop/start のみ のような制御で安全運用。
Q. SNS 通知で terminate を検知できる？
A. CloudWatch Events / EventBridge で EC2 Instance State-change Notification をトリガーに SNS 通知。インスタンスの状態の変化はすぐに分かります。誰が 実行したかは、CloudTrail に記録される TerminateInstances のイベントで確認します。
まとめ
Termination Protection は、EC2 の誤終了を防ぐための基本設定です。
stop のつもりで terminate した のような事故を減らすには、かなり素直に効きます。
ただし、覚えておきたいのはこの3点です。
つまり、Termination Protection は 入れるべき ですが、これだけで安心 ではありません。
EBS、AMI、スナップショット、Stop Protection、Auto Scaling の設計まで合わせて初めて、終わって困るサーバーを守りやすくなります。
このとき混ざりやすい AMI と スナップショット の役割差は、AMIとスナップショットはどう違うのか で整理しています。どちらも保存っぽく見えますが、起動テンプレートとディスクの時点コピーでは使いどころが違います。
関連で読むなら、誤終了後の復旧判断は AWSでEC2を停止ではなく終了してしまったときはどうする？まず確認すべきこと、ディスクの考え方は EBSとは？EC2のディスクをどう考えるべきか、Auto Scaling 配下の文脈は Auto Scalingとは？EC2の台数を自動で増減する基本 がつながります。
参考情報
- AWS EC2 User Guide: Change instance termination protection
- AWS EC2 User Guide: Enable stop protection for your EC2 instances
- AWS EC2 Auto Scaling User Guide: Control which Auto Scaling instances terminate during scale in
- AWS EC2 Auto Scaling User Guide: Configure termination policies for Amazon EC2 Auto Scaling