Amazon ECS Service Auto Scaling: Dramatically Faster with High-Resolution Metrics
Amazon ECS service auto scaling now supports 20-second high-resolution metrics, reducing the time to trigger scale-out from 363 seconds to 86 seconds (4.2x faster). This article covers how the improvement works, which workloads benefit most, step-by-step CLI configuration, and key considerations including cost trade-offs and flapping prevention.
Introduction
On June 18, 2026, AWS announced a significant improvement to Amazon ECS service auto scaling. With support for high-resolution (20-second) metrics and metric publishing optimizations, the time it takes to detect load changes and complete scale-out operations has been substantially reduced.
If you've been running services on ECS, you may have encountered situations where an unexpected traffic spike outpaced your auto scaling, resulting in elevated latency or errors. Or perhaps you've been maintaining a higher-than-necessary baseline task count to hedge against unpredictable spikes—and paying for it. This update addresses both of those problems directly.
This article walks through what changed, which workloads stand to benefit most, and how to configure the feature. The primary audience is infrastructure and backend engineers operating ECS services, as well as those looking to revisit their cost optimization or scaling strategy.
What Changed
ECS service auto scaling evaluates scaling policies based on metrics published to Amazon CloudWatch, then adjusts the desired task count accordingly. With the default 60-second metric resolution, it could take over six minutes from the moment load spiked to when new tasks were fully provisioned.
This update introduces support for 20-second high-resolution metrics, along with internal optimizations to the metric publishing pipeline. AWS benchmarking results show the following improvements:
| Metric | Before | After |
|---|---|---|
| Metric resolution | 60 seconds (standard) | 20 seconds (high-resolution) now available |
| Time to trigger scale-out | ~363 seconds (~6 min) | ~86 seconds (~1.4 min), 76% faster (4.2x) |
| Total time to scale and provision new tasks | ~386 seconds (~6.4 min) | ~109 seconds (~1.8 min), 72% faster (3.5x) |
Why Is It Faster?
There are two factors driving the improvement.
The first is the reduction in metric evaluation intervals. By shortening the interval at which ECS publishes CPU and memory utilization metrics to CloudWatch from 60 seconds to 20 seconds, Application Auto Scaling can now evaluate scaling decisions three times more frequently.
The second is the optimization of the metric publishing pipeline. Internal improvements on the ECS side have reduced the latency between when metrics are written to CloudWatch and when they are reflected in scaling policy evaluations. Together, these two changes can deliver a noticeably faster response in practice—sometimes beyond what the benchmark numbers alone suggest.
When high-resolution metrics are enabled, the following predefined metrics become available for use in target tracking scaling policies:
| PredefinedMetricType | Description |
|---|---|
| ECSServiceAverageCPUUtilizationHighResolution | Average CPU utilization at 20-second resolution |
| ECSServiceAverageMemoryUtilizationHighResolution | Average memory utilization at 20-second resolution |
The existing 60-second standard resolution metrics remain available. High-resolution metrics are opt-in, so existing services are unaffected until you explicitly configure them.
Which Workloads Benefit?
The degree of improvement depends on the characteristics of your workload. Rather than applying this change universally, it's worth evaluating whether your services match the profiles where the feature delivers meaningful impact.
High-Impact Scenarios
The clearest gains come from services that experience sharp, unpredictable traffic spikes. In scenarios like flash sales on e-commerce platforms or event launches in gaming services—where request volume can surge within minutes—the previous six-plus-minute scale-out window was often too slow to prevent impact. Cutting total provisioning time to approximately 109 seconds (~1.8 minutes) makes a real difference for end-user experience.
Consumer services built on Amazon SQS queues are another strong fit. Faster task scale-out in response to queue depth growth helps prevent processing backlogs from accumulating.
Services that maintain elevated baseline task counts as a buffer against unexpected spikes also stand to benefit. With faster scale-out, there's less need to over-provision headroom, which translates directly to reduced compute costs.
Limited-Benefit Scenarios
For services where traffic follows predictable daily or weekly patterns, Predictive Scaling or Scheduled Scaling may deliver more value. Proactively provisioning capacity ahead of anticipated demand is generally more effective at preventing latency impact than reactive scaling alone.
Services with stable, consistent load—or cases where the primary scaling bottleneck is task startup time rather than metric evaluation latency—will see limited gains from this feature in isolation.
Cost Trade-offs
Standard-resolution (60-second) ECS metrics are published to CloudWatch at no charge. High-resolution (20-second) metrics incur additional CloudWatch costs. The feature itself carries no extra charge, but switching to 20-second resolution triples the number of metric data points, increasing CloudWatch metric costs accordingly. See the Amazon CloudWatch Pricing page for details.
The right framework for evaluating adoption is to weigh the compute cost savings from reduced baseline capacity against the additional CloudWatch metric costs. Services that currently maintain significant spare capacity to absorb spikes will generally find the trade-off favorable. A practical approach is to start with your highest-traffic or most spike-prone services, validate the impact, then expand from there.
Choosing Your Scaling Strategy
ECS service auto scaling supports multiple policy types, each suited to different scenarios. The improved responsiveness of target tracking with high-resolution metrics makes it worth revisiting how you're combining these policies.
| Policy Type | Best For | Characteristics |
|---|---|---|
| Predictive Scaling | Recurring patterns such as morning business hours or weekend traffic increases | Uses ML to analyze historical load data and proactively scales before demand arrives |
| Scheduled Scaling | Planned events with known timing—sales, releases, batch jobs | Changes task count at a specified time; reliable for anticipated load |
| Target Tracking (high-resolution) | Sudden, unpredictable traffic spikes | The focus of this update. Reactive scaling with near-real-time metric evaluation |
Understanding Each Policy Type
Predictive Scaling and Scheduled Scaling are both proactive approaches. Predictive Scaling learns traffic patterns automatically without manual configuration, though it requires sufficient historical data to be accurate—making it less effective for newly launched services. Scheduled Scaling is reliable for known events but cannot respond to spikes that occur outside of planned windows.
Target tracking scales reactively based on real-time metrics, making it well-suited for unpredictable load fluctuations. The limitation historically was the 60-second evaluation interval; the high-resolution metric support in this update addresses that directly.
Combining Strategies in Practice
A practical configuration might use Predictive Scaling for recurring daily traffic patterns, Scheduled Scaling for planned campaigns or deployments, and high-resolution target tracking as a backstop for unanticipated spikes. Using proactive and reactive policies together lets each compensate for the other's blind spots.
Migrating from Step Scaling
Some teams have relied on step scaling policies to achieve aggressive reactive scaling—defining multiple adjustment steps to compensate for target tracking's slower response. With high-resolution target tracking, that level of responsiveness is now achievable with a simpler single-policy configuration. If you've been maintaining complex step scaling setups, this update is a good opportunity to consolidate.
How to Configure
The configuration process differs depending on whether you're creating a new service or updating an existing one. Updating an existing service is a two-step process. Note that this feature is supported for services using Application Load Balancers or Network Load Balancers. Classic Load Balancers without target groups are not supported, nor are services using the
CODE_DEPLOY or EXTERNAL deployment controller types.New Services
From the Console
In the service creation form, go to the Monitoring configuration section and choose Add metric configuration. Select
CPUUtilization or MemoryUtilization as the metric name and set the resolution to 20 seconds. In the Service auto scaling section, choose Target Tracking as the scaling policy type, then select ECSServiceAverageCPUUtilizationHighResolution or ECSServiceAverageMemoryUtilizationHighResolution as the metric type.Using the AWS CLI
Start by creating the service with a 20-second monitoring configuration:
1
2
3
4
5
6
aws ecs create-service --region <region> \
--cluster <cluster-name> \
--service-name <service-name> \
--task-definition <task-definition> \
--desired-count <desired-count> \
--monitoring "metricConfigurations=[{metricNames=[CPUUtilization,MemoryUtilization],resolutionSeconds=20}]"
Next, register the service as a scalable target with Application Auto Scaling:
1
2
3
4
5
6
7
aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--resource-id service/<cluster-name>/<service-name> \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity <min-capacity> \
--max-capacity <max-capacity> \
--region <region>
Finally, create a target tracking scaling policy using the high-resolution predefined metric:
1
2
3
4
5
6
7
8
9
10
11
12
13
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--resource-id service/<cluster-name>/<service-name> \
--scalable-dimension ecs:service:DesiredCount \
--policy-name <policy-name> \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": <target-value>,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
}
}' \
--region <region>
Configuration via AWS CloudFormation and the AWS SDKs is also supported.
Updating Existing Services
Updating an existing service is a two-step process. You must first update the monitoring configuration and wait for the resulting service deployment to complete. Only after all tasks are emitting metrics at 20-second resolution can you configure the high-resolution scaling policy. If you attempt to configure the policy before the deployment finishes, the high-resolution metric options will be grayed out in the console.
From the Console
Open the service Update form and add a 20-second resolution metric configuration in the Monitoring configuration section, then submit the update. Once the deployment completes, navigate to the Service auto scaling tab on the service detail page to create a scaling policy using the high-resolution metric.
Using the AWS CLI
Update the monitoring configuration and wait for the deployment to complete:
1
2
3
4
aws ecs update-service --region <region> \
--cluster <cluster-name> \
--service <service-name> \
--monitoring "metricConfigurations=[{metricNames=[CPUUtilization,MemoryUtilization],resolutionSeconds=20}]"
Neither
update-service nor create-service responses include the monitoring configuration. To confirm the change was applied, use describe-service-revisions after the deployment completes. First retrieve the active service revision ARN from describe-services, then run:1
2
aws ecs describe-service-revisions --region <region> \
--service-revision-arns <service-revision-arn>
If the response includes
"resolutionSeconds": 20, the monitoring configuration has been applied successfully.Once the deployment completes, register the service as a scalable target:
1
2
3
4
5
6
7
aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--resource-id service/<cluster-name>/<service-name> \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity <min-capacity> \
--max-capacity <max-capacity> \
--region <region>
Then create the scaling policy:
1
2
3
4
5
6
7
8
9
10
11
12
13
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--resource-id service/<cluster-name>/<service-name> \
--scalable-dimension ecs:service:DesiredCount \
--policy-name <policy-name> \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": <target-value>,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
}
}' \
--region <region>
Verifying Your Configuration
In the CloudWatch console, go to Metrics → All metrics → AWS/ECS → ClusterName, ServiceName. Set the period to 20 seconds and confirm that data points are appearing at 20-second intervals. On the service detail page, check the Service auto scaling tab to verify that the scaling policy is referencing
ECSServiceAverageCPUUtilizationHighResolution or ECSServiceAverageMemoryUtilizationHighResolution.Best Practices and Considerations
Set Cooldown Periods Carefully
With scaling decisions evaluated every 20 seconds instead of every 60, scaling events will trigger more frequently. Without appropriate cooldown periods, minor fluctuations in load can cause task counts to oscillate rapidly—commonly referred to as flapping.
Set scale-in cooldown periods with extra margin. The general principle is to scale out aggressively and scale in conservatively. ECS allows you to configure separate cooldown periods for scale-out and scale-in, so tune each independently based on your service's traffic behavior.
Test in a Non-Production Environment First
Updating the monitoring configuration creates a new service revision and triggers a service deployment. Before applying the change to production, validate scaling behavior in a development or staging environment.
Visualize Scaling Behavior with CloudWatch
A CloudWatch dashboard showing CPU and memory utilization alongside task count gives you end-to-end visibility into the scaling pipeline—from metric spike to task provisioning. It's useful both for confirming that the feature is working as expected and for tuning cooldown periods and target values over time. Rapid, repeated scaling events are a signal to check for flapping and revisit your configuration.
Summary
This article covered the Amazon ECS faster service auto scaling update. With 20-second high-resolution metrics and metric publishing optimizations, the time to trigger scale-out is now 4.2x faster, and total task provisioning time is 3.5x faster—a meaningful improvement for services that need to respond quickly to sudden traffic spikes.
That said, this isn't a change to apply across the board. High-resolution metrics incur additional CloudWatch charges, so weigh the compute cost savings against the increased observability cost before enabling it. Starting with your most spike-prone services in a non-production environment is a reasonable approach.
The feature is available today in all AWS commercial Regions and AWS GovCloud (US) Regions, across all ECS compute options: AWS Fargate, Amazon ECS Managed Instances, and Amazon EC2.
References
- Amazon ECS announces faster service auto scaling (AWS What's New)
- Amazon ECS introduces new high-resolution metrics for faster service auto scaling (AWS News Blog)
- Automatically scale your Amazon ECS service (Amazon ECS Developer Guide)
- Faster auto scaling with high-resolution metrics (Amazon ECS Developer Guide)
- Amazon CloudWatch Pricing
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article