I Tried Reducing ECS Deployment Wait Time from 242 Seconds to 47 Seconds
This page has been translated by machine translation. View original
Introduction
In July 2026, ECS deployments and the CloudFormation and CDK that support them have changed in quick succession. Updates that directly affect deployment speed have kept coming, including the GA of Express mode, the addition of Action Logs, and support for the --express option in CDK. At AWS Summit Japan 2026 the other day, there was also a session introducing ECS updates and optimization techniques.
The details of how Express mode itself works are summarized in a previous article.
In this article, I tried some of these in an evaluation environment and measured how much ECS Fargate deployment time can be reduced.
Verification Details
Verification Environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 |
| VPC | vpc-xxxxxxxxx (default VPC) |
| Workload | Spring Petclinic (ARM64) |
| Number of tasks | 2 (multi-AZ) |
| CPU / Memory | 512 / 1024 MiB |
| Container image | ECR private repository (cached) |
| Deployment circuit breaker | Enabled |
Measurement method:
- Deployment trigger: Switch the image tag in the task definition between
v1↔v2(same image, different tags) - Tool completion time: Wall clock time from command execution start to completion (measured with the bash
SECONDSvariable) - ECS deployment time:
startedAt→finishedAtfromdescribe-service-deployments - Action Logs: Timestamps of
SERVICE_DEPLOYMENT_IN_PROGRESS→SERVICE_REVISION_STABLE→SERVICE_DEPLOYMENT_SUCCESSFUL - Each pattern was measured 3 times and the average calculated (only Phase 5 had one valid run due to measurement conditions, and is listed as a reference value)
Overview of Verification Patterns
| # | Pattern | Changes (difference from Phase 1) | Production use |
|---|---|---|---|
| 1 | CFn normal + default | — | ○ |
| 2 | CFn normal + tuning | ECS parameter optimization | ○ |
| 3 | CFn Express + tuning | + Express mode (skips waiting for stabilization) | △ (if stabilization checks are implemented separately) |
| 4 | CDK Express + tuning | + Express via CDK (no need to split out TaskDefinition) | △ (same as above) |
| 5 | CDK hotswap + tuning | Bypasses CFn (direct SDK calls) | ✗ (dev/test only) |
Results Summary
| # | Pattern | Tool completion (avg) | vs. Phase 1 | Production use | Wait for stabilization |
|---|---|---|---|---|---|
| 1 | CFn normal + default | 242 sec (≈4.0 min) | Baseline | ○ | Yes |
| 2 | CFn normal + tuning | 222 sec (≈3.7 min) | -8% | ○ | Yes |
| 3 | CFn Express + tuning | 61 sec (≈1.0 min) | -75% | △ | No (separate check required) |
| 4 | CDK Express + tuning | 47 sec (≈0.8 min) | -81% | △ | No (separate check required) |
| 5 | CDK hotswap + tuning | 109 sec (≈1.8 min) ※ reference value | -55% | ✗ | Yes |
The speedup breaks down into three main steps.
- ECS parameter tuning (Phase 1→2): The ECS deployment itself is shortened by 14%. However, since it is rate-limited by CFn's polling interval, the tool completion time is only reduced by 8%
- CFn Express mode (Phase 2→3): Skipping the CFn stabilization wait yields -73% vs. Phase 2 (-75% vs. Phase 1). The ECS deployment proceeds in the background
- CDK Express (Phase 3→4): CDK's immediate detection of stack events yields -23% vs. Phase 3. No need to split out the TaskDefinition
※ Phase 5 (hotswap) is a reference measurement using a CFn bypass, and is a different approach from the three steps above.
Phase 1: Baseline Measurement
Parameters with default settings:
| Parameter | Value |
|---|---|
| DeregistrationDelay | 300 sec |
| HealthCheckIntervalSeconds | 30 sec |
| HealthyThresholdCount | 5 |
| MinimumHealthyPercent | 100% |
| MaximumPercent | 200% |
| HealthCheckGracePeriod | 60 sec |
| Run | Image | Tool completion | ECS deployment | CFn overhead |
|---|---|---|---|---|
| #1 | v1→v2 | 242 sec | 141 sec | 101 sec |
| #2 | v2→v1 | 242 sec | 130 sec | 112 sec |
| #3 | v1→v2 | 243 sec | 116 sec | 127 sec |
| Average | — | 242 sec | 129 sec | 113 sec |
This is the breakdown of container startup. Since it is not the bottleneck, we will focus on the deployment flow from here on.
| Task | created → pullStart | pull time | pull → started |
|---|---|---|---|
| Task A | 14 sec | 5 sec | 14 sec |
| Task B | 13 sec | 4 sec | 17 sec |
The pull from ECR completed in 4–5 seconds, and container startup itself was fast with a cached image.
Timeline for Run #1 from Action Logs:
| Event | Timestamp (UTC) | Elapsed since deployment start |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 08:47:01 | 0 sec |
| SERVICE_REVISION_STABLE | 08:47:37 | 36 sec |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 08:49:21 | 140 sec |
It takes about 104 seconds from SERVICE_REVISION_STABLE (36 sec) to SERVICE_DEPLOYMENT_SUCCESSFUL (140 sec). This interval is the stabilization wait, including the old tasks' Deregistration Delay. Of the 242 seconds of tool completion, the ECS deployment accounted for 129 seconds, and the remaining 113 seconds was overhead from CFn polling and status checks, so nearly half of the deployment time was CFn-side processing.
Phase 2: ECS Parameter Tuning
The following parameters were changed. DeregistrationDelay shortens the drain wait for old tasks, and the HealthCheck interval and threshold speed up the healthy determination of new tasks. MinimumHealthyPercent is intended to parallelize the replacement of old and new tasks.
| Parameter | Before | After |
|---|---|---|
| DeregistrationDelay | 300 sec | 5 sec |
| HealthCheckIntervalSeconds | 30 sec | 10 sec |
| HealthyThresholdCount | 5 | 2 |
| MinimumHealthyPercent | 100% | 50% |
| Run | Image | Tool completion | ECS deployment | CFn overhead |
|---|---|---|---|---|
| #1 | v2→v1 | 242 sec | 121 sec | 121 sec |
| #2 | v1→v2 | 182 sec | 93 sec | 89 sec |
| #3 | v2→v1 | 242 sec | 119 sec | 123 sec |
| Average | — | 222 sec | 111 sec | 111 sec |
Timeline for Run #1 from Action Logs:
| Event | Timestamp (UTC) | Elapsed since deployment start |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 09:09:19 | 0 sec |
| SERVICE_REVISION_STABLE | 09:10:03 | 44 sec |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 09:11:19 | 120 sec |
The interval between REVISION_STABLE and DEPLOYMENT_SUCCESSFUL was 76 seconds, shortened from 104 seconds in Phase 1. The ECS deployment time averaged 111 seconds, -14% vs. Phase 1. However, the tool completion time for Runs #1 and #3 is 242 seconds, the same as Phase 1. Because it is rate-limited by CFn's polling interval (about 60 seconds), even if the ECS deployment finishes early, you have to wait until the next poll. Only in Run #2 did polling run right after the ECS deployment completed, so it was shortened to 182 seconds.
Phase 3: CloudFormation Express Mode
For details on how Express mode works, see the following article.
Express mode could not handle updates involving a TaskDefinition Replacement (replacement by creating a new revision). Therefore, I split the TaskDefinition out of the CFn template's management. The TaskDefinition property of the Service resource was designed to receive the ARN via a parameter.
Parameters:
TaskDefinitionArn:
Type: String
Description: Task Definition ARN (managed outside this stack)
Resources:
ECSService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: !Ref TaskDefinitionArn
# DeploymentConfiguration, NetworkConfiguration, etc. omitted
This is the deployment command in Express mode.
aws cloudformation update-stack \
--stack-name ecs-deploy-bench \
--use-previous-template \
--parameters ParameterKey=TaskDefinitionArn,ParameterValue=arn:aws:ecs:ap-northeast-1:123456789012:task-definition/petclinic:9 \
--deployment-config '{"Mode":"EXPRESS"}'
| Run | TaskDef Rev | Tool completion |
|---|---|---|
| #1 | rev 9 | 62 sec |
| #2 | rev 8 | 61 sec |
| #3 | rev 9 | 61 sec |
| Average | — | 61 sec |
This was -75% vs. Phase 1. Express mode reports stack update completion without waiting for the ECS deployment to finish stabilizing.
I checked the timeline for Run #1 from Action Logs. Because the timing of tool completion and ECS deployment completion differs in Express mode, the times are shown relative to the tool completion point.
| Event | Timestamp (UTC) | Elapsed since tool completion |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 09:40:37 | Before tool completion |
| SERVICE_REVISION_STABLE | 09:41:06 | Before tool completion |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 09:42:35 | +about 58 sec |
At the point of tool completion, the ECS deployment is still in the IN_PROGRESS state, and SERVICE_DEPLOYMENT_SUCCESSFUL is recorded in the background after the tool completes.
Phase 4: CDK Express Mode (The Main Candidate)
This is the command to run Express mode with CDK.
cdk deploy --express --force
CDK handles Replacement-type updates (creating a new TaskDefinition revision) internally, so the template design changes that were needed in Phase 3 are unnecessary.
| Run | Image | Tool completion |
|---|---|---|
| #1 | v2→v1 | 47 sec |
| #2 | v1→v2 | 47 sec |
| #3 | v2→v1 | 47 sec |
| Average | — | 47 sec |
This was -81% vs. Phase 1 and -23% vs. CFn Express (61 sec). Phase 3 includes waiting for the polling interval of aws cloudformation wait. In contrast, CDK monitors stack events as a stream, so it can detect completion immediately, and that overhead is eliminated. As in Phase 3, the stabilization wait is skipped.
Phase 5: CDK hotswap (Reference)
hotswap is a mode that bypasses CFn and calls update-service directly via the SDK. Drift occurs, making consecutive measurements difficult, so there was only one valid measurement.
| Run | Image | Tool completion | Notes |
|---|---|---|---|
| #1 | v2→v1 | 109 sec | With stabilization wait |
| #2 | v1→v2 | 9 sec | Failed immediately due to CFn drift detection (excluded) |
The representative value is 109 seconds from Run #1 (-55% vs. Phase 1, reference value).
- hotswap skips CFn, but it waits for ECS stabilization, so it is slower than Express mode (47 sec)
- Drift needs to be resolved before the next normal deployment
- Not recommended for production (dev/test only)
Summary
In this verification, I triggered deployments by registering task definition revisions outside the stack and switching the task definition referenced by the ECS Service. On this path, tuning such as Deregistration Delay and health check settings reduced the ECS deployment time from an average of 129 seconds to 111 seconds.
However, because CloudFormation normal mode waits for the ECS deployment to finish stabilizing, the ECS-side reduction did not translate directly into tool completion time.
On the other hand, CloudFormation Express mode and CDK's --express option are choices that can shorten the wait time while keeping IaC management. In this evaluation environment, a normal CloudFormation deployment took 242 seconds and CDK Express took 47 seconds, reducing the wait time until tool completion by about 81%.
With Express mode, stack update completion and ECS deployment stabilization completion occur at different times. Therefore, you should not judge a deployment as successful based solely on CloudFormation success; you also need to check the ECS-side deployment status.
ECS Action Logs, the console's real-time deployment visualization, and extended deployment circuit breaker settings are available. They make it easier to grasp the deployment's progress, success or failure, and behavior on failure even after skipping the wait.
For situations such as development and test environments, where you want to prioritize quick feedback over waiting for stabilization to complete, the Express option is a strong choice. Please try it first in an evaluation environment, together with a method for checking the ECS deployment.
