オートスケールは何を見て増やすか — 測定・判断・起動の遅れ

各段の遅れが文書にどう書かれているかを見ます(AWS のドキュメント、2026-09-16 時点)。

測定の遅れ。 EC2 のユーザーガイドは既定の basic monitoring をこう書きます。

Status check metrics are available in 1-minute periods. All other metrics are available in 5-minute periods.

(両方式を並べた表の basic monitoring 行)

CPU 使用率は「その他」なので既定は5分に1点。1分粒度にする detailed monitoring は同じ表の次の行に "You are charged per metric that Amazon EC2 sends to CloudWatch." とあり、細かく測るには値段が付きます。

判断の遅れ。 方式ごとに別の仕組みが効きます。cooldown の定義は次のとおり。

After your Auto Scaling group launches or terminates instances, it waits for a cooldown period to end before any further scaling activities initiated by simple scaling policies can start. The intention of the cooldown period is to let your Auto Scaling group stabilize and prevent it from launching or terminating additional instances before the effects of the previous scaling activity are visible.

既定値は "By default, this cooldown period is set to 300 seconds (5 minutes)." ただし同ページ冒頭に次の一文。

起動の遅れ。 instance warmup の定義はこうです。

You can specify how long after an instance reaches the InService state it waits before contributing usage data to the aggregated metrics. This specified time is called the default instance warmup.

既定の扱いに注意が要ります。同じページは "we strongly recommend that you enable and configure the default instance warmup. It is not enabled or configured by default." と書きます。warmup には既定値が無く、既定では有効ですらありません。 目安の "you could start with 300 seconds" は出発点の推奨です。待つ理由も "need time to stabilize" とあり、直後の実体は消費が跳ねるため、その値を混ぜると判断が歪みます。

増やす以外の判断も同じ構造です。第30週『死活監視 — 壊れた実体を外す仕組み』の nginx は実リクエストの失敗を数え、既定は max_fails が 1、fail_timeout が 10秒。「10秒の間に1回失敗したら、10秒間そのサーバを使わない」でした。

ここに窓があります。失敗を即反映せず10秒の区間にまとめて数えるのは測定の粒度そのもの。外した後の10秒は効果を待つ区間で cooldown と同じです。

段    増やす                     外す(nginx)
測定  粒度 既定5分                fail_timeout の窓 既定10秒
判断  安定化ウィンドウ HPA 既定300秒  max_fails 既定1 に達したか
起動  warmup 既定値なし・既定で無効  fail_timeout 後にそのまま復帰

どちらも現在ではなく「少し前の区間にまとめた状態」で決めます。方向が逆なだけで遅れ方は同じです。