【AWS】AutoScalingで使用する起動テンプレートを更新したい

コストを最優先し、手動での介入を許容する範囲での障害復旧手順をいろいろ考えてみました。

前提

・AMIは７世代分くらいを毎日取得している
・起動テンプレは作成済み
・シングルAZ構成でパブリックサブネットにALB + EC2構成

「障害インスタンス発生 → メール通知 → 手動で、起動テンプレートのAMIを最新のものに設定 → Auto Scalingの希望容量と最小容量を1に設定」

という手順は、Auto Scaling Group (ASG) の本来の自動復旧能力を最大限に活用できておらず、手動作業が多く、迅速な復旧という観点からは最適ではありません。

コストを抑えつつ、EC2インスタンス単体障害からの自動復旧を目指すのであれば、

「常に最新のAMIを使用するように起動テンプレートを設定し、ASGの最小容量/希望容量を1にしておく」

ことが、追加コストを発生させずに自動復旧を実現する、最も良い方法です。

ASGの基本的な機能として、ヘルスチェックに失敗したインスタンスを自動的に置き換える機能があります。この機能は、追加料金なしで利用できます。

この手順だと、以下の点が課題となります。

- ASGは、起動テンプレートで指定されたAMIを使ってインスタンスを起動します。
- もし、起動テンプレートのAMIが常に最新になっていないと、障害時に古いAMIからインスタンスが起動されてしまい、最新のデータや設定が反映されません。
- 毎日AMIを取得しているのに、それを手動で起動テンプレートに反映させる作業は、手間がかかるだけでなく、緊急時にAMIの指定ミスをするリスクもあります。
- ASGの「インスタンスの置き換え」機能自体は、現在の起動テンプレートの設定に基づいて自動で行われます。障害時に手動で起動テンプレートを更新してからASGの設定を変更するのは、手間も時間もかかり、復旧が遅れます。

- これはASGの基本的な設定として、常に「1」にしておくべきです。
- ASGがインスタンスの障害を検知すると、自動的にそのインスタンスを終了し、新しいインスタンスを「希望容量 (Desired Capacity)」を満たすように起動しようとします。 もし希望容量が1であれば、障害インスタンスを終了後、新しいインスタンスを1台起動します。
- この挙動は、希望容量や最小容量を「0」から「1」に変更するような手動操作を必要としません。

ASGが提供する無料の自動復旧機能を最大限に活用し、かつコストを抑えるためには、以下の手順が最も良いです。

DLM (Data Lifecycle Manager) でAMIの自動取得と世代管理を設定する:
- これにより、毎日自動でAMIが取得され、古いAMIは自動で削除されます。ここには手動介入は不要です。
Auto Scaling Group (ASG) を適切に設定する:
- 起動テンプレート (Launch Template) を作成し、常に最新のAMI IDを参照するようにする（ここが少し工夫が必要な部分です。後述します）。
- ASGの最小容量 (Min capacity) を 1 に設定します。
- ASGの希望容量 (Desired capacity) を 1 に設定します。
- ASGの最大容量 (Max capacity) を 1 以上（例えば 1 または 2）に設定します。（1 にすると、常に1台しか存在しません。スケールアウトはしません。）
- ALBのターゲットグループと連携させ、ALBのヘルスチェックを使用するようにASGを設定します。
- これにより、インスタンスが障害を起こしたり、ALBのヘルスチェックに失敗したりした場合、ASGが自動的にそのインスタンスを終了し、起動テンプレートに指定されたAMIから新しいインスタンスを「自動で」起動し直します。

これが「手間なく自動復旧」を実現する上で最も重要な点です。

- DLMで新しいAMIが作成されるたびに、手動で起動テンプレートの新しいバージョンを作成し、そこに最新のAMI IDを指定します。
- ASGは、デフォルトで起動テンプレートの最新バージョンを使用するように設定できます（または特定のバージョンを指定することも可能）。
- コストはかかりませんが、毎日手動で更新する手間が発生します。

コストを抑えつつ単一インスタンスの障害復旧を自動化するならば、

これが、追加のインフラコストなしに、EC2インスタンスの単体障害からの自動復旧を実現するベストなアプローチです。手動でのAMI更新は手間とリスクを伴うため、可能であればLambdaによる自動更新を検討するのが良いです。