※注意
この記事は僕がAIエージェントの勉強がてら作っています。内容はほぼお任せなので、あっているのかもよくわかりません。投稿時点では裏どりしてません（参考のサンプル問題のリンクも怪しい）し、試験に出るかもわかりません。という大変不誠実な投稿ですが、ご了承ください。
AWS EC2 Auto Scaling まとめ
EC2 Auto Scaling とは
EC2 Auto Scaling は、アプリケーションの負荷に応じて EC2 インスタンスを自動的に増減するサービスです。
主な役割は3つあります。
- 可用性の向上: 異常なインスタンスを自動検知して健全なインスタンスに置き換える
- コスト最適化: 不要なインスタンスをスケールインして無駄なコストを削減する
- 負荷対応: トラフィック増加時にインスタンスを追加してパフォーマンスを維持する
インスタンス群を管理する単位を Auto Scaling グループ（ASG） と呼び、「何台起動するか」を以下の3値で制御します。
最小キャパシティ ≤ 希望キャパシティ ≤ 最大キャパシティ
2 ≤ 4 ≤ 10
- 最小: 常時維持する下限（0も可）
- 希望: 現在 ASG が維持しようとしている台数。スケーリングにより変動する
- 最大: スケールアウトの上限。コストの青天井を防ぐ
「何を起動するか」は 起動テンプレート（AMI・インスタンスタイプ・セキュリティグループなど）に定義し、ASG に紐づけます。
試験で問われやすいポイント
スケーリングポリシーの使い分け
Auto Scaling のトリガーは5種類あり、状況に応じてどれを選ぶかが頻出問題です。
| 種類 | 動作 | 使いどころ |
|---|---|---|
| 手動 | Desired を直接変更 | 検証・メンテナンス |
| スケジュール | 指定した時刻に台数を変更 | 毎日決まった時間に負荷が変動する |
| ターゲット追跡 | 指定メトリクスを目標値に維持 | 最もシンプルで汎用的。推奨 |
| ステップ | メトリクスの範囲ごとに増減数を定義 | 段階的に細かく制御したい |
| シンプル | アラーム1件につき1アクション | 古い設計。現在はステップ推奨 |
| 予測スケーリング | ML で将来の負荷を予測して事前にスケール | 週次など周期的なパターンがある |
ターゲット追跡スケーリングは ALBRequestCountPerTarget（ターゲット当たりのリクエスト数）を使うと、ALB と連携したスケーリングが可能です。
クールダウンの違い（シンプル vs ステップ）
試験で紛らわしいのがクールダウン中の挙動の違いです。
- シンプルスケーリング: クールダウン中にアラームが発火しても無視する
- ステップスケーリング: クールダウン中でも追加でスケールできる → 急激な負荷増加に強い
ヘルスチェックの種類と違い
Unhealthy と判定されたインスタンスは自動的に終了・置き換えされます。
| 種類 | 検知範囲 | 備考 |
|---|---|---|
| EC2（デフォルト） | ハードウェア障害など AWS インフラレベル | アプリの異常は検知できない |
| ELB | ALB/NLB のヘルスチェック結果を利用 | アプリレベルの異常も検知。本番推奨 |
| カスタム | 任意のロジックで API から通知 | 独自の監視と組み合わせる場合 |
よく出るひっかけ: デフォルトの EC2 ヘルスチェックではアプリがハングしていても検知できません。アプリの自動復旧を実現するには ELB ヘルスチェックへの切り替えが必要です。
また health-check-grace-period（ヘルスチェック猶予期間）を短く設定しすぎると、アプリ起動中のインスタンスが Unhealthy と判定され、終了→再起動のループが発生します。
ライフサイクルフック
インスタンスの起動・終了のタイミングに処理を挟む機能です。
【スケールアウト】
起動 → Pending:Wait →（初期化・設定取得など）→ CONTINUE → InService
【スケールイン】
InService → Terminating:Wait →（ログ保存・セッションドレインなど）→ CONTINUE → 終了
- タイムアウトはデフォルト 1時間（最大 48 時間）
- タイムアウト前に
complete-lifecycle-actionを呼ばないとdefault-result（CONTINUE or ABANDON）が自動適用される - 試験頻出パターン: EventBridge や SQS でフックを受け取り → Lambda で処理 → ASG に完了通知
起動テンプレート vs 起動設定
起動設定（Launch Configuration）は非推奨です。試験でも「どちらが推奨か」という問いで登場します。
| 機能 | 起動テンプレート | 起動設定 |
|---|---|---|
| バージョン管理 | ○ | ✗ |
| スポット＋オンデマンド混在 | ○ | ✗ |
| IMDSv2 対応 | ○ | ✗ |
| 今後の新機能追加 | ○ | ✗（凍結） |
コスト最適化（混合インスタンスポリシー）
スポットインスタンスとオンデマンドを組み合わせることで、最大 90% のコスト削減が可能です。
OnDemandBaseCapacity = 2 # 最低限オンデマンドで確保する台数
OnDemandPercentageAboveBase = 20 # それ以上はスポット 80% / オンデマンド 20%
SpotAllocationStrategy = price-capacity-optimized ← AWS 推奨
スポット割り当て戦略は price-capacity-optimized（価格と空き容量のバランスを取る）が推奨です。lowest-price は中断リスクが高く、試験では「中断を最小化したい」シナリオでは不正解になりやすいです。
まとめ：シナリオ別の正解パターン
| シナリオ | 正解の選択肢 |
|---|---|
| アプリが落ちているのに Auto Scaling が検知しない | ELB ヘルスチェックを有効化する |
| 起動直後に Unhealthy 判定されて置き換えループ |
health-check-grace-period を延長する |
| 急激な負荷増加に素早く対応したい | ステップスケーリング（クールダウン中も追加スケール可） |
| 夜間にインスタンスを減らしてコストを削減 | スケジュールスケーリング |
| 終了前にログをS3に退避させたい | ライフサイクルフック（Terminating:Wait）+ Lambda |
| スポットを活用してコストを下げたい | 混合インスタンスポリシー + price-capacity-optimized |
| 起動設定を使っている既存の ASG の改善 | 起動テンプレートへ移行する |