先に要点
- 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 コンソールなど別インターフェース経由の終了操作も防ぐと説明されています。
つまり、まずの理解としてはこうです。
本番機や重要サーバーでは、かなり基本の安全策です。
何を防げるのか
Termination Protection が特に効くのは、日常的な誤操作です。
たとえば次のようなケースです。
- コンソールで stop のつもりが terminate を押す
- CLI で対象インスタンスを取り違える
- 自動化スクリプトが誤って terminate を投げる
この種の事故は、分かっている人でも普通に起きる のがやっかいです。
だからこそ、Termination Protection は 高度な設計 というより、まず入れておくべきガードレールとして価値があります。
何を防げないのか
ここが一番大事です。
AWS の公式ドキュメントでも、Termination Protection は万能ではないと明記されています。
特に押さえたいのは次の3つです。
1. インスタンス内からの終了動作
ドキュメントでは、インスタンス内からの OS シャットダウンで InstanceInitiatedShutdownBehavior=terminate になっている場合、Termination Protection では防げないと説明されています。
つまり、外からの terminate を止める設定であって、OS 内部からの終了動作までは別物です。
2. AWS 側の予定終了イベント
AWS のメンテナンスや基盤都合で発生する terminate イベントまでは防げません。
この意味でも、Termination Protection は 人間の誤操作防止 には強いですが、インフラ側の全終了パターンを止める盾 ではありません。
3. Auto Scaling 配下の終了
Auto Scaling グループの配下にあるインスタンスは、スケールインや置き換えで終了されることがあります。
この場合は、Termination Protection だけで ずっと残す という考え方が合わないことがあります。
Auto Scaling の文脈では、終了を防ぎたいなら別途 instance scale-in protection やグループ側の設計を見た方が自然です。
Stop Protectionとは何が違うのか
最近は Stop Protection もあるので、ここも混ざりやすいです。
Stop Protection は、その名の通り 誤停止 を防ぐための設定です。
AWS の stop protection ドキュメントでは、DisableApiStop で stop 操作を保護できると整理されています。
違いをざっくり表にするとこうです。
| 設定 | 主に防ぐもの | 主な属性 |
|---|---|---|
| Termination Protection | terminate | DisableApiTermination |
| Stop Protection | stop | DisableApiStop |
つまり、消されたくない と 止められたくない は別です。
どちらも重要なサーバーなら、両方考えた方が自然です。
Auto Scaling 配下では何に注意するか
Auto Scaling を使っているときに 重要だから Termination Protection を入れておこう と考えると、少し噛み合わないことがあります。
なぜかというと、Auto Scaling は必要に応じてインスタンスを終了・置き換える仕組みだからです。
スケールインや古い構成の置き換えを止めすぎると、グループ全体の運用意図とぶつかることがあります。
AWS の Auto Scaling ドキュメントを見ると、どのインスタンスを優先的に終了するかは termination policy や scale-in protection の考え方で整理されています。
なので、Auto Scaling 管理下では
- その1台を絶対消したくないのか
- グループ全体として安定稼働したいのか
を分けて考える方が大事です。
Termination Protection を有効にしても安心しきれない理由
ここは少し厳しめに言うと、設定して終わりだと思うと危ないです。
Termination Protection は役立ちます。
でも、事故時に本当に効くのは次のような別の層です。
たとえば、誤終了そのものは防げても、別経路の終了や障害でインスタンスを失うことはあります。
そのとき、バックアップもなく、データが全部インスタンス内だけだと結局つらいです。
だから、Termination Protection は 最初の防波堤 ではあっても、最後の安全装置 ではありません。
どんなインスタンスなら特に入れておきたいか
実務で優先度が高いのは、たとえば次のようなものです。
1. 本番の単一インスタンス
まだ冗長化していない単一 EC2 なら、1台消えるだけで影響が大きいです。
この場合はかなり優先度が高いです。
2. 踏み台や管理サーバー
台数は少なくても、消えると運用が止まりやすいサーバーです。
こういうものは誤停止・誤終了ともに防ぎたいことがあります。
3. 手作業が多い環境
IaC や完全自動化がまだ整っていない環境ほど、1回の誤操作ダメージが大きくなります。
そういう環境では、まず手動事故を減らすだけでも価値があります。
どう設定すべきかの考え方
考え方としては、かなりシンプルです。
この4つを見ると、とりあえず入れるべきか と 他の対策も同時に必要か が整理しやすいです。
特に、直近の AWSでEC2を停止ではなく終了してしまったときはどうする？まず確認すべきこと とつなげて見ると、設定する理由がかなり腹落ちしやすいはずです。
まとめ
Termination Protection は、EC2 の誤終了を防ぐための基本設定です。
stop のつもりで terminate した のような事故を減らすには、かなり素直に効きます。
ただし、覚えておきたいのはこの3点です。
つまり、Termination Protection は 入れるべき ですが、これだけで安心 ではありません。
EBS、AMI、スナップショット、Stop Protection、Auto Scaling の設計まで合わせて初めて、終わって困るサーバーを守りやすくなります。
関連で読むなら、誤終了後の復旧判断は 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