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

Hello. This is Takeda from the Service Development Division.

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 start scale-out was reduced from 363 seconds to 86 seconds (76% reduction), and even including the time for new tasks to finish launching, it dropped from 386 seconds to 109 seconds (72% reduction). This update makes it easier to lower baseline task counts to reduce costs while still responding quickly to sudden load spikes.

We have verified in a separate article whether enabling this feature on a standard ECS service actually speeds up scale-out.

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 application with just three settings. Express mode is a simplified deployment feature that automatically configures everything from the ALB to auto scaling just by providing a container image, execution role, and infrastructure role. We verify whether the 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-suffixed metrics covered this time were added to the SDK/CLI simultaneously with the feature release. If you 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 high-resolution predefined metrics in the target tracking policy." This configuration worked with 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 allows the high-resolution policy to be accepted temporarily. However, Express management (canary deployments and reconciliation) reverts it back to 60 seconds, so it could not be maintained stably.
• For now, if you want to use high-resolution auto scaling, you will need to choose a standard ECS service.

First, Confirm How to Enable It on Standard ECS

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

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 values you can specify for resolutionSeconds are 20 or 60; 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 versions of predefined metrics have been added to Application Auto Scaling.

• ECSServiceAverageCPUUtilizationHighResolution
• ECSServiceAverageMemoryUtilizationHighResolution

The conventional ECSServiceAverageCPUUtilization is the 60-second version, and the HighResolution-suffixed version is the 20-second version. You specify the HighResolution-suffixed one in the target tracking policy.

There Is an Order Dependency Between the Two

There is an order dependency between these two. 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.

Moreover, there is a propagation delay between enabling monitoring and when the high-resolution policy is accepted. This is a lag before metrics start flowing; in the author's environment it was approximately 60 seconds. The behavior was that creating a policy immediately after enabling it would result in the above error, but waiting a while would allow it to go through.

It Could Be Configured 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 measuring the actual scale-out time is not the purpose here. Actual measurements on a standard service are left to the Developers.IO article mentioned earlier; this article only confirms that the configuration goes through.

Verifying with Express Mode

Here is the main topic. We checked 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 consisted of only these four items.

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

There are no fields equivalent to monitoring or resolutionSeconds that exist in standard services. This means that the API for operating Express mode simply does not provide a way to specify 20-second resolution in the first place.

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

Express mode automatically generates a standard ECS service and Application Auto Scaling policy as its actual implementation. Checking the generated underlying resources, there was no monitoring setting on the service (i.e., the default 60-second resolution). The target tracking policy also used the 60-second version, ECSServiceAverageCPUUtilization. Express mode defaults to a 60-second resolution configuration.

Even If You Directly Rewrite the Underlying Resources, Express Reverts Them to 60 Seconds

One of the selling points of Express mode is that you can also directly access the underlying resources. With that in mind, we tried directly applying 20-second monitoring to the underlying standard service via UpdateService and replacing the policy with a high-resolution one.

The results were as follows.

• After applying 20-second monitoring via UpdateService, the high-resolution policy was accepted after propagation (approximately 60 seconds later).
• However, after a while the settings reverted, and the high-resolution policy started being rejected again.
• While an Express mode update or canary deployment was in progress, there were periods when re-applying monitoring would not be accepted.

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

For comparison, performing the same 20-second conversion via UpdateService on a plain standard service resulted in the high-resolution policy being accepted without issue after propagation and remaining in place afterward. This means 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 on ECS can be used with Express mode.

With a standard ECS service, it can be configured using the two-part combination of the 20-second monitoring setting and the HighResolution-suffixed predefined metrics. 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 was unstable, as Express's management mechanism reverted the settings.

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