I verified whether high-resolution (20-second) auto scaling can be used in ECS Express mode

Hello. This is Takeda from the Service Development Department.

In June 2026, Amazon ECS service auto scaling added support for high-resolution (20-second) metrics. In addition to the previous 60-second resolution, you can now choose 20-second resolution, allowing earlier detection of load changes and faster scale-out.

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

According to AWS benchmarks, the time to begin scale-out was reduced from 363 seconds to 86 seconds (a 76% reduction), and even including the time for new tasks to finish launching, it went from 386 seconds to 109 seconds (a 72% reduction). This update makes it easier to follow sudden load spikes while keeping costs down by lowering the baseline task count.

We have verified whether scale-out actually becomes faster when enabling this feature on a standard ECS service in a separate article on our site.

https://dev.classmethod.jp/articles/ecs-high-resolution-metrics-faster-autoscaling/

In this article, we verify whether this high-resolution auto scaling can also be used with ECS Express mode, which lets you publish a web app with just three settings. Express mode automatically configures everything from the ALB to auto scaling simply by providing a container image, execution role, and infrastructure role. We investigate whether 20-second resolution can be applied to that automatic configuration.

The verification was performed with boto3 1.43.33 (released June 18, 2026). The monitoring and HighResolution metrics covered here were added to the SDK/CLI simultaneously with the feature release. If you want to try this with the AWS CLI, you will need a version that supports these additions.

Conclusion First

• High-resolution auto scaling is enabled by a two-part combination: "enabling 20-second resolution metrics on the service side" and "specifying the high-resolution predefined metric in the target tracking policy." This configuration worked on a standard ECS service.
• The API for operating Express mode has no field for specifying resolution.
• The underlying service automatically generated by Express used the default 60-second resolution.
• Directly rewriting the underlying standard service to 20 seconds temporarily allows the high-resolution policy to be accepted. However, Express management (canary deployments and reconcile) reverts it back to 60 seconds, making it impossible to maintain stably.
• For now, if you want to use high-resolution auto scaling, you will need to use a standard ECS service.

First, Confirm How to Enable It on a Standard ECS Service

Before looking at Express mode, let's clarify how to enable high-resolution auto scaling on a plain ECS service. Enabling it involves two settings that work together.

Enable 20-Second Resolution Metrics on the Service Side

monitoring has been added to CreateService/UpdateService. This is where you specify the collection resolution for CPUUtilization/MemoryUtilization.

{
  "monitoring": {
    "metricConfigurations": [
      {
        "metricNames": ["CPUUtilization", "MemoryUtilization"],
        "resolutionSeconds": 20
      }
    ]
  }
}

The valid values for resolutionSeconds are 20 or 60, and if unspecified, it defaults to the conventional 60 seconds. High-resolution metrics incur standard CloudWatch charges.

Use High-Resolution Predefined Metrics in the Target Tracking Policy

High-resolution predefined metrics have been added to Application Auto Scaling.

• ECSServiceAverageCPUUtilizationHighResolution
• ECSServiceAverageMemoryUtilizationHighResolution

The conventional ECSServiceAverageCPUUtilization is the 60-second version, while the one with HighResolution is the 20-second version. Specify the HighResolution version in your target tracking policy.

The Two Settings Have an Order Dependency

These two settings have an order dependency. If you try to create a high-resolution policy without first enabling 20-second resolution on the service side, it will be rejected.

ValidationException: High-resolution metrics are not fully enabled on the ECS service.

Furthermore, after enabling monitoring, there is a propagation delay before the high-resolution policy is accepted. This is a lag until metrics begin flowing; in the author's environment it was approximately 60 seconds. Attempting to create the policy immediately after enabling it results in the above error, but waiting a while allows it to go through.

Configuration Was Possible on a Standard Service

A standard Fargate service was created with the 20-second monitoring setting. A target tracking policy using ECSServiceAverageCPUUtilizationHighResolution was then registered on it. The result was that the policy was accepted and a CloudWatch alarm was also generated. On a standard ECS service, high-resolution auto scaling can be configured with this two-part combination.

Note that the goal here is not to measure actual scale-out time. Actual measurements on a standard service are left to the DevIO article mentioned earlier; this article limits itself to confirming that the configuration is accepted.

Verifying with Express Mode

Now for the main topic. We examined from three angles whether 20-second resolution can be applied to Express mode auto scaling.

The Express API Has No Field for Specifying Resolution

Express mode is operated via CreateExpressGatewayService and UpdateExpressGatewayService. Auto scaling is specified with a structure called scalingTarget, and its contents consist of only these four items.

• minTaskCount
• maxTaskCount
• autoScalingMetric (AVERAGE_CPU/AVERAGE_MEMORY/REQUEST_COUNT_PER_TARGET)
• autoScalingTargetValue

There are no fields corresponding to monitoring or resolutionSeconds that exist in the standard service. In short, the API for operating Express mode simply does not provide a way to specify 20-second resolution.

The Underlying Service Created by Express Uses the Default 60-Second Resolution

Express mode automatically generates a standard ECS service and an Application Auto Scaling policy as its actual implementation. Checking the generated underlying resources, the service had no monitoring configuration (meaning the default 60-second resolution). The target tracking policy also uses the 60-second version, ECSServiceAverageCPUUtilization. Express mode is configured with 60-second resolution by default.

Even Directly Rewriting the Underlying Service, Express Reverts It to 60 Seconds

One selling point of Express mode is that "you can also access the underlying resources directly." With that in mind, we considered whether it would be possible to directly apply UpdateService with 20-second monitoring to the underlying standard service and replace the policy with a high-resolution one, and we tried it.

The results were as follows.

• Applying 20-second monitoring via UpdateService allowed the high-resolution policy to be accepted after propagation (approximately 60 seconds later).
• However, after some time the settings reverted, and the high-resolution policy began being rejected again.
• During periods when Express mode updates or canary deployments were in progress, there were windows where re-applying monitoring was not accepted.

Express mode continuously manages the service state. In the course of canary deployments and reconcile (convergence to the desired state), it overwrites the monitoring settings we applied and reverts them to 60-second resolution. While the settings could be applied momentarily, they could not be maintained stably.

For isolation purposes, performing the same 20-second UpdateService change on a plain standard service resulted in the high-resolution policy being accepted without issue after propagation, and remaining in place thereafter. The procedure itself is correct, and the conclusion is that Express mode's management mechanism is reverting the settings.

In Closing

We verified whether high-resolution (20-second) auto scaling for ECS can be used with Express mode.

For a standard ECS service, it can be configured with the two-part combination of the 20-second monitoring setting and the HighResolution predefined metric. Express mode, on the other hand, has no field for specifying resolution in its operating API, and defaults to 60-second resolution. Even directly rewriting the underlying standard service proved unstable, as Express's management mechanism reverted the changes.

If you want to properly use high-resolution auto scaling, you will need to use a standard ECS service for now. The outcome reveals a clear trade-off in Express mode: it enables quick deployment with minimal configuration, but does not accommodate this kind of fine-grained tuning. If a resolution option is added to Express mode's scaling configuration in the future, this situation may change.