起動テンプレートとAuto Scalingの関係、ちゃんと理解してる？

AWSでEC2を自動スケールさせようとしたとき、「起動テンプレート」と「Auto Scaling Group」って両方出てくるじゃないですか。最初のうちは「どっちに何を設定するんだっけ」ってなりがちで、なんとなく動くようにしてから深く理解しないまま来てしまってる人も多いんじゃないかなぁと思っています。自分もそうだったので。

改めて整理したら思ったよりシンプルだったので、まとめておきます。

役割分担はシンプル

一言で言うと、こうです。

起動テンプレート＝「どんなインスタンスを作るか」の設計図
Auto Scaling Group＝「何台作るか・いつ作るか」の管理

起動テンプレートに書くのは、AMI（どのOSイメージを使うか）、インスタンスタイプ、セキュリティグループ、IAMロール、起動時に実行するスクリプト（ユーザーデータ）、EBSの設定などです。つまり「EC2を1台立てるのに必要な情報」をまとめたもの。

ASGはその設計図を受け取って、最小・最大・希望台数の範囲でインスタンスを増減させます。設計図を渡してあげれば、あとはASGが負荷に応じて「もう1台追加」「1台落とす」を自動でやってくれる、という役割分担です。

バージョン管理が地味にありがたい

起動テンプレートが起動設定（旧方式）と大きく違う点のひとつが、バージョン管理ができることです。

例えばこんな状態を作れます。

起動テンプレート "my-app-template"
  ├── v1: t3.medium, 旧AMI
  ├── v2: t3.large, 旧AMI   ← Default
  └── v3: t3.large, 新AMI   ← Latest（確認中）

ASGに紐付けるとき、$Default $Latest か特定のバージョン番号を指定できます。新しいAMIを試したいときにv3を作って試せるし、問題があればすぐDefaultに戻せる。これがめっちゃ助かるんです。

旧方式の「起動設定」にはバージョン管理がなくて、変更するたびに別名で新しいものを作る必要があって正直つらかったです。今から作るなら絶対に起動テンプレートを使いましょう。

AMI更新するときの安全な手順

EC2のOSアップデートやミドルウェアのバージョンアップをするとき、新しいAMIで起動テンプレートを更新してASGに反映させるんですが、やり方を間違えると既存インスタンスが急に全部落ちたりして怖いです。

安全な手順はこうです。

1. 新AMIで起動テンプレートの新バージョンを作る
2. ASGのバージョン指定を新バージョンに変更
3. インスタンスリフレッシュで既存インスタンスを順番に入れ替える
4. 問題があれば旧バージョンに戻す

インスタンスリフレッシュは、「古いインスタンスを1台落として新しいインスタンスを起動、ヘルスチェックが通ったら次の1台」という手順を自動でやってくれます。一気に全部入れ替わらないので、デプロイ中もトラフィックが捌ける状態を保てます。

ローリングアップデートの割合も設定できるので、「一度に最大20%まで」とかに絞ることもできます。

スポットインスタンスと混在させるのも起動テンプレートがないとできない

コスト最適化の話で、スポットインスタンスをASGに混ぜる「混合インスタンスポリシー」という設定があります。「ベースはオンデマンド3台、それ以上はスポットで補う」みたいな構成ができて、コストをかなり下げられます。

これ、旧方式の起動設定では使えないんですよね。起動テンプレートを使うことが前提になっています。スポットはインスタンスが突然終了されるリスクがあるので全台に適用するのは怖いですが、「増加分だけスポット」という構成ならリスクを抑えながらコストを削れます。

起動テンプレートとASGの関係って最初は「なんで2つあるんだ」って思ってたんですが、設計図と管理を分けることで柔軟に運用できるようになってるんだなぁと今は思ってます。特にバージョン管理とインスタンスリフレッシュの組み合わせは、本番環境の運用がすごく楽になるのでぜひ試してみてください。

これはclaude codeで生成しました。

私は確かにーて思ってます。