はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Auto Scaling Group (ASG) 関連の知識をまとめました。
スケーリングポリシーの選び方から、スケールイン時の終了順序、高可用性のキャパシティ計算まで、試験で問われやすいポイントを網羅しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
スケーリングポリシー
| ポリシー | 予測的 | リアルタイム | 主な用途 |
|---|---|---|---|
| Predictive | ✅（ML予測） | ❌ | 予測可能なパターン（事前スケール） |
| Target Tracking | ❌ | ✅ | メトリクスをターゲット値に維持 |
| Step Scaling | ❌ | ✅ | 閾値ベースの段階的スケール |
| Simple Scaling | ❌ | ✅（遅い） | 単一アクション + クールダウン |
| Scheduled Action | △ | ❌ | 固定時間のスケール |
試験では「どのスケーリングポリシーを使うか？」がよく問われます。判断のポイントは、予測可能か突発的か、時間ベースかメトリクスベースか、スパイクへの応答速度が求められるか の3つです。
デフォルト終了ポリシー（優先順位）
スケールイン時に「どのインスタンスが終了されるか」はデフォルト終了ポリシーで決まります。優先順位は次のとおりです。
- On-Demand vs Spot のアロケーション戦略
- Launch Configuration を使うインスタンスが優先的に終了（Launch Template より先）
- 最古の Launch Configuration / Template のインスタンス
- 次の課金時間に最も近いインスタンス（最後）
特に「Launch Configuration と Launch Template が混在している場合、Launch Configuration 側が先に終了される」という点は試験で問われやすいポイントです。
スケールイン時のフロー
実際のスケールイン処理は、以下の順序で進みます。
- インスタンス数が最も多い AZ から終了（AZ 間バランスを維持するため）
- アロケーション戦略
- 最古の Launch Template / Configuration
- 課金時間
ヘルスチェックタイプ
| タイプ | 判定基準 |
|---|---|
| EC2（デフォルト） | インスタンス状態（running / stopped） |
| ELB | ALB / NLB のヘルスチェック結果 |
ALB + ASG 構成では、ASG のヘルスチェックタイプを ELB ベースに明示的に変更するのが推奨です。デフォルトの EC2 ヘルスチェックのままだと、ALB が unhealthy と判定してもASGは気づかず、インスタンスが置換されません。
ASG がインスタンスを終了しない主な理由
ASG が unhealthy なインスタンスを終了しないケースには、いくつかの原因があります。
- Grace Period が未満了（起動直後はヘルスチェックが猶予される）
- Impaired 状態（回復を待っている）
- ヘルスチェックタイプの不一致（ASG が EC2 タイプなのに、ALB のヘルスチェックで unhealthy になっている）
- Standby 状態のインスタンス
- ReplaceUnhealthy プロセスが Suspended になっている
SQS キュー長に基づくスケーリング
SQS のキューの深さに応じてスケールしたい場合は、Target Tracking Policy + カスタムメトリクス を使います。
カスタムメトリクスは ApproximateNumberOfMessages ÷ InService インスタンス数（= backlog per instance）で算出します。
混合インスタンスポリシー
ASG では複数の購入オプション・インスタンスタイプを組み合わせることができます。
- ベースライン → Reserved Instances
- スパイク → Spot 優先、Spot が確保できない場合は On-Demand にフォールバック
高可用性の最小キャパシティ計算
「1つの AZ が障害で失われても、通常のワークロードを処理できる台数を維持する」という考え方です。
- 必要台数 × AZ 数 で計算する
- 例: 通常2台必要で、1AZ 障害に耐える場合 → 最小4台（2AZ × 2台）
- ASG は AZ 間で均等に分散配置する
試験で問われる設計パターン
SAA の試験では「こういう要件のとき、どのスケーリング戦略・構成を選ぶか？」というシナリオ問題が出題されます。ここからは、ASG に関連する頻出シナリオを 「どんな状況で → 何を選ぶか → なぜか」 の形式で整理していきます。
スケーリングポリシー系
予測可能なピーク時間にスケールアウト → Scheduled Action + desired capacity
シナリオ: 毎月末の特定時間帯に EC2 が10台必要になります（通常は2台）。事前に分かっているこのピークに対応するには、どのスケーリング方法が最適でしょうか？
正解: Scheduled Action で desired capacity を 10 に設定
- 発生時間が分かっている → Scheduled Action（時間ベース）
- 正確なインスタンス数が決まっている → desired capacity を指定
- Target Tracking や Simple Scaling は時間ベースのスケーリングには向かない
SQS キュー長に基づく Auto Scaling → Target Tracking + カスタムメトリクス
シナリオ: SQS キューにメッセージが溜まったらワーカーの EC2 を増やし、キューが空になったら減らしたいです。最も適切なスケーリングポリシーはどれでしょうか？
正解: Target Tracking + backlog per instance メトリクス
- Simple Scaling はクールダウン期間があり、スパイクへの対応が遅れる
- Scheduled は突発的なスパイクに対応できない
- Step Scaling でも近い動作は可能だが、Target Tracking の方が正確にターゲット値を追従する
終了ポリシー系
デフォルト終了ポリシーの優先順位を問う問題
シナリオ: ASG に以下のインスタンスがあります。スケールインで1台終了する場合、どれが先に終了されるでしょうか？
- A: 最古の Launch Template で起動
- B: 最古の Launch Configuration で起動
- C: 最新の Launch Configuration で起動
- D: 次の課金時間に最も近い
正解: Instance B（最古の Launch Configuration）
- Launch Configuration を使っているインスタンスは、Launch Template より優先的に終了される
- 同じ Launch Configuration 同士なら「最古」が先
- 「次の課金時間」は最後の判定基準
AZ 間バランスを考慮したスケールイン
シナリオ: AZ-A に3台、AZ-B に4台のインスタンスがある ASG でスケールインが発生します。どのインスタンスが終了されるでしょうか？
正解: AZ-B（インスタンス数が多い方）から、最古の Launch Template / Configuration を持つインスタンスが終了
- Step 1: AZ 間のバランスを取るため、インスタンス数が多い AZ から終了
- Step 2 以降: 通常の終了ポリシー（アロケーション戦略 → 最古の Launch Template/Configuration → 課金時間）
高可用性 + コスト最適化系
HA + スケール + コスト最適の ASG 設定
シナリオ: 3つの AZ にまたがる ASG を構成しています。アイドル時間もあります。高可用性を維持しつつ、スケールもでき、コストも最適化したい場合、最小キャパシティと購入オプションはどうすべきでしょうか？（2つ選択）
正解:
- 最小キャパシティ = 2（2つの AZ に1台ずつ）
- 最小キャパシティ分を Reserved Instances で確保
- 3AZ でも最小2台で十分な HA を確保できる（1AZ 障害時に ASG が3つ目の AZ に自動配置）
- 常時稼働する分は RI、スパイク分は On-Demand / Spot で対応
クリティカルアプリ + 高可用性 → 最小4台（2AZ × 2台）
シナリオ: クリティカルなアプリケーションを ASG で運用しています。通常時は2台でワークロードを処理でき、ピーク時は最大6台まで拡張します。信頼性が極めて重要な場合、最小・最大キャパシティはどう設定すべきでしょうか？
正解: 最小4台（2AZ × 2台）、最大6台
- 1AZ が障害で失われても通常の2台を維持するには、各 AZ に2台ずつ必要 → 最小4台
- 最小2台では、1AZ 障害時に1台しか残らず、通常のワークロードを処理できない
- ASG はリージョンをまたげない点にも注意
ヘルスチェック系
ALB が unhealthy と判定するが直接アクセスは可能
シナリオ: ALB 配下の EC2 インスタンスが unhealthy と表示されますが、EC2 に直接アクセスするとアプリケーションは正常に動作しています。原因として考えられるものを2つ選んでください。
正解:
- EC2 のセキュリティグループが ALB のセキュリティグループからのトラフィックを許可していない
- ヘルスチェックのルートが誤って設定されている
- 直接アクセスは OK なのに ALB 経由で unhealthy → ネットワーク経路（SG） か ヘルスチェック設定 の問題
- EBS やランタイムの問題であれば直接アクセスでも異常が出るはず
ASG が unhealthy インスタンスを終了しない理由
シナリオ: ALB は一部のインスタンスを unhealthy と判定してトラフィックから除外していますが、ASG がそのインスタンスを新しいものに置換してくれません。考えられる原因を3つ選んでください。
正解:
- Grace Period がまだ満了していない
- インスタンスが Impaired 状態（回復待ち）
- ELB ヘルスチェックが失敗しているが、ASG のヘルスチェックタイプが EC2 に設定されている
- ASG のデフォルトは EC2 ヘルスチェックなので、ELB ベースに明示的に変更しないと ALB の判定結果が反映されない
- Spot インスタンスでもヘルスチェック失敗時は終了対象になる
- カスタムヘルスチェックで
SetInstanceHealthAPI を呼べば手動で終了させることも可能
ALB が unhealthy を除外するが ASG が置換しない → ヘルスチェックタイプの不一致
シナリオ: ALB + ASG 構成で運用しています。ALB は一部のインスタンスを unhealthy としてトラフィックから除外しましたが、ASG はそのインスタンスを healthy とみなしたまま置換しません。何が原因でしょうか？
正解: ASG のヘルスチェックタイプが EC2 に設定されており、ALB のヘルスチェック結果を参照していない
- ALB は独自の HTTP ヘルスチェックしか使えない（EC2 ベースのヘルスチェックは使えない）
- ASG は EC2 / ELB ベースを選択できる
- ASG + ALB 構成では、ASG のヘルスチェックタイプを ELB ベースに変更すべき
おわりに
ASG は EC2 と密接に関連しており、スケーリングポリシーの選択・終了ポリシーの理解・ヘルスチェックの設定が試験で頻出します。特に「ヘルスチェックタイプの不一致」と「高可用性の最小キャパシティ計算」は見落としがちなので、しっかり押さえておくと試験で差がつきます。
間違いや補足があればぜひコメントで教えてください。