ECSサービスオートスケーリングが高解像度メトリクス（20秒）に対応したので、スケールアウトが本当に速くなるか検証してみた
はじめに
2026年6月18日、Amazon ECSのサービスオートスケーリングが高解像度メトリクス（20秒間隔）に対応し、スケールアウトの検知・発動が高速化されました。
従来、ECSのTarget Tracking Auto Scalingは60秒間隔のCloudWatchメトリクスに基づいてスケーリング判断を行っていました。今回のアップデートにより、CPUおよびメモリ使用率を20秒間隔で取得・評価できるようになり、負荷変動の検知からスケールアウト発動までの時間が大幅に短縮されます。
AWSの公式ベンチマークでは、スケールアウトトリガーまでの時間が4.2倍高速化したと報告されています。
| 項目 | 従来（60秒解像度） | 新機能（20秒解像度） |
|---|---|---|
| メトリクス発行間隔 | 60秒 | 20秒 |
| PredefinedMetricType | ECSServiceAverageCPUUtilization |
ECSServiceAverageCPUUtilizationHighResolution |
| 追加料金 | なし（Basic Monitoring） | あり（Detailed Monitoring相当） |
| 対応コンピュート | Fargate / Managed Instances / EC2 | 同左 |
なお、上表のPredefinedMetricTypeはCloudWatchメトリクス名ではありません。Application Auto Scalingのターゲット追跡ポリシーで指定する定義済みメトリクスタイプです。
CloudWatch上のメトリクス名としては、どちらもAWS/ECS名前空間のCPUUtilizationです。高解像度メトリクスでは20秒Periodでデータポイントを取得・評価できる点が異なります。
本記事では、2つのECSサービスを並列で構築し、同時にCPU負荷をかけてスケールアウト発動までの時間を実測比較しました。
検証環境
| 項目 | 設定値 |
|---|---|
| リージョン | ap-northeast-1 |
| コンピュート | AWS Fargate (0.25 vCPU, 512MB) |
| コンテナイメージ | amazonlinux:2 + EPEL + stress-ng |
| クラスター | 2つ新規作成（autoscale-test-normal / autoscale-test-highres） |
| Auto Scaling | min=1, max=3, TargetValue=50% |
| Cooldown | デフォルト値（ScaleOutCooldown / ScaleInCooldown ともに未指定） |
| 負荷生成 | タスク定義コマンド: stress-ng --cpu 0 --timeout 600s |
設定手順
高解像度メトリクスの有効化
ECSサービスの作成時に--monitoringパラメータで20秒解像度を指定します。
# 高解像度メトリクス付きでサービス作成
aws ecs create-service \
--region ap-northeast-1 \
--cluster autoscale-test-highres \
--service-name stress-highres \
--task-definition autoscale-test-stress:3 \
--desired-count 1 \
--launch-type FARGATE \
--network-configuration 'awsvpcConfiguration={subnets=[subnet-xxxxxxxxxxxxxxxxx],securityGroups=[sg-xxxxxxxxxxxxxxxxx],assignPublicIp=DISABLED}' \
--monitoring 'metricConfigurations=[{metricNames=[CPUUtilization],resolutionSeconds=20}]'
assignPublicIp=DISABLEDの場合、NAT Gatewayまたは必要なVPCエンドポイント経由で外部通信できる環境が前提です。
CPUとメモリの両方を高解像度にする場合はmetricNames=[CPUUtilization,MemoryUtilization]を指定します。
通常解像度（60秒）のサービスは、--monitoringパラメータを指定せずに作成します。
Auto Scalingポリシーの設定
Application Auto Scalingでターゲット追跡ポリシーを設定します。
# スケーラブルターゲットの登録
aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--resource-id service/autoscale-test-highres/stress-highres \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity 1 \
--max-capacity 3 \
--region ap-northeast-1
# 高解像度メトリクスによるターゲット追跡ポリシー
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--resource-id service/autoscale-test-highres/stress-highres \
--scalable-dimension ecs:service:DesiredCount \
--policy-name highres-cpu-policy \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
}
}' \
--region ap-northeast-1
通常解像度のサービスには ECSServiceAverageCPUUtilization を指定します。
検証結果
両サービスにほぼ同時にCPU 100%負荷をかけ、各タスクの起動時刻を起点としてスケールアウトが発動するまでの時間を計測しました。
本検証における時刻の定義は以下のとおりです。
- タスク起動時刻: ECS Taskの
startedAt（コンテナがRUNNINGになりstress-ngが開始された時刻） - スケールアウト発動時刻: ECS Serviceのdesired countが1から2に変更された時刻（
describe-scaling-activitiesで確認）
スケールアウト発動時間の比較
| 項目 | Normal (60秒解像度) | Highres (20秒解像度) |
|---|---|---|
| タスク起動時刻 | 08:53:49 | 08:53:39 |
| スケールアウト発動時刻 | 09:00:47 | 08:55:39 |
| 起動→スケールアウトまで | 418秒 | 120秒 |
高解像度メトリクスを使用したサービスは、従来の約3.5倍速く（約5分早く）スケールアウトが発動しました。
AWS公式ベンチマークではトリガーまで363秒→86秒（4.2倍）の改善が報告されています。自環境での418秒→120秒（3.5倍）という結果も、計測条件や評価タイミングの違いはあるものの、同程度のオーダーで改善が確認できました。
なぜ速くなるのか
スケールアウト発動の速度差は、CloudWatchアラームの評価タイミングの違いから生まれます。
本検証でTarget Trackingポリシーにより自動生成されたCloudWatch Alarmでは、スケールアウト側の条件として以下が設定されていました。
-
通常解像度側： Period=60秒、EvaluationPeriods=3、DatapointsToAlarm=3
-
高解像度側： Period=20秒、EvaluationPeriods=3、DatapointsToAlarm=3
-
60秒解像度: 3データポイント × 60秒 = 最短180秒で検知
-
20秒解像度: 3データポイント × 20秒 = 最短60秒で検知
実際にはメトリクス発行とアラーム評価、Application Auto Scalingの処理タイミングのずれにより理論最短値よりは長くなります。それでも、メトリクス解像度の違いがスケールアウト発動時間の短縮に大きく寄与していることが確認できます。
CloudWatch メトリクスのデータポイント
実際に取得されたメトリクスのデータポイントを示します。
Normal（60秒解像度）
08:52:00 9.8%
08:53:00 0.4%
08:54:00 44.7%
08:55:00 99.9%
08:56:00 99.6%
08:57:00 100.0%
08:58:00 99.9%
08:59:00 99.9%
09:00:00 99.8%
09:01:00 82.8%
09:02:00 91.1%
Highres（20秒解像度）
08:52:20 5.3%
08:52:40 1.6%
08:53:00 0.0%
08:53:20 0.0%
08:53:40 49.3%
08:54:00 86.3% ← 3連続超過の起点
08:54:20 74.5%
08:54:40 100.0% ← ここで3連続達成
08:55:00 100.0%
08:55:20 100.0%
20秒解像度では08:54:00、08:54:20、08:54:40の3データポイントで閾値超過が確認できました。その後、CloudWatch Alarmの評価およびApplication Auto Scalingの処理を経て、08:55:39にスケールアウトが発動しています。60秒解像度では同じ条件を満たすまでにさらに時間がかかり、09:00:47まで待つことになりました。
注意事項
設定時の制約
- 高解像度メトリクスの有効化にはサービスデプロイが発生します。デプロイ完了後に高解像度スケーリングポリシーの設定が可能になります
- Classic Load Balancer（ターゲットグループなし）を使用するサービスは非対応です
CODE_DEPLOYおよびEXTERNALデプロイコントローラを使用するサービスは非対応です- 既存のTarget Tracking Policyを高解像度版に置き換える場合、通常解像度ポリシーを同時に残すと挙動の解釈が難しくなります。本検証では1サービスにつき1つのTarget Tracking Policyのみを設定しました
料金
高解像度メトリクスはCloudWatchのDetailed Monitoring Metricsとして課金されます。メトリクス自体はAWS/ECS名前空間のサービスメトリクスですが、料金体系はカスタムメトリクスの単価に準じます。従来の60秒解像度はBasic Monitoringとして無料です。
| 料金項目 | 単価（ap-northeast-1） |
|---|---|
| 高解像度メトリクス | $0.30/メトリクス/月（最初の10,000メトリクスまで） |
| 高解像度アラーム | $0.30/アラーム/月 |
Target Tracking Policyはスケールアウト用・スケールイン用のCloudWatch Alarmを自動作成するため、1ポリシーあたり複数のアラーム課金が発生します。
CloudWatch料金ページのExample 27に、ECS高解像度メトリクスの具体的な料金例が記載されています。4サービスでCPU + メモリの高解像度メトリクスを利用した場合、月額$1.38〜$2.50程度です。
1サービスでCPUのみを高解像度にする最小構成であれば、メトリクス$0.30 + アラーム$0.30 × 2 = 月額$0.90程度の追加コストです。小規模な構成であれば追加コストは小さく、スケールアウト発動時間を短縮したい場合に検討しやすい選択肢です。
まとめ
ECSの高解像度メトリクス（20秒間隔）を有効化し、Target Tracking Auto Scalingのスケールアウト発動が約3.5倍速くなることを単一試行の実測で確認しました。
追加料金もサービスあたり月額$0.90程度からと低コストです。スパイクアクセスやバッチ処理の急増など、予測困難な負荷変動への対応を強化したい環境では有力な選択肢になります。スケジュールスケーリングや予測スケーリングを補う手段として組み合わせることで、より堅牢なスケーリング構成が実現できます。
参考リンク
