The scale-out that looked fine in a load test and then blipped in production was often waiting on a one-minute CloudWatch point. Amazon ECS high-resolution metrics, announced June 18, 2026, publish CPUUtilization and MemoryUtilization every 20 seconds and let target tracking evaluate on that cadence.
The number people quote is 76% faster. That is AWS's benchmark for time to trigger scale-out, 363 seconds down to 86 seconds, about 4.2x. Total time to scale and provision new tasks in the same test went from 386 seconds to 109 seconds, 72% faster. It is not a drop from a 60-second evaluation interval to 10 seconds. Ten seconds is the lowest period EC2 Auto Scaling accepts on a custom high-resolution metric. ECS service metrics are 20.
The task definition does not change. The service does, and then the scaling policy does. An existing CPU, memory, or ALB request-count policy does not pick this up on its own.
Enable 20-second metrics on the service first
By default ECS still publishes those two service metrics at 60-second resolution, at no extra CloudWatch charge. You opt into 20 seconds on the service monitoring configuration. Valid resolutionSeconds values are 20 and 60. Valid metric names are CPUUtilization and MemoryUtilization. Fargate, ECS Managed Instances, and EC2 launch types all support it.
aws ecs update-service \
--cluster my-cluster \
--service my-service \
--monitoring "metricConfigurations=[{metricNames=[CPUUtilization,MemoryUtilization],resolutionSeconds=20}]"
That update creates a new service revision and starts a deployment. The high-resolution scaling metric is not available until the deployment finishes and every running task is emitting at 20 seconds. CreateService and UpdateService responses omit the monitoring block. Read it from DescribeServiceRevisions.
CodeDeploy and EXTERNAL controllers are out. Classic Load Balancers without a target group are out. Application Load Balancers and Network Load Balancers are the supported path.
Then point target tracking at the high-resolution metric
Application Auto Scaling adds two predefined metric types: ECSServiceAverageCPUUtilizationHighResolution and ECSServiceAverageMemoryUtilizationHighResolution. You must enable the matching 20-second metric on the service before you create a policy with either type.
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--resource-id service/my-cluster/my-service \
--scalable-dimension ecs:service:DesiredCount \
--policy-name cpu-highres \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
}
}'
A new service can take both the monitoring block and the policy at create time. An existing service is two steps: monitoring, wait for the deployment, then the policy. Flip the policy first and the console greys the high-resolution metric out until the tasks catch up.
There is no ALBRequestCountPerTargetHighResolution. ALBRequestCountPerTarget stays the ALB metric it was. CPU and memory policies you already have keep evaluating the 60-second series until you change PredefinedMetricType. Leaving the old policy next to the new one makes the desired count hard to explain. Replace it.
CloudFormation puts the same monitoring object on AWS::ECS::Service. The CDK L2 monitoring property is still an open pull request; until it lands, set monitoring on CfnService or an L1 override. The container image, CPU, memory, and IAM role on the task definition stay where they were.
20 seconds is detection. Cooldown and provisioning still sit after it.
Target tracking now looks every 20 seconds. Scale-out cooldown still waits for the previous scale-out to take effect. Scale-in cooldown still gates the way down. Image pull, platform version, health checks, and healthCheckGracePeriodSeconds still decide when the new task takes traffic.
AWS's 86-second trigger is the detection plus policy evaluation in that test, not the interval. The 109-second total is the first new capacity in that test. Your number is those two plus whatever your image and health check actually cost. A spike that is over in 15 seconds still finishes before a task that needs a minute to become healthy. The workloads that feel this are the ones that stay high long enough for a new task to matter: API bursts, webhook consumers, notification processors, anything behind an event bus that used to error while the 60-second point was still catching up.
Predictive scaling and scheduled scaling are unchanged. Use them for the pattern you already know is coming. High-resolution target tracking is the reactive path.
Pay CloudWatch for the points you actually use
The ECS feature has no surcharge. The 20-second series is a CloudWatch charge; the 60-second series is not. Confirm the live rate on the CloudWatch pricing page. Enable only the metric the policy reads. CPU-only target tracking does not need a 20-second memory series.
AWS's other claim is that faster scale-out lets you run a smaller baseline because you no longer pad tasks for the minute you used to wait. That is true only if the remaining provisioning time still fits your error budget. Measure time-to-healthy task under a burst, then cut desiredCount or the minimum. Do not cut the floor because the metric interval got shorter.
Turn it on for the services that spike. Leave the steady ones on free 60-second points.