EC2 Auto Scaling の動的・スケジュール・予測スケーリングで最大キャパシティを超えられるのか検証してみた

はじめに

動的スケーリングポリシーを設定したのにスケールアウトしないという状況に遭遇し、調査したところ最大キャパシティが低く、頭打ちになっていることが原因でした。
動的スケーリングが最大キャパシティを超えられないのは分かりましたが、他のスケーリング（スケジュール・予測）でも同じ挙動なのか気になったので、3 種類を実際に動かして確認してみました。

結論

3 種類のスケーリングのおさらい

まず前提を整理します。

動的スケーリング

CloudWatch メトリクスの現在値に反応して、希望キャパシティを増減させます。
ターゲット追跡・ステップ・シンプルの 3 方式があります。
増減の範囲は最小〜最大キャパシティの中に収まります。

スケジュールスケーリング

指定した時刻に、最小キャパシティ・最大キャパシティ・希望キャパシティを指定した値に更新します。
負荷変動のパターンが時間的に決まっている場合に有効です。

予測スケーリング

過去のメトリクス履歴から将来の需要を予測し、先回りしてスケールアウトします。

予測スケーリングには MaxCapacityBreachBehavior という設定があります。予測容量が最大キャパシティに近づく、または超えたときの挙動を決めます [1]。

• HonorMaxCapacity（既定）: 最大キャパシティを引き上げない
• IncreaseMaxCapacity: 最大キャパシティを引き上げる。上限は予測容量と MaxCapacityBuffer で決まる

検証環境

Auto Scaling グループを 3 つ用意しました。

共通設定は以下です。

• 起動テンプレート: Amazon Linux 2023 / t3.micro / 詳細モニタリング有効
• 負荷生成用に stress-ng をユーザーデータでインストール

予測スケーリングの用意

予測スケーリングは最低 24 時間のメトリクス履歴が必要で、精度を出すには 14 日分が推奨されています。ただし、実際の負荷で用意すると数日かかってしまいます。

そこで今回はカスタムメトリクスを使い、PutMetricData で過去 13 日分の日次周期データを一括投入しました。

予測スケーリングは Auto Scaling グループの稼働期間ではなく CloudWatch 上のメトリクス履歴を見るので、作りたてのグループでも予測が生成されます。

投入したメトリクスを CloudWatch で確認すると、14 日分の日次周期パターンが確認できます。

検証A: 動的スケーリングは最大キャパシティを超えない

作成時点では以下のように 1 台のみ起動している状態です。

asg-dynamic にターゲット追跡スケーリングポリシー（平均 CPU 使用率 40% を目標）を設定し、stress-ng で CPU 使用率を 95% まで上げました。

結果

1 台で CPU 95% の負荷をかけた結果、希望キャパシティが 1 から 2 に増えました。

2 台になった時点でのグループ平均 CPU 使用率は約 47.5% です。
ターゲット値 40% をまだ超えているため、本来は 3 台に増やしたい状態ですが、最大キャパシティが 2 のためここで止まりました。

なお、最大キャパシティを 3 に引き上げたところ、3 台目が起動しグループ平均 CPU 使用率は約 31.7% に下がり、アラームも解消しました。
動的スケーリング自体は正常に動作しており、最大キャパシティの制約で止まっていただけと確認できました。

検証B: スケジュールスケーリングは最大キャパシティごと書き換えて超える

asg-schedule（最小 1 / 希望 1 / 最大 2）で検証します。

B-1: 最大キャパシティを変えずに超えようとする

まず、最大キャパシティを 2 のままにして、希望キャパシティ 4 のスケジュールアクションを作ろうとしました。

結果はエラーです。希望キャパシティは最小〜最大の範囲内でなければならないという制約に弾かれました。

スケジュールスケーリングであっても、希望キャパシティは最小〜最大の範囲内でなければなりません。

B-2: 最大キャパシティごと書き換える

次に、同じスケジュールアクションで最大キャパシティも一緒に指定しました。

• 最小: 1
• 最大: 5（元は 2）
• 希望: 5

今度は成功しました。
画面下部の「予定されたアクション」から、指定通りのキャパシティとなっていることを確認できます。

アクティビティから、以下を確認できます。

• ASG 作成（ユーザー操作）で希望容量 0→1、EC2 1 台起動
• 15:00:07：スケジュールアクション実行 → min:1 / max:2→5 / desired:1→5 に変更
• 15:00:19〜15:01:26：差分解消のため EC2 4 台を追加起動（計 5 台）

検証C: 予測スケーリング（既定）は最大キャパシティを超えない

asg-predictive に予測スケーリングポリシーを作成し、MaxCapacityBreachBehavior は既定の HonorMaxCapacity、モードは ForecastAndScale（予測とスケール）にしました。

マネジメントコンソールでは、「追加のスケーリング設定」の "予測された容量を超える最大容量をバッファリングする" のチェックの有無で指定可能です。

予測容量が 6 台になる時間帯を狙って観測しました。

結果

結果としては、想定通り最大キャパシティである 2 台のインスタンスのみ起動されている状況でした。

また、予測スケーリングではアクティビティ履歴に予測容量と変更後の希望容量が明記されたログが残りました。

(日本語訳)
2026-08-03T08:55:04Z に、予測スケーリングポリシーが予測容量を 6 に設定し、希望容量を 1 から 2 に変更しました。2026-08-03T08:55:14Z に、希望容量と実際の容量の差を解消するためインスタンスが 1 台起動され、容量が 1 から 2 に増加しました。

上記のように、アクティビティから予測容量と、変更後の希望容量を確認できます。

検証D: 予測スケーリング（IncreaseMaxCapacity）は AWS が最大キャパシティを引き上げる

同じポリシーの MaxCapacityBreachBehavior を IncreaseMaxCapacity に変更し、MaxCapacityBuffer を既定値の 10% にしました。

なお、検証 C と D では観測した時間帯が異なるため、予測容量の値が異なります（検証 C: 予測 6 台、検証 D: 予測 4 台）。予測スケーリングは 1 時間ごとに異なる予測値を持つためです。

結果

希望容量が 2 で止まっていた状況から、予測容量である 4 まで引き上げられました。最大容量も自動的に 4 に引き上げられました。

その他気づき

• 検証B（スケジュール）では Setting max size from 2 to 5. とアクティビティ履歴に明記されましたが、検証D（予測）では最大キャパシティの変更はアクティビティ履歴に一切記録されませんでした。気づくには GroupMaxSize メトリクスや AWS Config 等で追跡する必要があります。

• 予測スケーリングはスケールアウト専用のため、予測が下がっても希望キャパシティ、最大キャパシティは減りません [2]。

まとめ

参考情報

[1] PredictiveScalingConfiguration - Amazon EC2 Auto Scaling API Reference

[2] 予測スケーリングの仕組み - Amazon EC2 Auto Scaling

予測で負荷の減少が予想される場合、キャパシティを削除するためのスケールインは行いません。不要になったキャパシティを削除する場合は、動的スケーリングポリシーを作成する必要があります。

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました