【AWS】Auto Scaling の終了ポリシーについて調べてみたよ

# 🌸はじめに

Auto Scaling グループを運用する際に重要だけど、意外と理解されていないのが「終了ポリシー（Termination Policies）」かなと思います。
インスタンスを増やす（スケールアウト）する仕組みは直感的に分かりやすいものの、どのインスタンスをいつ終了させるか（スケールイン）するかの仕組みは少し複雑です。
このブログでは、AWS Auto Scaling の終了ポリシーについて解説します。

# 🤔終了ポリシーとは？

終了ポリシーとは、Auto Scaling グループがスケールイン（縮小）する際に、**どのインスタンスを終了するか**を決定するルールです。
例えば、負荷が減少したときに10台のサーバーを5台に減らす場合、どの5台を選んで終了させるかを決めるのが終了ポリシーの役割です。

# 💡AWS が提供する終了ポリシーの種類

AWS が提供する終了ポリシーを表にまとめました

| 終了ポリシー名 | 説明 | ユースケース |
|--------------|------|----------------|
| **Default** | AWS がほとんどのユースケースに最適となるよう設計した順番で終了してくれるポリシー | バランスの取れた一般的な使用ケース |
| **OldestInstance** | 最も長く稼働しているインスタンスから終了 | 定期的なインスタンスリフレッシュ、メモリリーク対策 |
| **NewestInstance** | 最も新しく起動したインスタンスから終了 | 安定した長時間稼働中のインスタンスの維持 |
| **OldestLaunchConfiguration** | 最も古い起動設定（Launch Configuration）を使用しているインスタンスから終了 | 新しい構成へのローリングアップデート、AMI更新 |
| **OldestLaunchTemplate** | 最も古い起動テンプレート（Launch Template）またはそのバージョンを使用しているインスタンスから終了 | 起動テンプレートバージョン間の移行 |
| **ClosestToNextInstanceHour** | 次の課金時間（billing hour）に最も近いインスタンスから終了 | コスト最適化 |
| **AllocationStrategy** | 配置戦略に基づいてインスタンスを終了 | スポットとオンデマンドの混合環境 |

# 👀 kwsk

それぞれのポリシーを詳しく見ていきましょう。

## デフォルトポリシー（Default）

### 特別な要件がない限り、このデフォルトポリシーがバランスの良い選択

何も指定しない場合、Auto Scaling グループは「Default」ポリシーを使用します。
このポリシーは「AWS が一般的なユースケースで最適となるよう設計した終了順序」と考えると良いでしょう。
1. **AZ間のバランスを維持**: 
まず、各リージョン内の地域（AZ）間でインスタンスを均等に保つため、インスタンス数が多い地域から選びます
2. **インスタンス数の調整**: 
同じ状況の地域が複数ある場合は、インスタンスが最も多い地域から選択します
3. **保護されていないものを選択**: 
明示的に保護設定がされていないインスタンスを選びます
4. **古い設定のものを選択**: 
最も古い起動設定や起動テンプレートを使っているインスタンスを選びます
5. **料金の無駄を減らす**: 
上記が同じなら、次の課金時間（billing hour）に近いインスタンスを選んで料金の無駄を減らします
:::note info
Q：課金時間（billing hour）に近いインスタンスってなんだ？
A：以下の2つのインスタンスがあるとき、①が該当します
①インスタンスAは既に55分分の課金が発生している（次の時間区切りまであと5分）
②インスタンスBはまだ5分しか課金されていない（次の時間区切りまであと55分）
:::

## 最も古いインスタンス（OldestInstance）

### 「サーバーの若返り」が定期的に必要なシステムに向いています

`OldestInstance` ポリシーは、文字通り「一番長く動いているインスタンスから順に終了させる」というシンプルな仕組みです。

**こんなときに使います：**
- 長時間動いているサーバーのメモリ不足や性能低下を防ぎたい
- 定期的に新しいサーバーに入れ替えたい
- 古い世代のハードウェア上で動いている可能性のあるインスタンスを減らしたい

## 最も新しいインスタンス（NewestInstance）

### 「安定性重視」の運用に適したポリシー

`NewestInstance` ポリシーは、「最後に起動したインスタンスから先に終了させる」という仕組みです。

**こんなときに使います：**
- 安定して長く動いているサーバーを優先的に残したい
- 一時的な負荷増加のために追加したインスタンスを、負荷減少時に最初に削除したい
- 新しく追加したインスタンスに問題があったとき、それらを優先的に取り除きたい

## 最も古い起動設定（OldestLaunchConfiguration）

### 古い起動設定から起動したインスタンスから優先的に削除したい場合
:::note info
Q: 起動設定とは
A: インスタンスの起動時に利用する「レシピ」のようなもの
:::
`OldestLaunchConfiguration` ポリシーは、「最も古い起動設定（Launch Configuration）を使っているインスタンスから順に終了させる」仕組みです。

**こんなときに使います：**
- 新しいバージョンのアプリや設定に順番に更新していきたい
- 古い設定のサーバーを徐々に新しいものに置き換えたい
- 新しいAMI（サーバーイメージ）への移行をスムーズに行いたい

## 最も古い起動テンプレート（OldestLaunchTemplate）
:::note info
Q: 起動テンプレートとは
A: 起動設定の新しい版の呼び方。起動テンプレートは起動設定より多くの機能を持ってる。
:::
### 古い起動設定から起動したインスタンスから優先的に削除したい場合（起動テンプレート Ver.）
`OldestLaunchTemplate` ポリシーは、「最も古いバージョンの起動テンプレート（Launch Template）を使っているインスタンスから終了させる」仕組みです。

**こんなときに使います：**
- 起動テンプレートを使っている環境で、古いバージョンから新しいバージョンに移行したい
- テンプレートのバージョン管理機能を使ってアプリケーションを更新している

## 次の課金時間に最も近い（ClosestToNextInstanceHour）

### これはコスト節約の検討時にぜひ。

`ClosestToNextInstanceHour` ポリシーは、「次の課金時間（billing hour）に最も近いインスタンスから終了させる」仕組みです。

**こんなときに使います：**
- EC2インスタンスの料金を最大限節約したい
- すでに使った分の料金を無駄にしたくない

例えば、60分の課金サイクルで55分経過したインスタンスよりも、5分しか経っていないインスタンスを先に終了させます。
これにより、すでに支払った時間を最大限活用できます。

## 配置戦略（AllocationStrategy）

### 複数タイプのインスタンスを使い分けている場合に便利

`AllocationStrategy` ポリシーは、「配置戦略に基づいてインスタンスを終了させる」仕組みです。
スポットインスタンス（通常より安い料金の一時的なインスタンス）とオンデマンドインスタンス（通常料金のインスタンス）を混ぜて使っている環境で役立ちます。

**こんなときに使います：**
- スポットインスタンスとオンデマンドインスタンスを併用している

## 番外編1️⃣：キャパシティの再調整（CapacityRebalance）

### スポットインスタンスを使ってるときに便利

これは終了ポリシーではなく補完機能ですが、安定性が重要なスポットインスタンス環境では検討する価値があります。

この機能を有効にすると：
- スポットインスタンスが終了しそうになった時、事前に新しいインスタンスを準備します
- システムの可用性を高め、スポットインスタンスの突然の終了による影響を減らします

## 番外編2️⃣：複数の終了ポリシーの組み合わせる

AWS では、複数の終了ポリシーを順番に適用することもできます。
例えば👇みたいなかんじ。

```bash
aws autoscaling update-auto-scaling-group \
    --auto-scaling-group-name my-asg \
    --termination-policies "OldestLaunchConfiguration" "ClosestToNextInstanceHour"
```
この場合、まず「古い起動設定を使っているインスタンス」を選び、もし同じ起動設定を使っている複数のインスタンスがあれば、「次の課金時間に近いインスタンス」を選んで終了させます。

# 👩‍🏫活用例

## 例）ウェブアプリケーションを安全に更新するための手順
以下の方法は、ブルー/グリーンデプロイメントと呼ばれる手法に似ています。
新旧のサーバーが一時的に共存するため、問題があればすぐに元の状態に戻せます。
1. **新しいAMIを作成**: 
最新のアプリやソフトウェアを含む新しいサーバーイメージを作る
2. **起動設定を更新**: 
新しいAMIを使うように設定を変更する
3. **OldestLaunchConfiguration終了ポリシーを設定**: 
古い設定のサーバーから順に終了させるようにする
4. **グループサイズを一時的に増やす**: 
例えば5台なら10台に増やす（2倍に）
5. **新しいサーバーの確認**: 
新しいサーバーが正常に動いているか確認する
6. **古いサーバーの段階的な終了**: 
グループサイズを元に戻す（5台に）と、終了ポリシーにより古いサーバーから順に終了する

# 🎈まとめ

AWS Auto Scaling の終了ポリシーは、クラウドシステムの管理において重要な役割を果たします。
適切な終了ポリシーを選ぶことで、アプリケーションの安定性を保ちながら、コスト効率の良い運用を目指しましょう！！