先に結論
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 の全体像はかなり見えます。
まとめ
Auto Scaling は、EC2の台数を自動で増減しつつ、不健全なインスタンスを置き換えて、必要な台数を維持する仕組みです。
AWSでは Auto Scaling Group を使って、どんなEC2を何台維持するか をまとめて管理します。
最初に押さえるなら、
- Launch Template で起動設定をまとめる
- 最小・希望・最大台数を決める
- CloudWatch メトリクスで増減させる
- ヘルスチェックで壊れた台を置き換える
この流れで考えるとかなり分かりやすいです。
この記事と一緒に読む
- EC2とは？仮想サーバーの基本をAWS初心者向けに整理
- AMIとは？EC2起動テンプレートの意味
- AWSで知っておくべき基本的な単語とは？EC2・IAM・S3・VPCのつながりを初心者向けに整理
- Launch Template
- CloudWatch