ECSのオートスケールが遅い問題を20秒メトリクスで直す — 効果・料金・どのワークロードで効くか
Amazon ECSのtarget trackingがCPU/メモリの20秒メトリクスに対応。負荷検知が速くなり、過剰なベース容量を削れます。一方で高解像メトリクスのCloudWatch課金や、過敏スケール・Fargateのprovisioning時間という落とし穴も。効果・料金・効くワークロードの見極めを実務目線で整理します。仕様・料金は現行時点の記述として公式もご確認ください。
- #AWS
- #ECS
- #Fargate
- #Auto Scaling
- #CloudWatch
ピーク時にスケールアウトが間に合わず、リクエストを取り残してしまう。かといってベース容量（常時起動させておくタスクやインスタンス）を厚くすると、平常時のコストが膨らむ。Amazon ECS でサービスを運用する際の、この板挟みは珍しくありません。2026年6月18日、ECS の service auto scaling が CPU/メモリの 20秒の高解像度メトリクスに対応し、負荷検知を速くできるようになりました。本記事では、これで何が速くなるのか、料金はどう増えるのか、そしてどのワークロードで効いて、どこに落とし穴があるのかを、採用判断の軸で整理します。仕様や料金は現行時点（2026年6月）の記述のため、導入時に公式情報もあわせてご確認ください。
なぜECSのスケールは「遅い」と感じるのか
ECS の service auto scaling は、CloudWatch に集まるメトリクス（CPU使用率やメモリ使用率など）を見て、サービスのタスク数を自動で増減させる仕組みです。ここで初動を遅らせる要因のひとつが、メトリクスの集計間隔です。
ECS のサービスメトリクスは、通常 1分間隔で CloudWatch に送信されます。つまりスケーリングポリシーは、最短でも1分ごとの集計値を見て判断することになり、負荷が立ち上がってから「閾値を超えた」と気づくまでにラグが生じます。スパイクが急なほど、この検知の遅れが取り残しに直結します。
この遅れを縮めるために追加されたのが、20秒解像度のオプションです。集計間隔が短くなれば、負荷の立ち上がりに早く気づき、スケールアウトの初動を前倒しできます。
何が変わったか — 20秒メトリクスで速くなること
今回対応したのは、target tracking ポリシーの CPU使用率・メモリ使用率（いずれも定義済みメトリクス）が、既定の60秒に加えて20秒解像度を選べるようになった点です。AWS の発表（What’s New）でも、対象は「CPU とメモリ使用率の target tracking ポリシー」と明記されています。
注意したいのは対象範囲です。現時点で20秒対応が公式に明記されているのは、上記の CPU/メモリの target tracking 定義済みメトリクスです。step scaling やカスタムメトリクス、ALBのリクエスト数ベースのスケーリングが20秒対応かどうかは発表に明記がないため、本記事では対象として断定しません。利用前に、ECS および Application Auto Scaling の公式ドキュメントで現行の対応範囲をご確認ください。
速くなる効果について、AWS は社内のベンチマークテストの値を示しています。スケールアウトの発火までが 363秒から86秒（約76%短縮）、新しいタスクの起動まで含めた総時間が **386秒から109秒（約72%短縮）**という結果です。ただしこれは AWS 社内ベンチの値であり、構成や負荷の性質に依存します。保証された値ではなく参考値として捉えてください。また、総時間にはタスクの provisioning（起動準備）時間が含まれます。20秒化で縮むのは主に「検知の遅れ」の部分であり、タスクが立ち上がる速さそのものが速くなるわけではない点は押さえておく必要があります。
なお、ECS の service auto scaling は Application Auto Scaling 上で動き、target tracking のほかに step scaling（アラームの超過幅に応じた段階調整）、scheduled scaling（日時指定）、predictive scaling（履歴パターンからの先回り）の4種類があります。これらは併用も設計でき、たとえば周期的なベース負荷を predictive で先回り確保し、急な変動を20秒の target tracking で吸収する、といった組み合わせが考えられます。
対応するコンピュートは Fargate・ECS Managed Instances・EC2 のいずれもで、全AWS商用リージョンと GovCloud (US) で利用できます。東京リージョンを含めて、すでに一般提供（GA）されています。設定は Console・CLI・CloudFormation・SDK から、サービスの作成・更新時に20秒解像度を指定して構成します。設定項目やコマンドはバージョンによって変わり得るため、具体的な手順は公式ドキュメントの現行版でご確認ください。
料金の綱引き — 高解像メトリクス課金とベース容量削減
20秒化を判断するうえで外せないのが料金です。機能自体に追加料金はありません。増分は、高解像度のメトリクスとアラームにかかる CloudWatch の従量課金です。
具体的には、target tracking は内部で CloudWatch アラームを自動作成しますが、20秒解像度にするとこのアラームが高解像アラームの扱いになります。CloudWatch の料金（US East基準・リージョンで変動）では、高解像アラームが1個あたり月 $0.30、標準アラームが月 $0.10 で、差は1アラームあたり月 $0.20 です。CPU/メモリは AWS が発行する定義済みメトリクスのため、自前で PutMetricData するカスタムメトリクスの課金階層とは別の扱いになります。CloudWatch にはアラーム10個/月などの無料利用枠もあるため、小規模な構成では増分が枠内に収まることもあります。
増分要因と削減要因を並べると、判断の筋が見えてきます。
| 観点 | 内容 | 規模感 |
|---|---|---|
| 増分（監視費） | 高解像アラーム化（+$0.20/個・月）＋高解像メトリクス分の従量 | 1サービスのアラームは数個オーダー＝月数十〜数百円規模 |
| 削減（コンピュート費） | 検知が速くなる分、過剰に厚くしていたベース容量を削減できる | 常時起動タスク/インスタンスの削減＝桁が大きいことが多い |
1サービスあたりのアラームは通常数個のオーダーで、監視費の増分は月数十円から数百円程度に収まることが多い一方、20秒化で過剰なベース容量を削減できれば、コンピュート費の削減幅はそれより桁が大きくなりがちです。「わずかな監視費の増加で、過剰なベース容量を削る」というのが基本的な損益の筋です。ただし、スパイクが頻繁でスケール動作が多い構成では監視対象やアラームも積み上がるため、増分が無視できなくなる場合もあります。サービスあたりの総額は構成依存のため、実際の単価と課金例は CloudWatch の料金ページで確認してください。
速い＝常に得ではない — 効くワークロードと注意すべき構成
検知が速くなること自体は望ましいことですが、「速くすれば常に得」とは限りません。効くワークロードを見極め、設計で暴れを抑えて初めて効果になります。
第一に、**過敏なスケールによるタスクのchurn（頻繁な起動・停止）**です。検知が20秒で速くなる分、ターゲット値や cooldown の設定が緩いと、スケールアウトとスケールインが頻発し、タスクの起動・停止が増えて不安定になります。min/max capacity の範囲、cooldown、ターゲット値を適切に設計して、振動を抑えることが前提になります。
第二に、Fargate特有のボトルネックです。前述のとおり、検知が速くなってもタスクの provisioning 時間はボトルネックとして残ります。20秒化で効くのは主に検知の遅れの部分であり、起動の速さは別の問題です。立ち上がりの速さが重要なら、min capacity の確保や暖機で補う設計が必要です。ECS Managed Instances や EC2 では、キャパシティプロバイダによるインスタンス調達の待ち時間も絡みます。
第三に、運用上の境界の挙動です。デプロイ中はスケールインが自動的に停止します（スケールアウトは継続します）。また、min capacity を0にしたゼロスケール構成では、実容量が0で需要が発生したとき、最初のデータポイントを待ってから最小単位でスケールアウトするため、立ち上がりが一拍遅れます。
効く場面と注意すべき場面を整理すると、次のようになります。
| 区分 | 例 | 設計のポイント |
|---|---|---|
| 効きやすい | 検知の遅れが取り残しに直結する、急なスパイクのあるサービス | 20秒 target tracking ＋適切なターゲット値・cooldown |
| 注意が必要 | スパイクが頻繁でフラッピングしやすい構成 | min/max・cooldownで振動抑制／監視費の積み上がりも確認 |
| 効果が限定的 | provisioning時間が支配的なFargate、ゼロスケール運用 | min capacity・暖機で起動側を補完（検知速度だけでは解決しない） |
まとめ
ECS の20秒メトリクス対応は、採用判断の要点を押さえれば有効な選択肢になります。
- 対象: 現時点で公式に明記があるのは CPU/メモリの target tracking 定義済みメトリクス。それ以外は対象として断定しない。
- 効果: 速くなるのは検知の遅れ。タスクの provisioning 時間は別問題で、ベンチ値は環境依存の参考値。
- 料金: 機能自体は追加料金なし。増分は高解像メトリクス/アラームの CloudWatch 課金で、過剰なベース容量削減との綱引きで見る。
- 設計: 過敏スケールによるchurnや Fargate の provisioning ボトルネックを、min/max・cooldown・暖機で抑えて初めて効果になる。
検知を速くすることは、コストを抑えながら可用性を保つ運用の一手です。コスト面の最適化をさらに進めるなら AWS FinOps Agent による無駄の洗い出しが、スケールの挙動やメトリクスを継続的に把握するなら CloudWatchのOpenTelemetryメトリクス対応 が、それぞれ組み合わせとして効いてきます。まずは自分のサービスが「検知の遅れで取り残しているのか、provisioningで遅いのか」を切り分けるところから始めると、20秒化が効くかどうかの判断がつきます。
出典
- AWS What’s New「Amazon ECS announces faster service auto scaling」（2026-06-18・GA） — https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ecs-faster-autoscaling/
- Amazon ECS Developer Guide「Automatically scale your Amazon ECS service」 — https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html
- Amazon CloudWatch pricing（高解像アラーム/メトリクスの単価・課金例） — https://aws.amazon.com/cloudwatch/pricing/
- AWS Blog「New – High-Resolution Custom Metrics and Alarms for Amazon CloudWatch」（高解像アラームの単価の根拠） — https://aws.amazon.com/blogs/aws/new-high-resolution-custom-metrics-and-alarms-for-amazon-cloudwatch/