Rolling, Blue/Green, Canary or Linear? Choosing the Right Deployment Strategy on Amazon ECS
A simple guide to the four deployment strategies Amazon ECS now supports natively, with pros, cons, a comparison table, and how to switch between them in AWS CDK with just a few lines of code.
Every deployment carries a small risk: what if the new version has a bug? How much damage it causes depends on how you deploy.
Amazon ECS now supports four deployment strategies natively, with no AWS CodeDeploy needed. Here's a simple breakdown to help you pick the right one.
1. Rolling update (default)
ECS replaces old tasks with new ones a few at a time. New tasks get real traffic as soon as they're healthy.
- ✅ Simple and no extra cost
- ❌ Users hit bugs immediately, and rollback means redeploying
Best for: dev/test and low-risk services. Always enable the deployment circuit breaker so failed deployments roll back automatically.
2. Blue/green
ECS starts the new version (green) next to the current one (blue). After validation, all traffic switches to green at once. Blue stays alive for a short "bake time" so you can switch back instantly.
- ✅ Instant rollback, and you can test green before users see it
- ❌ Runs double tasks briefly, and everyone moves at once
Best for: most production services.
3. Canary
Like blue/green, but only a small percentage of users (e.g. 10%) go to the new version first. If all looks good, the rest follow.
- ✅ A bug only affects a small group, and you validate with real traffic
- ❌ Two versions run at once, so database changes must be backward compatible
Best for: user-facing apps where a bad release hurts.
4. Linear
Traffic moves in equal steps (10% → 20% → … → 100%) with a wait between each.
- ✅ The most gradual and safest option
- ❌ The slowest
Best for: high-traffic or business-critical services.
Quick comparison
| Strategy | Rollback | Extra cost | Speed |
|---|---|---|---|
| Rolling | Slow | None | Fast |
| Blue/green | Instant | Brief | Medium |
| Canary | Instant | Brief | Medium |
| Linear | Instant | Brief | Slow |
The safety net: automatic rollback
Attach CloudWatch alarms (like "too many 5xx errors") to your service. If an alarm fires during the deployment, ECS automatically moves traffic back to the old version. No manual action needed.
Switching strategies in AWS CDK
Blue/green, canary and linear need an Application Load Balancer with two target groups. After that, choosing a strategy takes just a few lines:
1
2
3
4
5
6
7
8
9
10
11
12
13
new ecs.FargateService(this, 'Service', {
cluster,
taskDefinition,
deploymentStrategy: ecs.DeploymentStrategy.CANARY,
canaryConfiguration: {
stepPercent: 10,
stepBakeTime: Duration.minutes(5),
},
deploymentAlarms: {
alarmNames: ['my-app-5xx-errors'],
behavior: ecs.AlarmBehavior.ROLLBACK_ON_ALARM,
},
});Want linear instead? Change
CANARY to LINEAR and canaryConfiguration to linearConfiguration.My recommendation
- Dev environment: Rolling + circuit breaker
- Production: Blue/green
- User-facing: Canary
- Critical, high traffic: Linear
What should I write about next? Vote in my poll: https://builder.aws.com/poll/3K9TWZQiNf2xqbtgKoto8wpRPYB_po
Which strategy do you use today? Let me know in the comments!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article