導入
深夜はアクセスが少なく、日中はピークになる。常に最大構成で待機するのはコストの無駄です。需要に合わせてEC2の台数を自動で増減させるのがAuto Scalingです。
説明
EC2 Auto Scaling は、起動テンプレート（Launch Template） に定義したインスタンス構成をもとに、需要に応じてEC2の台数を自動で調整する仕組みです。スケーリング方法には複数の種類があります。
| スケーリング方法 | 仕組み |
|---|---|
| 動的スケーリング（ターゲット追跡） | CPU使用率など指標を目標値に保つよう自動調整 |
| 動的スケーリング（ステップスケーリング） | 閾値超過の度合いに応じて段階的に増減 |
| 予測スケーリング（Predictive Scaling） | 過去のトラフィックパターンを機械学習で予測し先回りして調整 |
| スケジュールスケーリング | 「毎朝9時に増やす」など時刻ベースで調整 |
sequenceDiagram
participant CW as CloudWatch
participant AS as Auto Scaling
participant ELB as ELB
CW->>AS: CPU使用率が閾値超え
AS->>AS: 新しいEC2を起動
AS->>ELB: 新インスタンスを登録
ELB->>ELB: ヘルスチェック後にトラフィック分散
Auto ScalingはELBのヘルスチェックと連携し、異常なインスタンスを検知すると自動的に終了させ、正常なインスタンスに置き換えます。これにより「障害が起きたら誰かが手動で直す」ではなく「システムが自分で治す」= 自己修復（self-healing） と 疎結合 を実現します。これは信頼性の柱の中核です。
具体例
通販サイトが、2種類の需要変動にスケーリング方法を使い分けます。
- 読める波（毎朝のセールと深夜の閑散）→ スケジュールスケーリング … 「毎朝9時のタイムセールに合わせて8時50分に台数を増やす」と時刻指定。急な負荷でスケールが後手に回るのを防ぐ。
- 読めない波（テレビ紹介で突然の殺到）→ 動的スケーリング（ターゲット追跡） … 「平均CPUを50%に保つ」と設定しておけば、想定外のアクセス急増でも自動で台数が増える。
さらに、この2つと別の恩恵が自己修復です。ある日、8台のうち1台がフリーズしてヘルスチェックに失敗。Auto Scalingはそれを検知して自動で終了→新しいインスタンスに置き換え、担当者は何もしていないのにサービスは正常なまま。「深夜に障害対応で叩き起こされる」運用から解放されます。
SAAでは「需要変動に自動対応」「障害時に自動置き換え」「無駄なコスト削減」が揃ったら、Auto Scaling ＋ ELB ＋ Multi-AZのセットがほぼ正解です。
読んでみよう
「需要変動に自動対応」「障害時に自動で置き換え」「無駄なコストを削減」という3つのキーワードが揃ったら、まずAuto Scalingを検討してください。SAAでは「Auto Scaling + ELB + Multi-AZ」がセットで正解になるパターンが非常に多いです。