EC2 を1台立て、ELB の後ろに2台並べるところまではできた。でも、アクセスが急に増えたら誰が3台目を立てるのか。夜中に1台が壊れたら、朝まで1台で耐えるのか。台数を手で増やし、壊れたら手で作り直す運用は、台数とアカウントが増えるほど回らなくなります。ここで出てくるのが Amazon EC2 Auto Scaling です。ただ、設定画面には起動テンプレート、希望する容量、ターゲット追跡、ヘルスチェックの猶予期間と、似た言葉が並びます。この記事は「何を自動にするのか」→「いつ何台にするのか」→「壊れた台をどう入れ替えるのか」→「ELB と複数 AZ とどう組むか」の順に、言葉の関係を整理します。
この記事の結論
- Amazon EC2 Auto Scaling は、EC2 インスタンスの台数を需要に合わせて自動で増減し、異常な台を入れ替えて決めた台数を保つサービスです。
- Auto Scaling グループは、起動テンプレート（どんな1台か）と、希望する容量・最小・最大（何台か）をまとめた単位です。
- スケーリングポリシーは、ターゲット追跡・ステップ・スケジュール・予測の4つから、負荷の読みやすさで選び、併用できます。
- 既定のヘルスチェックは EC2 のステータスチェックだけで、アプリの異常まで入れ替えるには ELB のヘルスチェックを加えます。
- 複数の AZ にまたがるグループを ELB と組み合わせると、1つの AZ が止まっても残りの AZ で台数を補えます。
EC2 Auto Scaling とは何か（何を自動にするか）
たとえるなら、Auto Scaling はお店のシフト係です。店員の人数（台数）の最低と上限を決めておき、混む時間には呼び、空いたら帰し、倒れた人が出たらすぐ代わりを呼ぶ。店員1人の仕事内容（マニュアル）は、あらかじめ1枚にまとめてある。これを正確な言葉に戻すと、次の3つの部品になります。
FOUR PARTSAuto Scaling の部品
Auto Scaling は1台・台数・いつ・入替の4つで決まる
-
1台
起動テンプレート — AMI・タイプ・SG・ロールをまとめる
版を持てる。起動設定は使わない
-
台数
Auto Scaling グループ — 希望・最小・最大を持つ
複数 AZ のサブネットに置く
-
いつ
スケーリングポリシー — 希望する容量を動かす
ターゲット追跡・ステップ・スケジュール・予測
-
入替
ヘルスチェック — 異常な台を終了して起動し直す
ELB の後ろなら ELB のチェックも加える
起動テンプレート（どんな1台か）
起動テンプレートは、AMI・インスタンスタイプ・キーペア・セキュリティグループ・IAM ロール・起動時に流すスクリプト（ユーザーデータ）など、「1台を起動するときの設定」をまとめたものです。版を持てるので、AMI を新しくしたら新しい版を作ってグループに使わせます。古い仕組みの起動設定（launch configuration）もありますが、AWS は使わないよう強く勧めており、2024-10-01 以降に作られたアカウントでは新しく作れません。
Auto Scaling グループ（何台を保つか）
Auto Scaling グループは、同じ起動テンプレートから起動したインスタンスの集まりで、どのサブネット（AZ）に置くかと、3つの容量を持ちます。
| 容量 | 意味 | 決め方の目安 |
|---|---|---|
| 希望する容量 | いま保とうとする台数。ポリシーや手で変わる | 最初はふだんの負荷を支えられる台数 |
| 最小 | これより減らさない下限 | 1台が壊れても耐えられる台数（複数 AZ なら AZ の数以上） |
| 最大 | これより増やさない上限 | 費用の上限と、後ろの DB などが耐えられる台数 |
保とうとするのは「希望する容量」で、最小と最大はその動ける範囲です。ポリシーが「10台にしたい」と判断しても、最大が8なら8台で止まります。
CHECK 1ここまでの確認
最小2・希望する容量4・最大8の Auto Scaling グループで、ふだん動いている台数は何台?
答えと解説
答え: 2. 4台
Auto Scaling が保とうとするのは「希望する容量」です。最小と最大は、ポリシーが希望する容量を動かせる範囲の下限と上限です。「3つの容量」の表を読み直してください。
スケーリングポリシーとは（いつ何台にするか）
希望する容量を、いつ・どれだけ動かすかの決まりがスケーリングポリシーです。EC2 Auto Scaling には次の4つがあります。
| ポリシー | 何を見て台数を決めるか | 合う場面 |
|---|---|---|
| ターゲット追跡 | 指標（平均 CPU 使用率など）を目標値に保つよう自動で増減 | まず選ぶ基本の形。負荷が上下するが予測はしにくい |
| ステップ | CloudWatch アラームを超えた幅に応じて、段階的に何台足すか引くかを決める | 超えた幅によって増やし方を変えたい |
| スケジュール | 決めた日時に、希望・最小・最大の値を変える | 始業前・キャンペーン開始など、時刻の分かっている山 |
| 予測 | 過去の負荷から日・週の周期を見つけ、先回りして容量を増やす | 毎日・毎週同じ形の山が繰り返される |
ターゲット追跡では、目標値を決めるだけで、必要な CloudWatch アラームは Auto Scaling が作って管理します。ステップは自分でアラームを用意し、「10% 超えたら1台、30% 超えたら3台」のように増やし方を段階で書きます。
併用すると「大きい方」が使われる
ポリシーは組み合わせられます。複数のポリシーが同時に働くと、それぞれが希望する容量を出し、そのうち最も大きい値が使われます。たとえば、ふだんはターゲット追跡で追いかけ、始業前だけスケジュールで最小を上げておけば、朝の山に起動が間に合わない問題を避けられます。予測スケーリングは、まず予測だけを出すモードで当たり具合を確かめてから、実際に容量を動かすモードに切り替える使い方ができます。
MINIMUM CAPACITY最小の置き方
最小は山を前もって読めるかで決める
最小を小さく
- 使わない時間の費用が減る
- 急な山に起動が間に合わないことがある
- 山の時刻が読めるなら先回りで補う
最小を大きく
- 急な山にも強い
- 使わない時間も費用がかかる
- 読めない山が多いときの備え
支点は「負荷の山を前もって読めるか」
最小を小さくすれば、使わない時間の費用は減ります。ただ、インスタンスは起動してアプリが使えるようになるまでに時間がかかるので、急な山には間に合わないことがあります。山の時刻が読めるならスケジュールや予測で先回りし、最小は小さく保つのが、費用と応答の両方を取りにいく考え方です。
CHECK 2ここまでの確認
毎週月曜の朝にだけ負荷が上がると分かっているとき、先回りして備える方法として合うのはどれ?
答えと解説
答え: 2. 月曜の朝の前に容量を上げるスケジュールを足し、ふだんのポリシーと併用する
時刻が分かっている山には、スケジュールされたスケーリングで先に容量を上げておきます。ターゲット追跡などと併用でき、複数のポリシーが出した値のうち大きい方が使われます。「スケーリングポリシーとは」の表を読み直してください。
ヘルスチェックと入れ替えはどう働くか
Auto Scaling のもう1つの仕事は、壊れた台を見つけて入れ替えることです。グループは定期的に各インスタンスの状態を確かめ、異常と判定した台を終了し、希望する容量を保つために新しい台を起動テンプレートから起動します。
REPLACE THE BROKEN壊れた1台の入れ替え
異常な1台は終了して起動し直し、希望する容量に戻す
-
ヘルスチェック
EC2・ELB で
異常を検知 -
終了
異常な台を止める
-
起動
起動テンプレート
から新しい台 -
登録
ターゲットグループ
に自動で入る -
希望する容量
決めた台数に戻る
何を見て「異常」とするか
| ヘルスチェック | 何を見るか | 既定で有効か |
|---|---|---|
| EC2 のステータスチェック | 土台のホストの問題（システムステータス）と、インスタンス自体の問題（インスタンスステータス） | 常に有効 |
| ELB のヘルスチェック | ロードバランサーが送るリクエストに、アプリが正しく応答するか | 無効（グループの設定で加える） |
既定では Auto Scaling は ELB のヘルスチェックの結果を無視します。OS が動いていればアプリが固まっていても「正常」のままで、ALB は通信を送らないのに Auto Scaling は入れ替えない、という状態が起きます。ELB の後ろに置くグループでは、ELB のヘルスチェックを加えておくのが基本です。その際、起動してからアプリが準備できるまでの時間を「猶予期間」として取っておかないと、準備中の台を異常と判定して入れ替え続けることがあります。
インスタンスは使い捨てにする
入れ替えやスケールインでは、インスタンスはいつでも終了されます。ログイン状態やファイルを1台の中だけに置くと、その台と一緒に消えます。セッションは ElastiCache や DynamoDB、ファイルは S3 や EFS へ出し、どの1台が消えても困らない（ステートレスな）形にしておくのが、Auto Scaling を使う前提です。終了の前にログを退避したいときは、ライフサイクルフックで終了を待たせる仕組みもあります。
Auto Scaling でつまずきやすい3つ
- ELB の後ろなのに、ヘルスチェックを EC2 のステータスチェックだけにしている（アプリが固まっても入れ替わらない）
- ログイン状態をインスタンスのメモリに置いたまま台数を増減させる（スケールインのたびに利用者がログアウトされる）
- 1つの AZ のサブネットだけでグループを作る（その AZ が止まると全台が止まる）
CHECK 3ここまでの確認
ALB の後ろのアプリが固まったのに、Auto Scaling が入れ替えない。まず疑う設定はどれ?
答えと解説
答え: 1. Auto Scaling グループのヘルスチェックに ELB のヘルスチェックを加えていない
既定では Auto Scaling は EC2 のステータスチェックだけを見ます。OS が動いていればアプリが固まっても正常と判定されます。ELB のヘルスチェックを加えると、ロードバランサーが異常と見た台も入れ替えます。「ヘルスチェックと入れ替え」の章を読み直してください。
ELB と複数 AZ と組み合わせるとは
Auto Scaling は単独でも台数を保てますが、Web の構成では ELB と組み合わせて初めて「増えた台に通信が届く」ようになります。グループに ALB のターゲットグループを関連付けておくと、Auto Scaling が起動した台は自動でターゲットに登録され、終了する台は登録から外されます。台数が変わるたびに ALB の設定を手で直す必要はありません。
READ ALSO — 学習中向け・段2 構成
Elastic Load Balancing とは何か｜ALB・NLB・GWLB の違いとヘルスチェック、複数 AZ
グループには複数の AZ のサブネットを指定します。Auto Scaling は、有効な AZ の間で台数が均等になるよう、台数の少ない AZ に新しい台を起動します。1つの AZ が使えなくなると、残りの AZ で希望する容量を補い、AZ が戻ると再び均等に並べ直します。並べ直すときは新しい台を先に起動してから古い台を終了するので、並べ直しの間に台数が減ることはありません。
| 層 | 担当 | 何を見て動くか |
|---|---|---|
| 名前 | Route 53 | ルーティングポリシーとヘルスチェック（サイト・リージョン単位） |
| 通信の配り先 | ELB | ターゲットのヘルスチェック（1台ずつ） |
| 台数 | EC2 Auto Scaling | スケーリングポリシーと、EC2・ELB のヘルスチェック |
台数が増減するので、アプリ層のセキュリティグループで「Web 層からだけ許可」を IP アドレスで書くと、台が入れ替わるたびに崩れます。送信元に Web 層のセキュリティグループを指定しておけば、台数が変わっても書き直しは要りません。
READ ALSO — 未経験向け・段1 入口
セキュリティグループとネットワーク ACL の違い｜2つの門の仕組み
まとめ
- EC2 Auto Scaling は、台数を需要に合わせて増減し、異常な台を入れ替えて、希望する容量を保ちます。
- 部品は、どんな1台かを決める起動テンプレートと、何台を保つかを決める Auto Scaling グループ（希望・最小・最大）です。
- スケーリングポリシーは、基本のターゲット追跡に、時刻の分かる山ならスケジュール、周期のある山なら予測を重ねます。
- ELB の後ろでは ELB のヘルスチェックを加え、複数の AZ にまたがるグループにして、1つの AZ が止まっても台数を保てるようにします。
- 次は、増やす台を安く買う方法（購入オプション）と、何を見てアラームを鳴らすかの監視設計へ進んでください。
参照ソース
- What is Amazon EC2 Auto Scaling?（Amazon EC2 Auto Scaling User Guide） — Auto Scaling グループと希望・最小・最大の容量、料金の考え方の根拠（2026-09 時点の記載）
- Auto Scaling launch templates（Amazon EC2 Auto Scaling User Guide） — 起動テンプレートの推奨と、2024-10-01 以降に作られたアカウントで起動設定を作れないことの根拠（2026-09 時点の記載）
- Choose your scaling method（Amazon EC2 Auto Scaling User Guide） — スケーリングの方法の種類の根拠（2026-09 時点の記載）
- Target tracking scaling policies（Amazon EC2 Auto Scaling User Guide） — ターゲット追跡と、アラームを Auto Scaling が管理することの根拠（2026-09 時点の記載）
- Step and simple scaling policies（Amazon EC2 Auto Scaling User Guide） — ステップスケーリングの根拠（2026-09 時点の記載）
- Scheduled scaling（Amazon EC2 Auto Scaling User Guide） — スケジュールされたスケーリングの根拠（2026-09 時点の記載）
- Predictive scaling（Amazon EC2 Auto Scaling User Guide） — 予測スケーリングが過去の負荷から周期を見つけて先回りすることの根拠（2026-09 時点の記載）
- Health checks for instances in an Auto Scaling group（Amazon EC2 Auto Scaling User Guide） — 既定は EC2 のステータスチェックで、ELB のヘルスチェックは加えると使われることの根拠（2026-09 時点の記載）
- Auto Scaling benefits for application architecture（Amazon EC2 Auto Scaling User Guide） — 複数 AZ への均等な配置と、並べ直しで新しい台を先に起動することの根拠（2026-09 時点の記載）
