Zero-Downtime Strategies That Actually Hold Up
Blue/green and canary releases let you ship without anyone noticing — here's how the pros wire them so a bad build never reaches the crowd.
By the time you're deploying multiple times a day, "take the site down for maintenance" stops being acceptable. The two strategies that carry real production traffic are blue/green and canary, and on AWS you rarely hand-roll them — you lean on CodeDeploy traffic shifting or an ECS/Lambda deployment controller to do the choreography.
Blue/green in one breath
You stand up a complete green copy of your service beside the live blue one. The load balancer flips traffic to green in one atomic move once green passes its health checks. If something's wrong, you flip back — the old version was never torn down.
Canary, more surgically
Instead of an all-or-nothing flip, a canary sends a small slice (say 10%) of traffic to the new version, watches your alarms for a few minutes, then shifts the rest. CodeDeploy ships named configs like Canary10Percent5Minutes and Linear10PercentEvery1Minute so you don't invent the math.
The rule that separates seniors from the rest
A deploy strategy is only as good as the signal that aborts it. Wire a CloudWatch alarm (error rate, p99 latency) into the deployment so a spike triggers an automatic rollback before you've even opened Slack.
Example
// appspec + deployment config for an ECS blue/green via CodeDeploy
{
"deploymentConfigName": "CodeDeployDefault.ECSCanary10Percent5Minutes",
"blueGreenDeploymentConfiguration": {
"terminateBlueInstancesOnDeploymentSuccess": {
"action": "TERMINATE",
"terminationWaitTimeInMinutes": 5
},
"deploymentReadyOption": {
"actionOnTimeout": "STOP_DEPLOYMENT",
"waitTimeInMinutes": 10
}
},
"alarmConfiguration": {
"enabled": true,
"alarms": [{ "name": "myapp-prod-5xx-high" }]
},
"autoRollbackConfiguration": {
"enabled": true,
"events": ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]
}
}When to use it
- A fintech team deploys a payment API with CodeDeploy blue-green so the switch is instant and users mid-transaction are never interrupted.
- An ops engineer uses ECS deployment circuit breaker so a bad container image never fully replaces healthy tasks — the service automatically reverts.
- A company sets minimumHealthyPercent=100 and maximumPercent=200 on their ECS service so new tasks are always started before any old ones are stopped.
More examples
ECS zero-downtime deployment config
Updates ECS with 100% minimum healthy to ensure new tasks come up before old ones are killed, with auto rollback on failure.
aws ecs update-service \
--cluster prod \
--service myapp \
--task-definition myapp:9 \
--deployment-configuration \
'minimumHealthyPercent=100,maximumPercent=200,deploymentCircuitBreaker={enable=true,rollback=true}'ALB deregistration delay tuning
Reduces ALB connection drain time to 30 seconds so rolling deploys complete faster without stranding long connections.
# Lower deregistration delay so the old task drains quickly
aws elbv2 modify-target-group-attributes \
--target-group-arn $TG_ARN \
--attributes \
Key=deregistration_delay.timeout_seconds,Value=30CodeDeploy blue-green with test traffic
Runs health and smoke test hooks between traffic shifts so traffic only moves to green once tests confirm it is ready.
# appspec.yml hooks for blue-green ECS deploy
Hooks:
- BeforeAllowTraffic: ValidateGreenHealth
- AfterAllowTraffic: RunSmokeTests
- AfterAllowTestTraffic: IntegrationTests
Discussion