I verified whether scale-out actually becomes faster now that ECS Service Auto Scaling supports high-resolution metrics (20 seconds)

Introduction

On June 18, 2026, Amazon ECS service auto scaling added support for high-resolution metrics (20-second intervals), enabling faster detection and triggering of scale-out events.

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-ecs-faster-autoscaling/

Previously, ECS Target Tracking Auto Scaling made scaling decisions based on CloudWatch metrics at 60-second intervals. With this update, CPU and memory utilization can now be collected and evaluated at 20-second intervals, significantly reducing the time from load spike detection to scale-out activation.

According to AWS official benchmarks, the time to scale-out trigger has been reported to be 4.2x faster.

Note that the PredefinedMetricType values in the table above are not CloudWatch metric names. They are predefined metric types specified in Application Auto Scaling target tracking policies.

As CloudWatch metric names, both use CPUUtilization in the AWS/ECS namespace. The difference with high-resolution metrics is that data points can be collected and evaluated with a 20-second Period.

In this article, we built two ECS services in parallel, applied CPU load to both simultaneously, and measured the actual time to scale-out activation for comparison.

Test Environment

Configuration Steps

Enabling High-Resolution Metrics

Specify the 20-second resolution using the --monitoring parameter when creating an ECS service.

# Create service with high-resolution metrics
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}]'

When assignPublicIp=DISABLED, the environment must be able to communicate externally via a NAT Gateway or required VPC endpoints.

To set both CPU and memory to high resolution, specify metricNames=[CPUUtilization,MemoryUtilization].

For standard resolution (60-second) services, create without specifying the --monitoring parameter.

Configuring Auto Scaling Policy

Configure a target tracking policy with Application Auto Scaling.

# Register scalable target
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

# Target tracking policy with high-resolution metrics
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

Specify ECSServiceAverageCPUUtilization for standard resolution services.

Test Results

We applied 100% CPU load to both services at nearly the same time and measured the time from each task's start time to scale-out activation.

The time definitions used in this test are as follows:

• Task start time: startedAt of the ECS Task (the time the container became RUNNING and stress-ng started)
• Scale-out activation time: The time the ECS Service desired count changed from 1 to 2 (confirmed via describe-scaling-activities)

Scale-Out Activation Time Comparison

The service using high-resolution metrics triggered scale-out approximately 3.5x faster (about 5 minutes earlier) than the conventional approach.

AWS official benchmarks report an improvement from 363 seconds to 86 seconds (4.2x) to trigger. Our result of 418 seconds to 120 seconds (3.5x) in our own environment confirms an improvement of a similar order, despite differences in measurement conditions and evaluation timing.

Why Is It Faster?

The difference in scale-out activation speed comes from the difference in CloudWatch alarm evaluation timing.

The CloudWatch Alarms automatically generated by the Target Tracking policy in this test had the following conditions set for the scale-out side:

• Standard resolution side: Period=60 seconds, EvaluationPeriods=3, DatapointsToAlarm=3

• High-resolution side: Period=20 seconds, EvaluationPeriods=3, DatapointsToAlarm=3

• 60-second resolution: 3 data points × 60 seconds = detection in as little as 180 seconds

• 20-second resolution: 3 data points × 20 seconds = detection in as little as 60 seconds

In practice, the result is longer than the theoretical minimum due to timing differences in metric publication, alarm evaluation, and Application Auto Scaling processing. Even so, it is confirmed that the difference in metric resolution contributes significantly to reducing scale-out activation time.

CloudWatch Metric Data Points

Below are the actual metric data points collected.

Normal (60-second resolution)

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-second resolution)

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%  ← Starting point of 3 consecutive exceedances
08:54:20  74.5%
08:54:40 100.0%  ← 3 consecutive exceedances achieved here
08:55:00 100.0%
08:55:20 100.0%

At 20-second resolution, threshold exceedance was confirmed at the 3 data points of 08:54:00, 08:54:20, and 08:54:40. After that, following CloudWatch Alarm evaluation and Application Auto Scaling processing, scale-out was activated at 08:55:39. At 60-second resolution, it took additional time to meet the same conditions, resulting in a wait until 09:00:47.

Notes

Configuration Constraints

• Enabling high-resolution metrics triggers a service deployment. High-resolution scaling policy configuration becomes available after the deployment completes
• Services using Classic Load Balancer (without target groups) are not supported
• Services using CODE_DEPLOY and EXTERNAL deployment controllers are not supported
• When replacing an existing Target Tracking Policy with the high-resolution version, leaving the standard resolution policy in place simultaneously makes behavior difficult to interpret. In this test, only one Target Tracking Policy was configured per service

Pricing

High-resolution metrics are charged as CloudWatch Detailed Monitoring Metrics. While the metrics themselves are service metrics in the AWS/ECS namespace, the pricing follows the custom metrics unit price. The conventional 60-second resolution is free as Basic Monitoring.

Since a Target Tracking Policy automatically creates CloudWatch Alarms for scale-out and scale-in, multiple alarm charges are incurred per policy.

CloudWatch pricing page Example 27 provides a specific pricing example for ECS high-resolution metrics. For 4 services using high-resolution metrics for both CPU and memory, the monthly cost is approximately $1.38–$2.50.

https://aws.amazon.com/cloudwatch/pricing/

For a minimal configuration with high resolution for CPU only on a single service, the additional cost is approximately $0.30 for the metric + $0.30 × 2 for alarms = about $0.90/month. For small-scale configurations, the additional cost is low, making it an easy option to consider when you want to reduce scale-out activation time.

Summary

We enabled high-resolution metrics (20-second intervals) for ECS and confirmed in a single trial measurement that Target Tracking Auto Scaling scale-out activation became approximately 3.5x faster.
The additional cost is also low, starting at around $0.90 per service per month. It is a strong option for environments that need to improve response to unpredictable load fluctuations such as spike traffic or sudden bursts of batch processing. By combining it with scheduled scaling and predictive scaling, a more robust scaling configuration can be achieved.

Reference Links

https://aws.amazon.com/blogs/aws/amazon-ecs-introduces-new-high-resolution-metrics-for-faster-service-auto-scaling/

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/target-tracking-faster-auto-scaling.html