Blue-Green Deployments in AWS: ECS, EC2, Route 53 & Rollback

A blue-green deployment runs two identical production environments simultaneously. Blue serves all live traffic. You deploy the new version to green, verify it is healthy, then switch all traffic from blue to green in one step. If something breaks, you switch back instantly. Blue is still running. This approach eliminates deployment downtime and makes rollback a matter of seconds rather than minutes. The main cost is paying for two environments during the cutover window, typically 15 to 30 minutes.

Blue-green deployments explained simply#

In practice: you spin up a completely separate set of servers called green, deploy the new version there, and run your checks. Users still hit blue the whole time. Once green is confirmed healthy, you flip the switch. All traffic goes to green. Blue sits idle.

If green starts throwing errors after the switch, you flip back to blue. No reinstalling, no rollback scripts, no downtime.

How blue-green deployment works in AWS#

Every blue-green deployment follows this sequence, whether you use ECS, EC2, or Route 53:

1. Keep blue live. Blue is your current production environment. Users hit it normally throughout the entire deployment.
2. Deploy to green. Provision the new environment: a new ECS task set, a new EC2 Auto Scaling Group, or a separate ALB target. Deploy the new version there.
3. Run health checks and smoke tests. Wait for ALB health checks to pass. Test the green endpoint directly before touching live traffic.
4. Switch traffic. Update the ALB listener rule, let CodeDeploy shift target groups, or update Route 53 weights to send all traffic to green.
5. Monitor. Watch your CloudWatch alarms for error rates, latency spikes, and application-specific signals. This is your rollback window.
6. Roll back instantly if needed. Reverse the traffic switch. Blue is still running, so rollback takes seconds with no rebuild required.
7. Clean up blue. After the monitoring window closes without incident, terminate the blue environment and delete idle resources.

When to use blue-green deployments#

Blue-green is the right choice when:

• Your service is customer-facing and cannot tolerate any downtime. An in-place restart window is not acceptable.
• You need instant rollback. If something goes wrong after deploy, you want to recover in seconds.
• Mixed-version behavior is risky. If version 2 uses a different session format that version 1 cannot read, routing users to both versions simultaneously breaks half your sessions.
• You are doing a significant cutover. A major dependency upgrade, a new runtime, or a large infrastructure change where you want a clean, pre-tested environment before touching live traffic.

For teams managing multiple environments through staging and production, blue-green is a natural fit for the final production promotion step.

When not to use blue-green deployments#

Blue-green is not always the right tool:

• When doubling capacity briefly is too expensive. For large EC2-backed services, two full environments for 30 minutes adds up. A canary or rolling deployment may be a better fit.
• When the database schema is not backward-compatible. If green requires a column rename or a dropped field that blue still reads, both environments cannot safely share the same database during the transition.
• When your app cannot run two versions simultaneously. Stateful services or singleton processes, like a background job processor holding a distributed lock, may break if two versions are running at once.
• When a canary is a better fit. If you want to validate the new version gradually under real production traffic before committing, canary deployments give you more control over the rollout pace.

Blue-green with ECS and CodeDeploy#

For ECS services, AWS CodeDeploy manages blue-green deployments by maintaining two ECS task sets and shifting traffic between them using ALB target groups. The traffic switch happens at the Application Load Balancer level, instantly with no TTL delay, and CodeDeploy handles rollback automatically.

What CodeDeploy is doing: It starts a new task set (green) in the second target group, waits for ALB health checks to pass across all tasks, then updates the ALB listener rule to route production traffic from the blue target group to green. After a configurable wait period, it terminates the original task set.

Configure the ECS service for CodeDeploy deployments:

{
  "deploymentController": {
    "type": "CODE_DEPLOY"
  },
  "loadBalancers": [
    {
      "targetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/my-app-1/...",
      "containerName": "my-app",
      "containerPort": 8080
    }
  ]
}

Create the CodeDeploy application and deployment group:

aws deploy create-application \
  --application-name my-app \
  --compute-platform ECS

aws deploy create-deployment-group \
  --application-name my-app \
  --deployment-group-name my-app-prod \
  --deployment-config-name CodeDeployDefault.ECSAllAtOnce \
  --service-role-arn arn:aws:iam::123456789012:role/CodeDeployRole \
  --ecs-services '[{"serviceName": "my-app", "clusterName": "prod-cluster"}]' \
  --load-balancer-info '{
    "targetGroupPairInfoList": [{
      "targetGroups": [
        {"name": "my-app-1"},
        {"name": "my-app-2"}
      ],
      "prodTrafficRoute": {
        "listenerArns": ["arn:aws:elasticloadbalancing:...:listener/..."]
      }
    }]
  }' \
  --auto-rollback-configuration '{
    "enabled": true,
    "events": ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]
  }'

Blue-green with EC2 Auto Scaling Groups#

For EC2-backed services, blue-green deployments use two separate Auto Scaling Groups. The blue ASG serves production traffic through the load balancer. You create a green ASG with a new launch template version, let it scale up and become healthy, attach it to the load balancer, then detach and eventually terminate blue.

# Step 1: Create green ASG with the new launch template version
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-app-green \
  --launch-template LaunchTemplateId=lt-abc123,Version=2 \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 4 \
  --vpc-zone-identifier "subnet-abc,subnet-def"

# Step 2: Wait for green instances to pass health checks
aws autoscaling wait instance-in-service \
  --auto-scaling-group-name my-app-green

# Step 3: Attach green ASG to the load balancer target group
aws autoscaling attach-load-balancer-target-groups \
  --auto-scaling-group-name my-app-green \
  --target-group-arns arn:aws:elasticloadbalancing:...:targetgroup/my-app/...

# Step 4: Detach blue ASG (all traffic now flows to green)
aws autoscaling detach-load-balancer-target-groups \
  --auto-scaling-group-name my-app-blue \
  --target-group-arns arn:aws:elasticloadbalancing:...:targetgroup/my-app/...

# Step 5: Monitor for 15-30 minutes, then terminate blue
aws autoscaling delete-auto-scaling-group \
  --auto-scaling-group-name my-app-blue \
  --force-delete

The gap between step 4 and step 5 is your rollback window. If a monitoring alarm fires, reattach blue to the load balancer and detach green. Traffic is back on blue in seconds. Do not skip this window.

Blue-green with Route 53 weighted records#

Route 53 weighted routing can split DNS queries between two endpoints: two ALBs, two CloudFront distributions, or two API Gateway stages. This enables blue-green deployments at the DNS level, useful when both environments cannot share a single ALB.

# Set blue to 100% and green to 0%; to cut over, reverse the weights
aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXXXXXXXXXXXX \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "blue",
          "Weight": 100,
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "blue-alb.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      },
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "green",
          "Weight": 0,
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "green-alb.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

Route 53 weighted switching suits coarser scenarios: regional failover, switching between two completely separate stacks, or gradually shifting traffic between regions. For application-layer blue-green where you need precision and instant rollback, prefer ALB-level switching via CodeDeploy or a direct listener rule update. See DNS with Route 53 for more on TTL behaviour and weighted routing.

Application blue-green vs RDS Blue/Green Deployments#

These are two related but distinct concepts, and conflating them causes real problems.

Application blue-green is what most of this page covers: two versions of your application, one shared database, traffic switched at the ALB or DNS level. Both blue and green connect to the same RDS instance or Aurora cluster during the transition.

RDS Blue/Green Deployments is a separate AWS-managed feature for making changes to the database itself: engine version upgrades, major parameter group changes, or schema migrations that AWS manages end-to-end. AWS creates a synchronised green database, lets you test it, then switches the writer endpoint. It is a complementary tool, not a substitute for application-layer blue-green.

For application blue-green, the practical implication is this: schema changes must be backward-compatible. You cannot ship a column removal or rename in the same deployment as the application code that depends on it, because blue is still reading the old schema during the transition.

The standard approach is the expand-contract pattern:

1. Deploy an additive schema migration first (add new columns, keep old ones).
2. Deploy the application change so green uses the new schema while blue ignores it.
3. After blue is terminated and the monitoring window closes, clean up the old columns in a follow-up migration.

Blue-green vs canary vs rolling update#

How to choose: If downtime or mixed-version behavior is unacceptable, use blue-green. If you want to validate the new version incrementally under real traffic before committing, use canary. If your service tolerates brief mixed-version state and cost is a constraint, use rolling. You can also combine strategies: blue-green to stand up the new environment, then a short canary phase before full cutover.

Common mistakes#

Pre-cutover checklist#

Before switching any traffic to green, confirm:

• ALB health checks configured and passing on all green instances or tasks
• Smoke tests run against the green endpoint directly (not through production DNS)
• CloudWatch alarms in place with notification targets confirmed
• Rollback steps documented and tested: can you switch back in under 2 minutes?
• Automatic rollback enabled in CodeDeploy (if applicable)
• Schema migrations already deployed and confirmed backward-compatible with blue
• Two target groups configured and both listed in the CodeDeploy deployment group (ECS)
• TTL lowered to 60 seconds (if using Route 53 DNS switching)
• Monitoring window duration agreed with the team
• Cleanup plan defined: who terminates blue, and when

Last verified: 25 April 2026 · Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.