先に要点
- Auto Scalingは、EC2の台数を自動で増減しつつ、不健全なインスタンスを置き換えて、必要な台数を維持する仕組みです。
- AWSでは Auto Scaling Group を使って、どんなEC2を何台維持するかをまとめて管理します。
- Launch Template で起動設定をまとめ、最小・希望・最大台数を決め、CloudWatch メトリクスで増減させます。
- ヘルスチェックで壊れた台を置き換えるので、可用性を上げるための基盤でもあります。
先に結論
Auto Scaling は、負荷に応じて EC2 の台数を自動で増減したり、壊れたインスタンスを置き換えたりする仕組みです。
AWSでは、通常 Amazon EC2 Auto Scaling を使って、Auto Scaling Group という単位でEC2群を管理します。
ざっくり言うと、次のような運用を手でやらずに回すための仕組みです。
- 普段は2台でよい
- アクセスが増えたら4台に増やしたい
- 深夜は2台に戻したい
- 1台壊れたら自動で補充したい
この記事は、2026年4月23日時点で AWS 公式の
What is Amazon EC2 Auto Scaling?Dynamic scaling for Amazon EC2 Auto ScalingTarget tracking scaling policiesHealth checks for instances in an Auto Scaling groupCreate Auto Scaling groups using launch templatesをもとに整理しています。ヘルスチェックの種類と起動設定の扱いは、2026年10月に公式ドキュメントで再確認しました。
Auto Scalingとは何か
AWS公式では、Amazon EC2 Auto Scaling は アプリの負荷を処理するのに適切な数の EC2 インスタンスを維持する サービスとして説明されています。
この説明の中には、実は2つの役割が入っています。
役割 1：台数調整
1. 台数を増減する
アクセスや負荷に応じて、EC2を増やしたり減らしたりします。これが一般にイメージされやすい Auto Scaling です。
役割 2：自己修復
2. 壊れたインスタンスを置き換える
Auto Scaling は、単に増減するだけではなく、グループ内のインスタンスが不健全になったら新しいものへ置き換える役割も持ちます。
つまり、「台数調整」と「自己修復」の両方を担う、と理解するとかなり分かりやすいです。
まず押さえたい用語
Auto Scaling を読むと、似た言葉が続くので最初に整理しておくと楽です。
| 用語 | 意味 |
|---|---|
| Auto Scaling Group | EC2群をまとめて管理する単位 |
| 最小台数 | これ以下には減らさない下限 |
| 希望台数 | いま維持したい台数 |
| 最大台数 | これ以上は増やさない上限 |
| スケールアウト | 台数を増やすこと |
| スケールイン | 台数を減らすこと |
| Launch Template | どんなEC2を起動するかをまとめた設定 |
特に大事なのは、Auto Scaling = サービス名 と Auto Scaling Group = 実際に管理するEC2の単位 を分けて見ることです。
Auto Scaling Group で何を決めるのか
Auto Scaling Group では、主に次のことを決めます。
- 1
1. どんなEC2を起動するか
通常は Launch Template を使う。
- 2
2. 何台を基準に維持するか
min・desired・max を設定する。
- 3
3. どんな条件で増減させるか
通常は CloudWatch のメトリクスを使う。
1. どんなEC2を起動するか
ここは Launch Template を使います。旧方式の Launch Configuration は、2024年10月1日以降に作成したアカウントではどの方法でも新規作成できず、公式も Launch Template への移行を案内しています。
Launch Template には、AMI、インスタンスタイプ、セキュリティグループ、ストレージ設定などを入れます。
つまり Auto Scaling Group は、同じ性格のEC2を必要に応じて複製する箱 です。
このため、1台ごとに手で調整するより、同じ構成を横に増やせる設計のほうが相性がよいです。
2. 何台を基準に維持するか
AWS公式でも、Auto Scaling Group には min desired max を設定すると説明されています。
たとえば、
- 最小 2
- 希望 2
- 最大 6
なら、平常時は2台を維持しつつ、必要に応じて最大6台まで増やせる、という意味になります。
ここで初心者が混乱しやすいのは「希望台数」です。これは、「いまこの瞬間に維持したい台数」と考えると分かりやすいです。
3. どんな条件で増減させるか
負荷が増えたら増やし、落ち着いたら減らす条件を設定します。
この判断には、通常 CloudWatch のメトリクスが使われます。
どうやって増減するのか
Auto Scaling の増減方法はいくつかありますが、AWS公式でも特に中心になるのは 動的スケーリング です。代表的には次の3つです。
目標値を保つ
1. Target Tracking
最も初心者向けで分かりやすい方式です。AWS公式でも、Target Tracking はサーモスタットのように目標値を保つ考え方として説明されています。たとえば「CPU使用率を平均50%前後に保ちたい」「ALBの1ターゲットあたりリクエスト数を一定範囲に保ちたい」といった目標を置くと、Auto Scaling が必要に応じて台数を増減します。
段階的に変える
2. Step Scaling
しきい値の超え方に応じて、増減幅を段階的に変える方式です。たとえば「CPUが60%を超えたら1台増やす」「80%を超えたら2台増やす」のように決めます。
時間で変える
3. Scheduled Scaling
毎日の決まった時間に台数を変える方法です。たとえば「平日朝は増やす」「夜は減らす」「キャンペーン時間帯だけ事前に増やす」のような予測しやすい負荷に向きます。
Target Tracking がよく使われるのは、「何台増やすかを人が細かく決めなくてよい」からです。Step Scaling は細かく制御したいときには向きますが、最初からここまで作り込むより、まずは Target Tracking のほうが分かりやすい場面が多いです。
ヘルスチェックで置き換えるとはどういうことか
Auto Scaling の大事な役割の1つがここです。
AWS公式では、Auto Scaling Group 内のインスタンスは継続的に健康状態を監視され、不健全と判断されたものは置き換えられると説明されています。
ヘルスチェックで置き換える流れ
- 1
- 2不健全と判断する
EC2のステータスチェックに失敗した、ロードバランサーのヘルスチェックで落ちた、期待した状態になっていない。
- 3新しいEC2を起動する
同じ希望台数を維持するために置き換える。
つまり、たとえ負荷が増えていなくても、
- EC2のステータスチェックに失敗した
- ロードバランサーのヘルスチェックで落ちた
- 期待した状態になっていない
という場合には、同じ希望台数を維持するために新しいEC2を起動する ことがあります。
このため Auto Scaling は、単なるコスト最適化機能ではなく、可用性を上げるための基盤でもあります。
どんな場面で使うのか
Auto Scaling は、次のようなアプリで相性がよいです。
変動
アクセス変動がある
Webアプリのアクセス変動がある
複数台
EC2を複数台並べている
EC2を複数台並べて運用している
継続
1台壊れても続けたい
1台壊れてもサービスを続けたい
処理基盤
条件で増減させたい
バッチや処理基盤を一定条件で増減させたい
逆に、1台の中に状態を抱え込みすぎる構成だと、Auto Scaling の効果を活かしにくいです。同じ設定で複数台を立ち上げても困らない、という作りのほうが向いています。
よくある誤解
それだけではありません。不健全なインスタンスの置き換えも重要な役割です。
そこまではいきません。最小・最大・希望台数、どのメトリクスを見るか、ウォームアップ時間をどう考えるかは自分で決める必要があります。
意味がゼロではありませんが、「1台落ちても自動で補充する」程度に留まりやすいです。可用性の恩恵をしっかり受けるなら、複数台前提でロードバランサーと組み合わせる構成のほうが効果が見えやすいです。
最初に覚えるならどこを見るべきか
最初は次の順で理解すると整理しやすいです。
Auto Scaling を理解する順番
- 1AMI と Launch Template で起動設定を決める
どんなEC2を起動するかをまとめる。
- 2Auto Scaling Group で「最小・希望・最大」を決める
何台を基準に維持するかを決める。
- 3CloudWatch メトリクスで増減条件を決める
負荷に応じて増やし、落ち着いたら減らす。
- 4ヘルスチェックで壊れた台を置き換える
希望台数を維持する。
この4つがつながると、Auto Scaling の全体像はかなり見えます。
EC2 Auto Scalingのよくある質問
Q. Auto Scaling は本当に自動で増減しますか？
A. 設定したルールに従って自動増減します。CPU 70%超で +1台、30%未満で -1台、スケジュール(平日9-18時は3台) などのルール次第。設定なしで自動 ではなく、設定通りに自動 です。
Q. 起動が遅くて急増する負荷に追いつきません。
A. AMI に必要なものを焼き込む(Custom AMI)、Warm Pools で予熱インスタンスを用意、Predictive Scaling で予測増減、で対応します。起動時間を短縮するアプリ設計も重要。
Q. スケジュールベースとメトリクスベース、どちらを使う？
A. 両方併用が定番。平日昼間は最低3台(スケジュール) + 負荷で増減(メトリクス)、のような構成。完全予測可能ならスケジュール、予測困難ならメトリクス、と使い分けます。
Q. スケールイン(台数減らす)で困ることは？
A. 処理中のリクエストが切れる、長時間バッチが中断、などです。ALB の登録解除の遅延(deregistration delay。既定300秒、処理中のリクエストの完了を待つ)、Lifecycle Hook(処理完了待ち)、で対策します。
Q. ヘルスチェック失敗時の挙動は？
A. ヘルスチェック NG のインスタンスを自動終了 → 新規インスタンスを起動。既定は EC2 のステータスチェックで、ELB ヘルスチェック、VPC Lattice、EBS(ボリュームの障害)、カスタムのヘルスチェックを追加で有効にすると、より厳密に判定できます。
Q. Auto Scaling Group とロードバランサーの関係は？
A. ALB のターゲットグループに自動登録/解除。新規起動 → ターゲットグループに追加 → ヘルスチェック合格 → トラフィック流入、終了予定 → ターゲットから外す → 登録解除の遅延(処理中のリクエストを待つ) → 終了、の流れ。
Q. ECS や Kubernetes の Auto Scaling は別物？
A. 別物。EC2 Auto Scaling は仮想マシン単位、ECS Service Auto Scaling はタスク単位、Kubernetes HPA は Pod 単位。コンテナを動かす場合は ECS/EKS の Auto Scaling と EC2 の両方を組み合わせます。
まとめ
Auto Scaling は、EC2の台数を自動で増減しつつ、不健全なインスタンスを置き換えて、必要な台数を維持する仕組みです。
AWSでは Auto Scaling Group を使って、どんなEC2を何台維持するか をまとめて管理します。
最初に押さえるなら、
- Launch Template で起動設定をまとめる
- 最小・希望・最大台数を決める
- CloudWatch メトリクスで増減させる
- ヘルスチェックで壊れた台を置き換える
この流れで考えるとかなり分かりやすいです。
この記事と一緒に読む
- EC2とは？仮想サーバーの基本をAWS初心者向けに整理
- AMIとは？EC2起動テンプレートの意味
- AWSで知っておくべき基本的な単語とは？EC2・IAM・S3・VPCのつながりを初心者向けに整理
- Launch Template
- CloudWatch
参考リンク
- AWS Docs: What is Amazon EC2 Auto Scaling?
- AWS Docs: Dynamic scaling for Amazon EC2 Auto Scaling
- AWS Docs: Target tracking scaling policies for Amazon EC2 Auto Scaling
- AWS Docs: Health checks for instances in an Auto Scaling group
- AWS Docs: Create Auto Scaling groups using launch templates
- AWS Docs: Auto Scaling launch configurations（新規アカウントでの制限）
- AWS Docs: Edit target group attributes（Deregistration delay）