Amazon EC2 Auto Scaling のスケーリングは、暗記よりも「どういう状況で、どの意思決定が走るのか」を理解すると、設計でも試験でも迷いが減ります。ここでは ターゲット追従スケーリング、ステップスケーリング、予定スケーリング を、挙動・得意不得意・組み合わせ時の注意点まで、具体例で整理します。
（以降の用語は主に Amazon EC2 Auto Scaling を軸に説明しつつ、必要に応じて Application Auto Scaling 側の考え方も補足します。）
Auto Scalingのスケーリングポリシー全体像
まず全体像を押さえると、3方式は「どのタイミングで」「何を根拠に」「どれくらい増減させるか」の設計思想が違います。
- ターゲット追従スケーリング
あるメトリクスを “狙った値” に近づけ続ける方式です。温度調節（サーモスタット）のように、メトリクスが目標から外れたら自動で調整します。 - ステップスケーリング
CloudWatch アラームの「しきい値超え」をトリガーに、超え方の大きさに応じて増減幅を段階的に変える方式です。 - 予定スケーリング
時刻表どおりに、事前に決めた時間に最小・最大・希望キャパシティなどを調整する方式です。定期的な波に強いです。
試験目線で大事なのは、「3つは排他ではなく、併用してよい」という点です。予定で“前倒しの土台”を作り、動的スケーリング（ターゲット追従やステップ）で“その後の揺れ”に追随するのが王道です。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
ターゲット追従スケーリングの考え方
ターゲット追従は、「この ASG は平均 CPU をだいたい 50% くらいに保ちたい」のように、目標値を決めて、そこに近づくように自動調整します。ターゲット値を指定するのが基本で、個別のアラームや増減幅を手で組む発想から離れられるのがメリットです。
どういうときに向いているか
- トラフィックが日々ゆらぎ、手動調整が追いつかない
- 目標にしたい指標が素直（例：ASG の平均 CPU、平均リクエスト数など）で、目標値が置ける
メトリクス選びの落とし穴
ターゲット追従は万能ではなく、ASG の台数に比例して増減しない指標を使うと期待どおりに動きません。AWS のドキュメントでも、例として RequestCount や Latency など “比例しづらい指標” はターゲット追従に向かないケースが説明されています。
SAA-C03でも、ここを曖昧に覚えていると「なぜその指標でターゲット追従を選ぶのか」が説明できず、選択肢で揺れやすいところです。
クールダウンとウォームアップのイメージ
ターゲット追従やステップは、昔ながらの単純スケーリングの “クールダウン待ち” と挙動が違い、スケールアウトはすぐ走れる一方で、インスタンス側のウォームアップやスケールイン抑制が絡みます。結果として「増やすのは早いが、減らす判断は慎重にされる」ように感じることがあります。
ここは暗記よりも、「新規インスタンスが戦力化するまでの時間をどう見積もるか」という運用の視点で理解すると強いです。
ステップスケーリングの考え方
ステップスケーリングは、CloudWatch アラームが鳴ったら増減する方式で、「どれくらい超えたら、何台増やすか」を段階的に決められます。
どういうときに向いているか
- “急に跳ねる” 負荷に対して、増やし方を細かく制御したい
例：CPU が 70% なら +1、90% なら +3 のように、超え方に応じて攻める - 既にアラーム設計があり、チームの運用がアラーム中心で回っている
ターゲット追従との違いを一言で
- ターゲット追従：目標値に近づけ続ける。調整ロジックは AWS に委ねやすい。
- ステップ：しきい値超えを合図に、人が決めた段階ルールで増減する。
試験では、「しきい値ベースのアラーム駆動」か「目標値に追従」かを文章から読み取るのがコツです。
併用時に起きがちなこと
複数の動的スケーリングを併用すると、片方がスケールインした直後にもう片方がスケールアウトを指示する、のように“揺れ”が出る可能性があります。AWS 側も、ポリシー同士の相互作用に触れています。
実務でも試験でも、対策は「目的が被るポリシーを増やしすぎない」「メトリクスの役割分担を明確にする」です。
予定スケーリングの考え方
予定スケーリングは、決まった時間にキャパシティを調整する方式です。「毎週水曜の朝は増やす、金曜の夜は減らす」のように、周期的なパターンがあるときに効きます。
どういうときに向いているか
- “読めるピーク” がある（平日昼だけ増える、月末に処理が集中する など）
- ピーク前に 先に 台数を用意しておきたい
動的スケーリングだけだと、増えるまでの遅れが体感性能に効くことがあります
予定だけで完結させないほうがいい理由
予定はあくまで時刻表なので、想定外の増減には弱いです。AWS も、予定とスケーリングポリシー（動的スケーリング）を組み合わせて proactive と reactive の両方を取りに行けることを説明しています。
地味にハマる制約
- 同じ cron 式が複数あると実行順序が未定義になり得るので、予測可能にするなら時刻をずらす、などの工夫が必要です。
- 予定アクションは、スケーリングのクールダウンを待たずに実行されることがあります。
このあたりは「運用で事故りやすい点」として覚えるより、「なぜそうなると困るか」まで想像できると選択肢に強くなります。
SAA-C03で混乱しない使い分けと設計のコツ
最後に、SAA-C03の学習者が迷いやすいポイントを、判断軸としてまとめます。文章問題で情報が多くても、この軸に落とせると選びやすいです。
判断軸は3つだけでいい
- 負荷が予測できるか
予測できるなら予定で“先に”用意する。予測できない部分は動的で吸収。 - 目標値で語れるか、しきい値で語れるか
“CPU を 50% に保ちたい” ならターゲット追従。
“80% を超えたら +2” のように言いたいならステップ。 - メトリクスが台数に比例するか
比例しない指標でターゲット追従を選ぶと、そもそも設計が破綻しやすい。
具体例でイメージする
- 例：平日昼にアクセスが増える Web アプリ
まず予定で昼前に最小キャパシティを上げておき、昼の揺れはターゲット追従で平均 CPU を安定させる、のように組みます。 - 例：突発的に負荷が跳ねるバッチ受付
しきい値を超えたら一気に増やしたいならステップが合います。段階ルールにしておくと、跳ね方が大きいときに強めに増やせます。
学習の進め方としてのUdemyの使いどころ
スケーリングは、用語を覚えるだけだと「結局どれを選ぶの？」で詰まりがちです。CloudWatch のメトリクス選定、アラーム設計、ウォームアップを含めた一連の設計として整理できる教材だと理解が早いです。
体系的に学べる教材の一例として、Udemy で EC2 Auto Scaling と CloudWatch をハンズオンで触れる講座（SAA-C03対策の中でスケーリング周辺を丁寧に扱うコース）を一本入れておくと、文章で読んだ知識が「挙動の感覚」に変わりやすいです。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
Auto Scaling のスケーリングポリシーは、ターゲット追従は「目標値に近づけ続ける」、ステップは「アラームしきい値を合図に段階ルールで増減」、予定は「決まった時間に前倒しで土台を作る」という思想の違いがあります。
SAA-C03では、文章から「予測できる波か」「目標値かしきい値か」「メトリクスが台数に比例するか」を読み取り、併用の形までイメージできると、選択肢の切り分けがかなり楽になります。
