I Tried "Early Success Criteria," a New Feature for ECS Rolling Deployments

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-deployments-early-success/

To try the new feature, I set up a Fargate service for testing, changed the conditions used to determine early success, and checked how long deployments took.

Verification

Test environment

This is the configuration of the service used for measurement.

What is Early Success Criteria?

When Early Success Criteria is enabled, the deployment completes once the proportion of new tasks specified by healthyPercent become healthy. You specify the timing for cleaning up the tasks of the old revision with sourceServiceRevisionCleanup. With BLOCKING, the deployment completes after waiting for draining to finish, and with DEFERRED, the wait for draining can be detached from the deployment flow.

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

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

I applied this configuration with update-service.

aws ecs update-service \
    --cluster <クラスター名> \
    --service <サービス名> \
    --deployment-configuration '{
        "maximumPercent": 200,
        "minimumHealthyPercent": 10,
        "strategy": "ROLLING",
        "earlySuccessCriteria": {
            "enable": true,
            "healthyPercent": 20,
            "sourceServiceRevisionCleanup": "BLOCKING"
        }
    }' \
    --region ap-northeast-1

Measuring deployment time

I lowered healthyPercent step by step starting from 100%.

Because the configuration has no load balancer, the deregistration drain wait is not included in the duration. Each pattern was measured once.

The shortest was Early 20%. The reason minimumHealthyPercent is lowered in the 40% and 20% patterns is to comply with the constraint described above.

The difference in duration between 60% and 40% was about 1 second. With BLOCKING, the wait for draining the old tasks is long, so the difference in healthyPercent did not show up.

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 almost identical durations. The statusReason changed to "met early success criteria."

With Early 20%, the time until the service revision became STABLE was somewhat 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 normal completion it is "Service deployment completed successfully.", and for completion by meeting the early success criteria it is "Service deployment met early success criteria." From the Action Logs you can tell which path the deployment completed through.

Combining with DEFERRED

With the Early 20% setting, I changed sourceServiceRevisionCleanup from BLOCKING to DEFERRED and measured.

In configurations where waiting for ELB deregistration occurs, DEFERRED can detach that wait from the deployment completion determination, so a reduction in wait time can be expected. Because the test environment this time has no ELB, no deregistration wait occurred, and the difference from BLOCKING was only about 8 seconds. Although not verified this time, in configurations where DeregistrationDelay is set long on an ALB, a larger difference may appear.

Summary

With Early Success Criteria enabled, the time to deployment completion was cut by nearly half.

In environments that run multiple tasks and can tolerate a temporary decrease in the task count, Early Success Criteria is an option for shortening the wait for deployment completion. It is especially effective when you want to move faster through the downstream steps of a CI/CD pipeline that waits for deployment completion.

However, if you lower healthyPercent and minimumHealthyPercent too far, the number of running tasks may become insufficient and affect the service.
In production environments, I recommend configuring these settings carefully, balancing shorter deployment wait times against availability.