I tried the new ECS rolling deployment feature "Early Success Criteria"

Introduction

On September 4, 2026, Early Success Criteria was added to Amazon ECS rolling deployments.

https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ecs-introduces-early-success-criteria-for-service/

To try out the new feature, I prepared a Fargate service for validation and checked the deployment time by changing the early success determination conditions.

Validation Details

Validation Environment

Here is the configuration of the service used for measurement.

What is Early Success Criteria

When Early Success Criteria is enabled, the deployment completes when the percentage of new tasks specified by healthyPercent becomes healthy. The timing for cleaning up tasks from the old revision is specified with sourceServiceRevisionCleanup. With BLOCKING, the deployment completes after waiting for drain to finish, while with DEFERRED, the drain wait can be separated from the deployment flow.

When setting healthyPercent to 20%, the deployment configuration would be as follows.

{
    "maximumPercent": 200,
    "minimumHealthyPercent": 10,
    "strategy": "ROLLING",
    "earlySuccessCriteria": {
        "enable": true,
        "healthyPercent": 20,
        "sourceServiceRevisionCleanup": "BLOCKING"
    }
}

This configuration was applied with update-service.

aws ecs update-service \
    --cluster <cluster name> \
    --service <service name> \
    --deployment-configuration '{
        "maximumPercent": 200,
        "minimumHealthyPercent": 10,
        "strategy": "ROLLING",
        "earlySuccessCriteria": {
            "enable": true,
            "healthyPercent": 20,
            "sourceServiceRevisionCleanup": "BLOCKING"
        }
    }' \
    --region ap-northeast-1

Measuring Deployment Time

I decreased healthyPercent gradually from 100%.

Since the configuration has no load balancer, the drain wait for deregistration is not included in the elapsed time. These are single-measurement values for each pattern.

The shortest time was achieved with Early 20%. The reason minimumHealthyPercent is lowered for the 40% and 20% patterns is to conform to the constraint mentioned above.

The difference in elapsed time between 60% and 40% was about 1 second. With BLOCKING, the drain wait for old tasks is long, so the difference in healthyPercent did not appear.

I checked the events recorded in the Action Logs for the baseline, Early 60%, and Early 20%.

https://dev.classmethod.jp/articles/amazon-ecs-action-logs-deployment-visibility/

First, the baseline.

Early 60% and Early 40% had nearly identical elapsed times. The statusReason changed to "met early success criteria."

With Early 20%, the time until the service revision became STABLE was slightly longer at 37 seconds, and SUCCESSFUL was recorded at 89 seconds.

The event name at deployment completion remains SERVICE_DEPLOYMENT_SUCCESSFUL; what changes is the wording of statusReason. For a normal completion it reads "Service deployment completed successfully.", and for a completion triggered by meeting the early success criteria it reads "Service deployment met early success criteria." This allows you to distinguish which path led to completion from the Action Logs.

Combining with DEFERRED

I measured by changing sourceServiceRevisionCleanup from BLOCKING to DEFERRED using the Early 20% configuration.

In configurations where ELB deregistration wait occurs, DEFERRED can separate the wait from the deployment completion determination, so a reduction in wait time can be expected. Since there is no ELB in this validation environment, no deregistration wait occurred, and the difference from BLOCKING was only about 8 seconds. Although not tested this time, configurations with ALB where DeregistrationDelay is set to a long value may show a larger difference.

Summary

By enabling Early Success Criteria, the time to deployment completion was reduced to nearly half.

In environments where multiple tasks are running and a temporary reduction in task count is acceptable, Early Success Criteria is an option for shortening the deployment completion wait. It is particularly effective when you want to advance CI/CD downstream processes that wait for deployment completion more quickly.

However, lowering healthyPercent and minimumHealthyPercent too much may result in an insufficient number of running tasks, which could impact the service.
In production environments, it is recommended to configure these settings carefully while balancing the reduction in deployment wait time with availability.