ECS Early Success Criteria: where your deployment rollback ends

Until now, an ECS rolling deployment only completed when four things were true at once: the target revision reached 100% of the desired count with every task running and healthy, neither the circuit breaker nor a CloudWatch alarm triggered a rollback, the alarm bake time elapsed, and the source revision tasks were cleaned up. That is an all-or-nothing contract, designed for a homogeneous fleet that launches in seconds.

earlySuccessCriteria, available for the ROLLING strategy in all commercial Regions and GovCloud (US), splits that contract in two. You declare a healthyPercent — the fraction of the desired count that must be running and healthy on the target revision — and ECS completes the deployment there. With a desired count of 100 and healthyPercent 90, the deployment turns SUCCESSFUL at task 90; the remaining ten launch afterwards through regular service scaling.

The motivating case is easy to recognize: GPU-accelerated inference. The tail of a fleet on specialized capacity does not launch at the speed of its head — the variable is hardware availability, not your container. The deployment stays open waiting for two tasks that depend on instance supply, the pipeline behind it queues, and the next deploy never starts. The same applies to the other side of the trade: services with long-lived connections, whose source revision is slow to drain and holds the deployment open for a reason that has nothing to do with the health of the new code.

Reading this as a faster deploy is reading it wrong. healthyPercent is not an accelerator — it is a declaration of where automatic protection ends. The documentation is explicit: after ECS completes the deployment, the circuit breaker and alarm-based rollback no longer roll the service back, including while the remaining tasks launch through regular service scaling.

Translated to on-call terms: with a desired count of 100 and healthyPercent 90, the last ten tasks launch without a net. If the ninety-fifth fails for a reason that only shows under real load — a connection pool running out, a secret that only resolves in one AZ, a per-instance license cap — ECS replaces it with the same target revision, repeatedly, without returning to the previous one. The failure mode is not the deployment failing; it is the deployment passing and the service degrading slowly, with the pipeline already green and the team already on another task.

The circuit breaker still protects what is left of the window, and its sensitivity matters. The default BOUNDED_PERCENT type multiplies the value (default 50) by the desired count and clamps the result between 3 and 200: with 100 desired tasks that is 50 tolerated failures before rollback; with 400, the 200 cap applies. Worse, with resetOnHealthyTask at true — the default — the counter resets on every healthy task, so interleaved failures never accumulate. Shortening the protected window with healthyPercent while leaving the circuit breaker on its permissive default is applying two relaxations at once and calling it speed.

Three constraints close the range before any opinion enters. First: healthyPercent must be greater than or equal to the service minimumHealthyPercent. If you kept the 100% replica-service default, there is no range at all — lowering minimumHealthyPercent is a prerequisite, and it governs how many tasks the scheduler may stop during the swap, which is a capacity decision, not a speed one.

Second: the value is rounded up against the desired count. With 3 tasks at 50%, the deployment completes at 2. With 10 at 80%, at 8. On a small service each percentage point is worth a whole task, and the time saved trends to zero: earlySuccessCriteria only pays on a large fleet or on slow capacity.

Third: ECS launches at least one task on the target revision and waits for it to become healthy before evaluating the percentage. And a task only counts as healthy after passing the health checks you configured — with a load balancer that means the target group health check, and with an essential container that defines a health check, both.

From there it is a risk decision, and a conditional one. Use 90% or more when the service is stateless behind an ALB and the health check exercises a real dependency, not a /healthz that returns 200 without touching anything. Stay at 100% — or leave the feature off — when the tail of tasks carries state, a shard or a per-instance license. And if the motivation is a slow pipeline, measure first: in a rolling deployment the time usually lives in healthCheckGracePeriodSeconds, in the container health check startPeriod and in the target group deregistration delay — none of which the success rule changes.

The feature invents no new status. The lifecycle stays IN_PROGRESS → SUCCESSFUL, the EventBridge service deployment state change events and CloudTrail records are the same, and a deployment that completed early shows up normally when you filter ListServiceDeployments by SUCCESSFUL. That is excellent for compatibility and terrible for auditing: no consumer of your event bus can tell rolled out fully apart from rolled out to 90% and handed the rest to autoscaling. If your change process needs that distinction — and under BACEN, PCI-DSS or SOX it does — the source is DescribeServiceDeployments, which returns the early success criteria configuration alongside the deployment.

There is a silent trap in the counters. While the deployment is in progress, DescribeServiceDeployments returns live counts; after it completes, it returns a snapshot from the moment of completion, in both cleanup modes. A dashboard reading task count from there will show 90 forever, even with 100 tasks running and even with the source revision still draining. The live count lives in DescribeServices, and nowhere else.

So the alarm that matters moves. Before, an EventBridge rule with eventName equal to SERVICE_DEPLOYMENT_FAILED covered most of the release risk; now it covers only the window up to healthyPercent. What deserves an alarm instead is the gap between desiredCount and runningCount on the target revision a few minutes after success, the number of task replacements per revision, and the age of source revision tasks in DEFERRED mode. None of those three comes for free.