I tried reducing ECS deployment wait time from 242 seconds to 47 seconds
This page has been translated by machine translation. View original
Introduction
Updates related to ECS deployments and the CloudFormation/CDK that support them came in rapid succession entering July 2026. Updates directly impacting deployment speed have continued, including the GA of Express mode, the addition of Action Logs, and CDK's --express option support. At the recent AWS Summit Japan 2026, there were also sessions introducing ECS updates and optimization techniques.
The operational details of Express mode itself are summarized in a previous article.
In this article, we tested some of these in an evaluation environment and measured how much we could reduce ECS Fargate deployment times.
Verification Details
Verification Environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 |
| VPC | vpc-xxxxxxxxx (Default VPC) |
| Workload | Spring Petclinic (ARM64) |
| Task Count | 2 (Multi-AZ) |
| CPU / Memory | 512 / 1024 MiB |
| Container Image | ECR private repository (cached) |
| Deploy Circuit Breaker | Enabled |
Measurement method:
- Deploy trigger: Switching image tag
v1↔v2in task definition (same image, different tags) - Tool completion time: Wall clock time from command execution start to completion (measured with bash's
SECONDSvariable) - ECS deployment time:
startedAt→finishedAtfromdescribe-service-deployments - Action Logs:
SERVICE_DEPLOYMENT_IN_PROGRESS→SERVICE_REVISION_STABLE→SERVICE_DEPLOYMENT_SUCCESSFULtimestamps - Measured 3 times per pattern and averaged (Phase 5 only has 1 valid measurement due to conditions, listed as a reference value)
Verification Pattern Overview
| # | Pattern | Changes (diff from Phase 1) | Production Use |
|---|---|---|---|
| 1 | CFn standard + default | — | ○ |
| 2 | CFn standard + tuning | ECS parameter optimization | ○ |
| 3 | CFn Express + tuning | + Express mode (skip stabilization wait) | △ (when implementing separate stabilization checks) |
| 4 | CDK Express + tuning | + CDK-based Express (no TaskDefinition extraction needed) | △ (same as above) |
| 5 | CDK hotswap + tuning | CFn bypass (direct SDK calls) | ✗ (dev/test only) |
Results Summary
| # | Pattern | Tool Completion (avg) | vs Phase 1 | Production Use | Stabilization Wait |
|---|---|---|---|---|---|
| 1 | CFn standard + default | 242s (≈4.0 min) | Baseline | ○ | Yes |
| 2 | CFn standard + tuning | 222s (≈3.7 min) | -8% | ○ | Yes |
| 3 | CFn Express + tuning | 61s (≈1.0 min) | -75% | △ | No (separate check required) |
| 4 | CDK Express + tuning | 47s (≈0.8 min) | -81% | △ | No (separate check required) |
| 5 | CDK hotswap + tuning | 109s (≈1.8 min) ※reference | -55% | ✗ | Yes |
The speed improvement breaks down into three major steps.
- ECS parameter tuning (Phase 1→2): Reduces the ECS deployment itself by -14%. However, since it is rate-limited by CFn's polling interval, tool completion time improvement is only -8%
- CFn Express mode (Phase 2→3): Skipping CFn stabilization wait achieves -73% vs Phase 2 (-75% vs Phase 1). ECS deployment proceeds in the background
- CDK Express (Phase 3→4): Immediate detection of stack events in CDK achieves -23% vs Phase 3. No TaskDefinition extraction required
※ Phase 5 (hotswap) is a reference measurement using a different approach that bypasses CFn, and is separate from the 3 steps above.
Phase 1: Baseline Measurement
Default parameter settings:
| Parameter | Value |
|---|---|
| DeregistrationDelay | 300s |
| HealthCheckIntervalSeconds | 30s |
| HealthyThresholdCount | 5 |
| MinimumHealthyPercent | 100% |
| MaximumPercent | 200% |
| HealthCheckGracePeriod | 60s |
| Run | Image | Tool Completion | ECS Deploy | CFn Overhead |
|---|---|---|---|---|
| #1 | v1→v2 | 242s | 141s | 101s |
| #2 | v2→v1 | 242s | 130s | 112s |
| #3 | v1→v2 | 243s | 116s | 127s |
| Average | — | 242s | 129s | 113s |
Here is a breakdown of container startup. Since it is not a bottleneck, we will focus on the deployment flow going forward.
| Task | created → pullStart | pull time | pull → started |
|---|---|---|---|
| Task A | 14s | 5s | 14s |
| Task B | 13s | 4s | 17s |
The pull from ECR completed in 4–5 seconds, and container startup itself was fast with cached images.
Action Logs timeline for Run #1:
| Event | Timestamp (UTC) | Elapsed from deploy start |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 08:47:01 | 0s |
| SERVICE_REVISION_STABLE | 08:47:37 | 36s |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 08:49:21 | 140s |
It took approximately 104 seconds from SERVICE_REVISION_STABLE (36s) to SERVICE_DEPLOYMENT_SUCCESSFUL (140s). This interval includes the Deregistration Delay for old tasks and the stabilization wait. Of the 242-second tool completion time, ECS deployment accounted for 129 seconds, and the remaining 113 seconds were CFn polling and status check overhead — nearly half of the deployment time was spent on the CFn side.
Phase 2: ECS Parameter Tuning
The following parameters were changed. DeregistrationDelay shortens the drain wait for old tasks, while HealthCheck interval and threshold settings speed up health validation for new tasks. MinimumHealthyPercent is also set to parallelize the swap between old and new tasks.
| Parameter | Before | After |
|---|---|---|
| DeregistrationDelay | 300s | 5s |
| HealthCheckIntervalSeconds | 30s | 10s |
| HealthyThresholdCount | 5 | 2 |
| MinimumHealthyPercent | 100% | 50% |
| Run | Image | Tool Completion | ECS Deploy | CFn Overhead |
|---|---|---|---|---|
| #1 | v2→v1 | 242s | 121s | 121s |
| #2 | v1→v2 | 182s | 93s | 89s |
| #3 | v2→v1 | 242s | 119s | 123s |
| Average | — | 222s | 111s | 111s |
Action Logs timeline for Run #1:
| Event | Timestamp (UTC) | Elapsed from deploy start |
|---|---|---|
| SERVICE_DEPLOYMENT_IN_PROGRESS | 09:09:19 | 0s |
| SERVICE_REVISION_STABLE | 09:10:03 | 44s |
| SERVICE_DEPLOYMENT_SUCCESSFUL | 09:11:19 | 120s |
The interval from REVISION_STABLE → DEPLOYMENT_SUCCESSFUL was 76 seconds, reduced from the 104 seconds in Phase 1. The average ECS deployment time was 111 seconds, a -14% improvement over Phase 1. However, tool completion times for Run #1 and #3 remained at 242 seconds, the same as Phase 1. Since it is rate-limited by CFn's polling interval (approximately 60 seconds), even if the ECS deployment finishes early, it waits for the next poll. Only Run #2 was reduced to 182 seconds because polling happened to execute right after ECS deployment completed.
Phase 3: CloudFormation Express Mode
Please refer to the following article for details on how Express mode works.
In Express mode, updates involving TaskDefinition Replacement (replacement via new revision creation) could not be handled. Therefore, the TaskDefinition is extracted outside of CFn template management. The TaskDefinition property of the Service resource is 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
The deploy 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 | 62s |
| #2 | rev 8 | 61s |
| #3 | rev 9 | 61s |
| Average | — | 61s |
This was -75% vs Phase 1. Express mode reports stack update completion without waiting for ECS deployment stabilization to finish.
We verified the Action Logs timeline for Run #1. Since in Express mode the tool completion and ECS deployment completion occur at different times, we show it relative to tool completion.
| Event | Timestamp (UTC) | Elapsed from 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 | +approx. 58s |
At the time of tool completion, the ECS deployment is still in IN_PROGRESS state, and SERVICE_DEPLOYMENT_SUCCESSFUL is recorded in the background after tool completion.
Phase 4: CDK Express Mode (The Main Option)
The CDK command for running in Express mode:
cdk deploy --express --force
Since CDK handles Replacement-type updates (TaskDefinition new revision creation) internally, the template design changes required in Phase 3 are unnecessary.
| Run | Image | Tool Completion |
|---|---|---|
| #1 | v2→v1 | 47s |
| #2 | v1→v2 | 47s |
| #3 | v2→v1 | 47s |
| Average | — | 47s |
This was -81% vs Phase 1 and -23% vs CFn Express (61s). Phase 3 includes wait time for aws cloudformation wait polling intervals. On the other hand, CDK monitors stack events as a stream and can detect completion immediately, reducing that overhead. Just like Phase 3, the stabilization wait is skipped.
Phase 5: CDK hotswap (Reference)
Hotswap is a mode that bypasses CFn and directly calls update-service via SDK. Since drift occurs, continuous measurement is difficult, and only one valid measurement was obtained.
| Run | Image | Tool Completion | Notes |
|---|---|---|---|
| #1 | v2→v1 | 109s | With stabilization wait |
| #2 | v1→v2 | 9s | Immediate failure due to CFn drift detection (excluded) |
The representative value is Run #1 at 109 seconds (-55% vs Phase 1, reference value).
- hotswap skips CFn but waits for ECS stabilization, making it slower than Express mode (47s)
- Drift must be resolved before the next regular deployment
- Not recommended for production (dev/test only)
Summary
In this verification, we fired deployments by registering task definition revisions outside the stack and switching the task definition referenced by the ECS Service. Via this approach, tuning Deregistration Delay and health check settings reduced the average ECS deployment time from 129 seconds to 111 seconds.
However, since CloudFormation standard mode waits for ECS deployment stabilization to complete, the improvement on the ECS side did not translate directly to tool completion time.
On the other hand, CloudFormation Express mode and CDK's --express option are choices that can reduce wait time while maintaining IaC management. In this evaluation environment, standard CloudFormation deployment took 242 seconds while CDK Express took 47 seconds, reducing the wait time until tool completion by approximately 81%.
In Express mode, stack update completion and ECS deployment stabilization completion occur at different times. Therefore, it is necessary to also check the ECS deployment status rather than judging deployment success based solely on CloudFormation success.
ECS Action Logs, real-time deployment visualization in the console, and expanded deploy circuit breaker configuration settings are available. Even after skipping the wait, it has become easier to understand deployment progress, success/failure, and behavior on failure.
In situations where faster feedback is prioritized over waiting for stabilization to complete — such as in development and test environments — the Express option is a strong candidate. Start by trying it in an evaluation environment, together with an ECS deployment verification method.
