Automatic Rollback: Fail Backwards on Purpose
The best rollback is one you never have to trigger by hand. Bake the abort condition into the deploy so a regression reverts itself.
Every deploy is a hypothesis: "this version is at least as healthy as the last." A senior pipeline treats that hypothesis as falsifiable during the rollout and reverts the moment the evidence turns bad — no human in the loop, no 2 a.m. judgement call.
What a good rollback needs
- A known-good previous artifact — an immutable, versioned image or Lambda version you can point back to instantly.
- A health signal with teeth — a CloudWatch alarm on 5xx rate, latency, or a business metric, evaluated during traffic shifting.
- An automatic trigger — CodeDeploy's
autoRollbackConfiguration, or ECS circuit breakerrollback: true.
ECS deployment circuit breaker
For rolling ECS deployments (no CodeDeploy needed), the built-in deployment circuit breaker watches tasks fail to reach a steady state and rolls the service back to the last good task set on its own.
Rolling back should be the boring, well-rehearsed path — not the emergency you improvise. If your rollback needs a runbook longer than your deploy, fix the rollback first.
Example
# ECS rolling deploy with the circuit breaker doing the rollback for you
aws ecs create-service \
--cluster myapp-prod \
--service-name web \
--task-definition myapp:42 \
--desired-count 4 \
--deployment-configuration '{
"deploymentCircuitBreaker": { "enable": true, "rollback": true },
"minimumHealthyPercent": 100,
"maximumPercent": 200
}'
# If the new tasks never go healthy, ECS reverts to the prior task def
# automatically and marks the deployment ROLLED_BACK.When to use it
- A team wires a CloudWatch 5xx alarm to CodeDeploy so a spike in errors during a canary automatically halts and reverts the deployment.
- An ECS service with circuit breaker enabled rolls itself back within 2 minutes when three consecutive task starts fail their health checks.
- A Lambda alias shift pauses automatically and reverts to the previous version when the error rate CloudWatch alarm breaches the threshold.
More examples
CodeDeploy rollback on alarm
Configures CodeDeploy to roll back automatically when the deployment fails or when a CloudWatch alarm fires.
aws deploy update-deployment-group \
--application-name myapp \
--deployment-group-name myapp-prod \
--auto-rollback-configuration \
'enabled=true,events=[DEPLOYMENT_FAILURE,DEPLOYMENT_STOP_ON_ALARM]' \
--alarm-configuration \
'alarms=[{name=myapp-error-rate-high}],enabled=true'Lambda alias with rollback alarm
Deploys a Lambda alias shift with canary config so only 10% of traffic goes to the new version initially, enabling automatic rollback.
# Use CodeDeploy Lambda deployment with canary + alarm
aws deploy create-deployment \
--application-name myapp-lambda \
--deployment-group-name lambda-prod \
--deployment-config-name CodeDeployDefault.LambdaCanary10Percent5Minutes \
--revision revisionType=AppSpecContent,appSpecContent='{content:"{version:0.0,Resources:[{myFunction:{Type:AWS::Lambda::Function,Properties:{Name:myapp,Alias:prod,CurrentVersion:'$OLD_VER',TargetVersion:'$NEW_VER'}}}]}"}'Test rollback by simulating failure
Stops an in-flight deployment and triggers automatic rollback to verify the rollback path works before it is needed in a real incident.
# Manually stop a deployment to trigger rollback
DEPLOY_ID=$(aws deploy list-deployments \
--application-name myapp \
--deployment-group-name myapp-prod \
--query 'deployments[0]' --output text)
aws deploy stop-deployment \
--deployment-id $DEPLOY_ID \
--auto-rollback-enabled
Discussion