Blue-green and canary deployments

A rolling deploy gets a bad version into production gradually, which also means a bad version stays partially in production while you notice and react. Blue-green and canary deployments are two different answers to the same question — how do you ship a new version while keeping an instant, reliable way to back out of it?

Advanced

3 min read

Blue-green: two full environments, one atomic switch

Blue-green deployment runs two complete, independent production environments — "blue" (currently live) and "green" (the new version) — at the same time. You deploy the new version entirely to green, verify it there while it receives zero real traffic, then switch the router (load balancer, DNS, or service mesh) to send all traffic to green in one move.

Rollback is just switching the router back to blue — no redeploy, no waiting, seconds not minutes. That's blue-green's core advantage: the fastest possible rollback, because the previous known-good version is still fully running, not torn down.

The cost is literal: you're running double the infrastructure for the duration of the cutover, and any change that touches shared state (the database) isn't cleanly blue-green-able — both environments hit the same database, so schema changes still need the expand/contract discipline regardless of which deployment strategy you use.

Canary: gradual traffic shift, not a full cutover

Canary deployment takes a different approach: deploy the new version alongside the old one, but shift a small percentage of real traffic to it — 5%, then 25%, then 100% — while watching error rates and latency at each step. If the canary's metrics look bad, you stop the rollout and drain traffic back to the old version before most users are ever affected.

Implementing this requires something capable of weighted traffic splitting — an ALB with weighted target groups, a service mesh (Istio, App Mesh), or a managed rollout tool. AWS CodeDeploy's CodeDeployDefault.ECSCanary10Percent5Minutes config, for example, shifts 10% of traffic, waits 5 minutes evaluating CloudWatch alarms, then shifts the rest — or automatically rolls back if an alarm fires during the wait.

resource "aws_codedeploy_deployment_group" "app" {
  deployment_config_name = "CodeDeployDefault.ECSCanary10Percent5Minutes"
 
  auto_rollback_configuration {
    enabled = true
    events  = ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]
  }
 
  alarm_configuration {
    alarms  = [aws_cloudwatch_metric_alarm.error_rate.alarm_name]
    enabled = true
  }
}

The trade-off: blast radius vs speed and complexity

Blue-green's rollback is nearly instant, but its failure detection is binary and manual — you either catch the problem in your pre-cutover verification, or 100% of traffic hits the bug the moment you switch. Canary limits the blast radius automatically: a bad deploy only affects the percentage of users currently on the canary stage, and automated rollback can react to metrics before a human notices. The price is complexity (traffic-splitting infrastructure, defining meaningful alarm thresholds) and a slower full rollout — canary stages that wait 5–15 minutes each mean a full deploy can take an hour instead of two minutes.

Choosing between them isn't binary

Many production setups combine ideas from both: a canary stage to catch obvious regressions with a small blast radius, promoted to a blue-green-style full cutover once the canary looks healthy, with the old fleet kept warm briefly as a fast-rollback safety net. The right choice depends on what a bad deploy actually costs you — a low-traffic internal tool can usually accept the higher blast radius of blue-green for its simplicity; a payments API generally can't.

Further reading

Check your understanding

A quick comprehension check — not tracked, not graded, just for you.

1. What is blue-green deployment's main advantage over a standard rolling deploy?

2. How does canary deployment limit the blast radius of a bad release compared to blue-green?

3. Why doesn't blue-green deployment avoid the need for the expand/contract migration pattern?

4. What is the main cost trade-off of blue-green deployment versus canary?