SAA Auto Scaling と ELB の組み合わせ問題｜ヘルスチェックタイプ・スケーリングポリシー・ライフサイクルフックを要件文で即断する
AWS SAA-C03 で Auto Scaling と ELB（ALB/NLB）の組み合わせは、可用性・弾力性設計の中核として頻出する。本記事は Auto Scaling × ELB 問題を「ロードバランサの選択／ASG と ELB の連携とヘルスチェックタイプ／スケーリングポリシー（ターゲット追跡・ステップ・簡易・スケジュール・予測）／Multi-AZ 分散とライフサイクルフック・終了ポリシー・コスト最適化」の頻出10パターンに分解する。最頻出の地雷であるヘルスチェックタイプ（EC2 か ELB か）を軸に、要件文のどのキーワードが正解を一意に決めるかを示す。結論は「Auto Scaling × ELB 問題は暗記ではなく、分散・増減・健全性判定・安全な入れ替えという4つの評価軸で解く」こと。
Auto Scaling と ELB の組み合わせ問題を「負荷が増えたらサーバーを増やす仕組み」で片づけようとすると、ヘルスチェックのタイプ・スケーリングポリシーの選択・AZ 間の分散・安全な入れ替えで足をすくわれる。 SAA-C03 で EC2 Auto Scaling と Elastic Load Balancing は、配点26%のドメイン2（弾力性のある設計）と配点24%のドメイン3（高パフォーマンス設計）の両方で顔を出す最重要ペアだ。だが問われるのは「サービスの機能暗記」ではなく、どう負荷を分散するのか・いつインスタンスを増減するのか・どう健全性を判定するのか・どう安全に入れ替えるのかという設計判断である。攻略の鍵は、頻出テーマを「ロードバランサの選択」「ASG と ELB の連携とヘルスチェック」「スケーリングポリシー」「AZ 分散と入れ替え・コスト」の4系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、Auto Scaling × ELB 問題の頻出10パターンを分解する。読み終えれば、「最も可用性が高く、かつコスト効率よく需要変動に追従する構成はどれか」という問いに、迷わず正解を当てられるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：Auto Scaling × ELB 問題は「4つの評価軸」で解く
- パターン1〜2：ロードバランサの選択と ASG との連携
- パターン3：ヘルスチェックタイプ（EC2 か ELB か）の最頻出の罠
- パターン4〜6：スケーリングポリシー（ターゲット追跡・ステップ・スケジュール・予測）
- パターン7〜8：Multi-AZ 分散とライフサイクルフック
- パターン9〜10：終了ポリシーとコスト最適化（スポット混在）
- 頻出ひっかけパターンと打ち手の整理
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：Auto Scaling × ELB 問題は「4つの評価軸」で解く
SAA-C03 の Auto Scaling × ELB 問題を最短で解く骨格は、**「要件文が4つの評価軸——どう分散するか・いつ増減するか・どう健全性を判定するか・どう安全に入れ替えるか——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。
理由は明快で、この構成の登場人物はどれも「ある評価軸を制御するための道具」だからだ。ALB / NLB の選択は「どう分散するか」を、スケーリングポリシー（ターゲット追跡・ステップ・スケジュール）は「いつ増減するか」を、ヘルスチェックタイプ（EC2 / ELB）は「どう健全性を判定するか」を、ライフサイクルフック・終了ポリシー・AZ 分散は「どう安全に入れ替えるか」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の設定を一意に決める構造になっている。
具体例で見よう。「HTTP のパスによって振り分けたい」——分散の軸だから ALB。「CPU 使用率を一定に保ちたい」——増減の軸だから ターゲット追跡スケーリング。「アプリは正常だが ELB からは異常と見えるインスタンスが放置される」——健全性判定の軸だから ヘルスチェックタイプを ELB に変更。「起動直後にログを退避してから終了させたい」——安全な入れ替えの軸だから ライフサイクルフック。ここで「Auto Scaling を付ければ勝手に良い感じになる」と考えると、ヘルスチェックタイプやスケーリングポリシーを問う設問で誤答する。軸で解く——この一点が Auto Scaling × ELB 問題の攻略法だ。
2. パターン1〜2：ロードバランサの選択と ASG との連携
パターン1：ALB・NLB・GWLB の選択
Auto Scaling の前段に置くロードバランサは、何を分散するかで一意に決まる。
- HTTP/HTTPS で、パスやホストで振り分け → ALB：L7 で動作し、
/api/*は API サーバー、/img/*は画像サーバー、とパスベース・ホストベースのルーティングができる。Web アプリの標準解。 - 超低レイテンシ・高スループット、TCP/UDP、固定 IP → NLB：L4 で動作し、数百万リクエスト/秒をさばく。固定 IP（Elastic IP）が必要な要件、非 HTTP プロトコルなら NLB。
- サードパーティ製アプライアンス（FW/IDS）を透過的に挟む → GWLB：L3 で仮想アプライアンスへトラフィックを流す特殊用途。
パターン2：ASG と ELB の連携（ターゲットグループへの自動登録）
Auto Scaling グループ（ASG）に ターゲットグループをアタッチしておくと、スケールアウトで起動したインスタンスは自動的にターゲットグループへ登録され、ELB がトラフィックを流し始める。スケールインで終了するインスタンスは自動的に登録解除される。「増えたサーバーを手動で LB に追加する必要はない」——これが連携の本質だ。
3. パターン3：ヘルスチェックタイプ（EC2 か ELB か）の最頻出の罠
Auto Scaling × ELB 問題で最も出題頻度が高く、最も間違えやすいのがこのパターンだ。単独のセクションとして押さえたい。
ASG のヘルスチェックタイプには2種類ある。
- EC2 ヘルスチェック（デフォルト）：EC2 のステータスチェック（ハードウェア・システムの健全性）だけを見る。OS は起動しているがアプリ（Web サーバー）が落ちている状態は「正常」と判定してしまう。
- ELB ヘルスチェック：ELB がターゲットに対して行うアプリケーション層のヘルスチェック（例：
/healthに HTTP 200 が返るか）の結果も、ASG が健全性判定に使う。
あわせて ヘルスチェックの猶予期間（Health Check Grace Period） も押さえたい。インスタンス起動直後はアプリ初期化中でヘルスチェックに失敗しがちなので、猶予期間（デフォルト300秒）を設けて起動途中のインスタンスを誤って終了しないようにする。「起動と終了を無限に繰り返す（フラッピング）」という設問は、猶予期間が短すぎることを疑う。
4. パターン4〜6：スケーリングポリシー（ターゲット追跡・ステップ・スケジュール・予測）
「いつ増減するか」を決めるのがスケーリングポリシーだ。要件語で使い分ける。
パターン4：ターゲット追跡スケーリング（推奨・デフォルト解）
「CPU 使用率を平均50%に保ちたい」のように、1つのメトリクスに目標値を設定するだけで、AWS が自動でインスタンス数を増減してその値を維持する。CloudWatch メトリクスとサーモスタットのような関係だ。設定が最もシンプルで、AWS も推奨する。「特に細かい条件が書かれておらず、指標を一定に保ちたい」なら、まずターゲット追跡を選ぶ。
パターン5：ステップスケーリング・簡易スケーリング
「CPU 70%超で2台、90%超で4台追加、というように段階的に増やしたい」——これはステップスケーリングだ。CloudWatch アラームのしきい値ごとに追加台数を刻める。簡易スケーリング（Simple Scaling）は1段階だけの旧方式で、クールダウン完了まで次のアクションを待つため反応が鈍い。新規設計ではステップスケーリング以降を選ぶのが定石。
パターン6：スケジュールスケーリングと予測スケーリング
| 評価項目 | ターゲット追跡 推奨 | ステップ | スケジュール | 予測 |
|---|---|---|---|---|
| 本質 | 指標を目標値に維持 | しきい値ごとに段階増減 | 時刻指定で増減 | 過去実績から先読み |
| 代表用途 | CPU 50% を維持 | 負荷段階に応じ台数調整 | 毎朝9時にバッチ増強 | 周期的な需要に事前対応 |
| キーワード | 「一定に保つ」「シンプル」 | 「段階的に」「複数しきい値」 | 「毎日◯時」「決まった時間」 | 「予測」「周期的パターン」 |
5. パターン7〜8：Multi-AZ 分散とライフサイクルフック
パターン7：複数 AZ への分散と可用性
ASG は複数のアベイラビリティゾーン（AZ）にまたがってインスタンスを配置できる。これが可用性設計の要だ。
- ASG に複数 AZ のサブネットを指定 → AZ 障害時も残り AZ で稼働継続：1つの AZ が落ちても、ELB は健全な AZ のインスタンスへ振り分ける。
- AZ 間の均等化（AZ Rebalancing）：ASG は各 AZ のインスタンス数が偏らないよう自動で均す。「片方の AZ にインスタンスが偏る」問題は ASG が是正する。
- 単一 AZ 構成は誤答：「高可用性」が要件なら、必ず複数 AZ にまたがる ASG＋ELB を選ぶ。詳しくは高可用性設計のパターン集で深掘りしている。
パターン8：ライフサイクルフック
「スケールインで終了する前にログを S3 へ退避したい」「起動後にアプリ設定を流し込んでからサービスインしたい」——これはライフサイクルフックだ。インスタンスの起動時（Pending:Wait）や終了時（Terminating:Wait）に一時停止させ、その間にカスタム処理（Lambda や SSM 経由）を挟める。デフォルトで最大1時間待機し、処理完了を通知すると次の状態へ遷移する。
6. パターン9〜10：終了ポリシーとコスト最適化（スポット混在）
パターン9：終了ポリシー（どのインスタンスから減らすか）
スケールインの際、どのインスタンスを終了するかを制御するのが終了ポリシーだ。デフォルトは「最も古い起動設定/テンプレートのインスタンス」や「次の課金時間に最も近いもの」を優先して終了し、AZ バランスを保つ。「古い AMI のインスタンスから入れ替えたい（ローリング更新的に）」なら OldestInstance、「コスト無駄を減らしたい」なら課金時間ベース、と要件語で選ぶ。
パターン10：スポット + オンデマンド混在によるコスト最適化
| 評価項目 | オンデマンドのみ | スポット + オンデマンド混在 推奨 | スポットのみ |
|---|---|---|---|
| 本質 | 安定・割高 | ベース保証＋割安上乗せ | 最安・中断リスク |
| 代表用途 | 常時安定が最優先 | ベースはオンデマンド・急増分はスポット | ステートレス・中断許容 |
| キーワード | 「中断不可」「安定」 | 「コスト削減しつつ可用性」 | 「最安」「中断してよい」 |
7. 頻出ひっかけパターンと打ち手の整理
Auto Scaling × ELB 問題は、正しい打ち手と“やりがちな誤答”が明確に対になっている。表で押さえれば本番で機械的に振るえる。
8. 次のアクション チェックリスト
Auto Scaling × ELB 設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。
9. 関連記事
- SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本シリーズの上位ガイド
- SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
- SAA ドメイン2：弾力性のあるアーキテクチャの設計 — Auto Scaling が主役のドメイン
- SAA ドメイン3：高パフォーマンスアーキテクチャの設計 — 水平スケールの性能軸
- SAA 高可用性設計のパターン集（Multi-AZ / Multi-Region） — Multi-AZ と自動置換の上位
- SAA VPC 設計問題の頻出パターン10選 — サブネットと AZ 分散の隣接テーマ
- EC2 Auto Scaling の仕組みと設定方法 — Auto Scaling の基礎
- Elastic Load Balancing（ALB・NLB・CLB）完全比較 — ロードバランサ選択の詳細
- Application Load Balancer（ALB）の使い方 — L7 ルーティングの詳細
- Network Load Balancer（NLB）の使い方 — L4・固定 IP の詳細
- EC2 スポットインスタンスの活用 — 混在ポリシーのコスト最適化
- CloudWatch Metrics・Logs・Alarms の基本 — スケーリングの発火条件
10. 関連サイト
AWS 公式
- Amazon EC2 Auto Scaling ユーザーガイド（公式）
- Auto Scaling グループのヘルスチェック（公式）
- ターゲット追跡スケーリングポリシー（公式）
- Auto Scaling ライフサイクルフック（公式）
- Elastic Load Balancing の仕組み（公式）
- AWS Certified Solutions Architect – Associate（公式）
- SAA-C03 試験ガイド（公式 PDF）