先に結論
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をもとに整理しています。
Auto Scalingとは何か
AWS公式では、Amazon EC2 Auto Scaling は アプリの負荷を処理するのに適切な数の EC2 インスタンスを維持する サービスとして説明されています。
この説明の中には、実は2つの役割が入っています。
1. 台数を増減する
アクセスや負荷に応じて、EC2を増やしたり減らしたりします。
これが一般にイメージされやすい Auto Scaling です。
2. 壊れたインスタンスを置き換える
Auto Scaling は、単に増減するだけではなく、グループ内のインスタンスが不健全になったら新しいものへ置き換える役割も持ちます。
つまり、台数調整 と 自己修復 の両方を担う、と理解するとかなり分かりやすいです。
まず押さえたい用語
Auto Scaling を読むと、似た言葉が続くので最初に整理しておくと楽です。
| 用語 | 意味 |
|---|---|
| Auto Scaling Group | EC2群をまとめて管理する単位 |
| 最小台数 | これ以下には減らさない下限 |
| 希望台数 | いま維持したい台数 |
| 最大台数 | これ以上は増やさない上限 |
| スケールアウト | 台数を増やすこと |
| スケールイン | 台数を減らすこと |
| Launch Template | どんなEC2を起動するかをまとめた設定 |
特に大事なのは、Auto Scaling = サービス名 と Auto Scaling Group = 実際に管理するEC2の単位 を分けて見ることです。
Auto Scaling Group で何を決めるのか
Auto Scaling Group では、主に次のことを決めます。
- どんなEC2を起動するか
- 何台を基準に維持するか
- どんな条件で増減させるか
1. どんなEC2を起動するか
ここは通常、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台増やす
のように決めます。
細かく制御したいときには向きますが、最初からここまで作り込むより、まずは Target Tracking のほうが分かりやすい場面が多いです。
3. Scheduled Scaling
毎日の決まった時間に台数を変える方法です。
たとえば、
- 平日朝は増やす
- 夜は減らす
- キャンペーン時間帯だけ事前に増やす
のような予測しやすい負荷に向きます。
ヘルスチェックで置き換えるとはどういうことか
Auto Scaling の大事な役割の1つがここです。
AWS公式では、Auto Scaling Group 内のインスタンスは継続的に健康状態を監視され、不健全と判断されたものは置き換えられると説明されています。
つまり、たとえ負荷が増えていなくても、
という場合には、同じ希望台数を維持するために新しいEC2を起動する ことがあります。
このため Auto Scaling は、単なるコスト最適化機能ではなく、可用性を上げるための基盤でもあります。
どんな場面で使うのか
Auto Scaling は、次のようなアプリで相性がよいです。
逆に、1台の中に状態を抱え込みすぎる構成だと、Auto Scaling の効果を活かしにくいです。
同じ設定で複数台を立ち上げても困らない、という作りのほうが向いています。
よくある誤解
1. Auto Scaling はCPUが上がったら増やすだけ
それだけではありません。
不健全なインスタンスの置き換えも重要な役割です。
2. Auto Scaling を入れれば何でも自動で最適化される
そこまではいきません。
最小・最大・希望台数、どのメトリクスを見るか、ウォームアップ時間をどう考えるかは自分で決める必要があります。
3. 1台構成のままでも十分意味がある
意味がゼロではありませんが、1台落ちても自動で補充する 程度に留まりやすいです。
可用性の恩恵をしっかり受けるなら、複数台前提でロードバランサーと組み合わせる構成のほうが効果が見えやすいです。
最初に覚えるならどこを見るべきか
最初は次の順で理解すると整理しやすいです。
- AMI と Launch Template で起動設定を決める
- Auto Scaling Group で
最小・希望・最大を決める - CloudWatch メトリクスで増減条件を決める
- ヘルスチェックで壊れた台を置き換える
この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. 処理中のリクエストが切れる、長時間バッチが中断、などです。Connection Draining(ALB のターゲット切り離し)、Lifecycle Hook(処理完了待ち)、で対策します。
Q. ヘルスチェック失敗時の挙動は？
A. ヘルスチェック NG のインスタンスを自動終了 → 新規インスタンスを起動。ELB ヘルスチェック、EC2 ヘルスチェック の組み合わせで、より厳密な判定が可能。
Q. Auto Scaling Group とロードバランサーの関係は？
A. ALB のターゲットグループに自動登録/解除。新規起動 → ターゲットグループに追加 → ヘルスチェック合格 → トラフィック流入、終了予定 → ターゲットから外す → Connection Draining → 終了、の流れ。
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