EC2 Auto Scalingのポリシーと運用上の挙動
スケーリングポリシーの種類、複数ポリシーの併用、終了ポリシー、クールダウン、AZ再分散、ライフサイクルフック、障害時の扱いを整理します。
スケーリングポリシーの種類
需要に合わせて台数を変える主な方法は次のとおりです。
- ターゲット追跡（Target tracking） … CPU 平均使用率、ALB のリクエスト数 per ターゲットなど、目標値に近づくように台数を調整します。設定が単純で、運用で最もよく使われるタイプです。内部的には CloudWatch アラームが動きます。
- ステップスケーリング（Step scaling） … メトリクスがしきい値を超えた幅に応じて、増減する台数を段階的に変える。急激な変動に対して細かく反応したいときに使われます。
- シンプルスケーリング（Simple scaling） … アラーム発火に応じた単純な増減。クールダウン中は追加のスケーリングが抑止されやすい、という性質が試験に出ることがあります（現行コンソールでは優先度が下がっている場合もあるため、用語として知っておく程度）。
- スケジュールされたスケーリング … 決まった日時・繰り返しで希望キャパシティや最小／最大を変える。バッチ前のウォームアップ、営業時間帯のみ台数を増やす、など。
- 手動スケーリング … 希望キャパシティをオペレータが直接変更。
複数のポリシーを併用できます。典型的な運用例として、「スケジュールでベースラインを決め、閾値超過時は動的スケーリング」と説明されることがあります。
ヘルスチェックの選択（深掘り）
Auto Scaling が「インスタンスを健全とみなすか」は、ヘルスチェックの種類で挙動が変わります。
| 種類 | 検知しやすいもの | 検知しにくいもの |
|---|---|---|
| EC2 | インスタンスの停止、インプレース障害などハイパーバイザーが分かる状態 | アプリのハング、HTTP 500 だがプロセスは生きている、など |
| ELB | ターゲットグループのヘルスチェック（パス・ポート）に基づくアプリ層の異常 | EC2 自体のハード障害で ELB チェックが間に合わないケース（他の監視と併用） |
信頼性を優先する Web アプリでは ELB を選ぶ問題が多いです。誤答として「EC2 ステータスだけで十分」とする選択肢が出ます。
終了（ターミネーション）ポリシー
スケールイン時にどのインスタンスを止めるかを制御します。既定（デフォルト）では、おおざっぱに次のような観点が入ります。
- AZ 間の偏りを減らす … 片方の AZ だけ台数が多いと、そちらから終了候補が選ばれやすい。
- 古い起動テンプレート／設定のインスタンスを優先 … デプロイの一貫性のため。
- インスタンス保護 … 特定インスタンスに Scale-in protection を付けてスケールイン対象から外す、という運用も可能。
試験では「コスト削減で手早くスケールインしたいが、AZ の可用性を落としたくない」ときに終了ポリシーと最小キャパシティがセットで問われます。
クールダウン
スケーリング直後にすぐ次のスケーリングが走らないよう待つ時間です。メトリクスの収集遅延や、新インスタンスがヘルスチェック合格するまでのラグを考慮し、**振動（フラッピング）**を防ぎます。
一方で、スケジュールされたスケーリングや異常インスタンスの自動置換など、クールダウンを待たないケースもあります。細部は公式ドキュメントの該当節で確認してください。
AZ 間の再分散（rebalance）
インスタンス数が AZ 間で偏ると、少ない AZ に起動を追加したり、偏りの原因になったインスタンスを終了して別 AZ に立て直したりする再分散が行われます。最大キャパシティに張り付いていると再分散が進みにくいため、一時的に上限を上げる、という運用トピックが資料に出ます。
ライフサイクルフック
スケールアウトでインスタンスがInService になる前、スケールインで終了する前に、待機状態を挟みます。SNS、SQS、EventBridge などへ通知し、スクリプトや Lambda でアプリのウォームアップ、ログ・セッションの退避、ロードバランサー登録前のチェックなどを実行できます。
試験では「デプロイ時に必ず初期化スクリプトを走らせたい」という要件でライフサイクルフックが正解になることがあります。
インスタンスの手動終了とサスペンド
オペレータが手動でインスタンスを終了しても、Auto Scaling は希望キャパシティを維持しようとして別インスタンスを起動することがあります。障害調査で止めたいときは、グループのプロセスを一時停止する、希望キャパシティを下げる、など意図した手順が必要です。
よくある誤答（SAA）
- 「スケーリングポリシーは1つしか設定できない」→ 複数可。
- 「ターゲット追跡は CPU しか指定できない」→ メトリクスによりALB RequestCountPerTarget 等も指定可能（前提条件あり）。
- 「クールダウン中は一切スケールできない」→ 例外あり。
公式ドキュメント（深掘り）
重要ポイント
- ▸ターゲット追跡は目標メトリクスに追従。ステップはしきい値の超過幅で段階変更
- ▸スケジュールと動的スケーリングは併用可能（朝は固定・日中は追従など）
- ▸終了ポリシーはデフォルトでAZバランスや古い起動設定の置換を意識
- ▸クールダウンは連続スケールを抑制するが例外あり（スケジュール・置換など）
- ▸ライフサイクルフックで起動／終了前にスクリプトやLambdaを挟める
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
同じサービスの関連トピック
EC2 とコンピュート に関連するトピックを続けて確認できます。