Amazon EC2 Auto Scaling を中心に、設計・スケーリングポリシー・ヘルスチェック・コスト・デプロイ・運用の観点で押さえるべきポイントをまとめる。ECS / DynamoDB / Aurora などの Application Auto Scaling にも共通する考え方は随時補足する。
目次
- 設計の基本方針
- スケーリングポリシーの選び方
- ウォームアップ・クールダウン・ライフサイクル
- ヘルスチェック
- コスト最適化
- デプロイと更新
- スケールインの制御
- セキュリティ・ガバナンス
- 監視と運用
- Application Auto Scaling（EC2 以外）の補足
- チェックリスト
1. 設計の基本方針
1.1 ステートレスなアプリケーションにする
- インスタンスはいつ終了されても問題ない前提で設計する（「ペット」ではなく「家畜」）。
- セッション情報は ElastiCache / DynamoDB などの外部ストアへ。
- ログはローカルに溜めず CloudWatch Logs / S3 などへ即時転送する。
- アップロードファイルや一時データは S3 / EFS に置く。
1.2 マルチ AZ 構成
- Auto Scaling グループ (ASG) には 最低 2〜3 つの AZ のサブネット を指定する。
- AZ 障害時に残りの AZ で必要容量を賄えるよう、
最小キャパシティ と最大値に余裕を持たせる（例: 3 AZ 構成なら 1 AZ 喪失時でも 2/3 で耐えられるか）。
- AZ リバランシングが走ることを前提にし、終了されても問題ない作りにする。
1.3 起動テンプレートを使う
- 起動設定（Launch Configuration）は非推奨。新規アカウントでは利用できないため、必ず起動テンプレート（Launch Template）を使う。
- 起動テンプレートはバージョン管理し、ASG からは
$Latest / $Default または明示的なバージョンを参照する（本番は明示バージョンか $Default で変更を制御するのが安全）。
- AMI ID は直接書かず、SSM パラメータ参照（例:
resolve:ssm:/aws/service/...）で最新 AMI を解決する方法も有効。
- IMDSv2 を必須（
HttpTokens: required）に設定する。
1.4 起動を速くする
- スケールアウトの効果は「インスタンスがトラフィックを受けられるまでの時間」で決まる。
- ゴールデン AMI（EC2 Image Builder 等で事前にミドルウェア・アプリを焼き込み）を使い、User Data での重い処理を避ける。
- 初期化に時間がかかるワークロードは ウォームプール を検討する（後述）。
- コンテナの場合はイメージサイズの削減、イメージのプリフェッチを検討する。
2. スケーリングポリシーの選び方
| ポリシー | 適するケース | ポイント |
|---|
| ターゲット追跡 (Target Tracking) | ほとんどのケースの第一選択 | 指標と目標値を決めるだけ。スケールイン/アウトを自動調整 |
| ステップスケーリング | 閾値ごとに増減量を細かく変えたい | アラームの段階設計が必要 |
| シンプルスケーリング | 原則使わない | クールダウン中は次のアクションが動かない |
| スケジュールスケーリング | 時間帯で負荷が予測できる | 営業時間・バッチ・イベント前の事前拡張 |
| 予測スケーリング (Predictive) | 日次・週次の周期性がある | 機械学習で需要を予測し事前にキャパシティ確保 |
2.1 ターゲット追跡を基本にする
- まずはターゲット追跡から始め、足りない部分を他のポリシーで補う。
- 指標の選び方:
- CPU バウンド →
ASGAverageCPUUtilization（目標 40〜70% 程度から調整）
- Web/API →
ALBRequestCountPerTarget（1 台あたり処理可能なリクエスト数を負荷試験で把握）
- キュー処理 → SQS の「インスタンスあたりのバックログ数」をカスタムメトリクスとして算出して追跡
- 指標は負荷に比例して増減するもの を選ぶ（メモリ使用率のように負荷と比例しにくい指標は不向きな場合がある）。
- 目標値は低すぎるとコスト増、高すぎるとスパイクに耐えられない。負荷試験で決める。
- 急峻なスパイクがある場合は、高解像度（1 分未満）メトリクスを使った応答性の高いターゲット追跡も検討する。
2.2 複数ポリシーの組み合わせ
- 複数ポリシーが同時に発火した場合、最も大きなキャパシティを要求するもの が優先される（スケールアウト優先）。
- 典型的な組み合わせ:
- 予測スケーリング + ターゲット追跡: 周期的な負荷は予測で先回り、予測外の変動はターゲット追跡で吸収。
- スケジュール + ターゲット追跡: キャンペーン開始前に最小キャパシティを引き上げておく。
2.3 予測スケーリング
- 最初は 「予測のみ（ForecastOnly）」モード で精度を評価してから「予測とスケール」に切り替える。
- 学習には最低 24 時間、精度を出すには 2 週間程度の履歴があるとよい。
- 起動に時間がかかる場合は
SchedulingBufferTime（事前起動のバッファ）を設定する。
- 周期性がない・急激な突発負荷が主なワークロードには向かない。
2.4 スケールインは慎重に、スケールアウトは素早く
- スケールアウトは早めに、スケールインは緩やかに（非対称）するのが基本。
- ステップスケーリングではスケールイン側の評価期間を長めにとる。
- 頻繁な増減（フラッピング）が起きる場合は、目標値・評価期間・ウォームアップ時間を見直す。
3. ウォームアップ・クールダウン・ライフサイクル
3.1 デフォルトインスタンスウォームアップを設定する
- ASG 単位の Default instance warmup を有効化する。起動直後でメトリクスが安定しないインスタンスを、集計から一定時間除外できる。
- 値はアプリが実際にトラフィックを受けられるまでの時間（ヘルスチェック合格までの時間 + α）を目安にする。
- 未設定だとスケールアウト直後の低い CPU 値に引っ張られて過剰なスケールイン/アウトが起きやすい。
3.2 ライフサイクルフックを活用する
- 起動時フック: 設定投入・ソフトウェアのインストール・サービス登録などの完了を待ってから InService にする。
- 終了時フック: ログの退避、処理中ジョブのドレイン、サービスディスカバリからの登録解除などを行う。
- タイムアウト（ハートビート）とデフォルトアクション（CONTINUE / ABANDON）を適切に設定する。
- EventBridge + Lambda / SSM Automation で処理を自動化し、完了時に
complete-lifecycle-action を呼ぶ。
3.3 ウォームプール
- 初期化に数分以上かかるアプリでは、停止状態（Stopped）や休止状態（Hibernated）で事前初期化済みのインスタンスをプール しておくと、スケールアウトを大幅に短縮できる。
- Stopped 状態ならインスタンス料金はかからず、EBS 料金のみ。
- 混合インスタンスポリシーの ASG や EKS マネージドノードグループでも利用可能になっている。
- ウォームプール内のインスタンスにもライフサイクルフックが効くので、「プールに入る時」の初期化処理を設計しておく。
4. ヘルスチェック
- ロードバランサー配下では ELB ヘルスチェックを有効化 する（デフォルトの EC2 ステータスチェックだけではアプリ障害を検知できない）。
- ヘルスチェックの猶予期間（Health check grace period）は起動〜アプリ準備完了までの時間に合わせる。短すぎると起動中に Unhealthy 判定され、置き換えループに陥る。
- ヘルスチェック用エンドポイントは 軽量かつ自身の健全性を反映 するものにする。依存先（DB 等）の障害で全台 Unhealthy にならないよう、深いチェックと浅いチェックを使い分ける。
- 必要に応じて EBS ヘルスチェックや VPC Lattice のヘルスチェックも活用する。
- 独自の判定ロジックがある場合は
SetInstanceHealth API で Unhealthy をマークし置き換えさせる。
5. コスト最適化
5.1 混合インスタンスポリシー + スポット
- 複数のインスタンスタイプ を指定し、容量不足や価格変動への耐性を上げる。
- 属性ベースのインスタンスタイプ選択（vCPU・メモリ範囲で指定）を使うと、新世代タイプも自動で候補に入る。
- オンデマンドのベース容量 + スポットの比率を設定する（例: ベース 2 台はオンデマンド、それ以上はスポット 70%）。
- スポットの配分戦略は
price-capacity-optimized を推奨（中断リスクと価格のバランスが良い）。
- Capacity Rebalancing を有効化し、中断リスクが高まったスポットを事前に置き換える。
- スポットはステートレスかつ中断耐性のあるワークロードに限定する。
5.2 適正なサイズとキャパシティ
- 最小キャパシティを過大にしない（スケジュールで夜間・週末は下げる）。
- 最大キャパシティは「暴走時のコスト上限」としても機能するので必ず妥当な値にする。
- Compute Optimizer の推奨を定期的に確認し、インスタンスタイプを見直す。
- 定常部分は Savings Plans / リザーブドインスタンスでカバーし、変動部分を Auto Scaling + スポットで賄う。
- Graviton（Arm）インスタンスが使えるならコスト性能比の向上を検討する。
5.3 キャパシティ確保が重要な場合
- 確実に起動させたいワークロードは On-Demand Capacity Reservations と組み合わせる。
- 「予約を優先し、その後 AZ バランス」の配分戦略なども活用できる。
6. デプロイと更新
6.1 インスタンスの更新（Instance Refresh）
- AMI や起動テンプレートを更新したら Instance Refresh でローリング置き換えを行う。
MinHealthyPercentage / MaxHealthyPercentage で可用性と速度のバランスを調整する（例: 90% / 110% で追加起動してから置き換え）。- チェックポイント を設定して段階的に進め、途中で検証する。
- 自動ロールバック と CloudWatch アラーム連携を有効化し、異常時に自動で元に戻す。
- 「スキップマッチング」を有効にすると、すでに目的の設定のインスタンスは置き換え対象外になる。
- 緊急時は進行中の更新を強制キャンセルできる。
- ルートボリューム置き換え（ReplaceRootVolume）戦略を使えば、インスタンスを停止せずにルート EBS を差し替える方式も選べる。
6.2 Blue/Green
- 大きな変更やすぐに切り戻したい場合は、ASG ごと入れ替える Blue/Green（CodeDeploy や ALB の重み付けターゲットグループ）を検討する。
6.3 インフラのコード化
- ASG・起動テンプレート・ポリシーは CloudFormation / CDK / Terraform で管理する。
- IaC で
DesiredCapacity を固定値で管理すると、デプロイのたびにスケール状態が上書きされる問題が起きるため、指定しない・または無視する設定にする。
7. スケールインの制御
- 終了ポリシー を明示する（例:
OldestLaunchTemplate → OldestInstance、スポットを優先的に終了 など）。必要ならカスタム終了ポリシー（Lambda）も使える。
- 長時間ジョブを処理中のインスタンスは スケールイン保護（Instance Scale-in Protection） を動的に付け外しする。
- ALB の登録解除遅延（Deregistration delay）を適切に設定し、処理中リクエストをドレインしてから終了させる。
- 一時的に調査したいインスタンスは スタンバイ 状態に移す、またはプロセス（
Terminate / ReplaceUnhealthy など）を一時停止する。
8. セキュリティ・ガバナンス
- インスタンスには必要最小限の権限の IAM インスタンスプロファイル を付与する。
iam:PassRole の範囲を絞り、起動テンプレート経由で過剰な権限ロールを渡せないようにする。- 本番 ASG は 削除保護 を設定し、IAM ポリシーの条件キー（強制削除の制御など）で誤削除を防ぐ。
- Auto Scaling のサービスリンクロールが KMS 暗号化 EBS のキーを使えるよう、キーポリシーを確認する。
- タグを起動インスタンスに伝播（
PropagateAtLaunch）させ、コスト配分・運用管理に使う。
9. 監視と運用
- ASG グループメトリクス（
GroupDesiredCapacity, GroupInServiceInstances, GroupPendingInstances など）を有効化し、CloudWatch で可視化する。
- スケーリングアクティビティの失敗（キャパシティ不足、起動テンプレート誤り、クォータ超過）を EventBridge で通知する。
- 最大キャパシティ到達を監視し、到達したらアラートを出す（上限張り付きは性能劣化の兆候）。
- EC2 のサービスクォータ（vCPU 上限）を定期的に確認し、ピーク時に不足しないようにする。
- 定期的に 負荷試験 を実施し、目標値・ウォームアップ時間・最大キャパシティが妥当か検証する。
- AZ 障害やインスタンス大量終了を想定したカオステスト（AWS FIS）で回復性を確認する。
10. Application Auto Scaling（EC2 以外）の補足
| 対象 | ポイント |
|---|
| ECS サービス | タスク数をターゲット追跡（CPU / メモリ / ALB リクエスト数）。基盤が EC2 の場合はキャパシティプロバイダー（マネージドスケーリング）でクラスタ側も連動させる |
| EKS | Pod は HPA / KEDA、ノードは Karpenter または Cluster Autoscaler（+ マネージドノードグループ） |
| DynamoDB | オンデマンドモードとプロビジョンド + Auto Scaling を負荷パターンで選択 |
| Aurora | リードレプリカの Auto Scaling、または Aurora Serverless v2 |
| Lambda | プロビジョンド同時実行数をスケジュール / ターゲット追跡で調整 |
11. チェックリスト
参考