ECS Deployment Strategies: When Rolling Updates Break and What to Do Instead

When rolling update is enough

Rolling update is the right choice for most ECS services: stateless APIs, background workers, and anything with short-lived HTTP connections. The ECS circuit breaker (enabled by default since 2024) handles bad deploys automatically.

The circuit breaker threshold is max(3, min(0.5 × desiredCount, 200)). For a 4-task service, ECS will roll back automatically after 3 consecutive task failures. For a 100-task service, the threshold is 50 failed tasks. Once triggered, ECS rolls back by redeploying the last successful task definition — no manual intervention.

ECS Native Blue/Green (July 2025)

AWS launched built-in ECS blue/green on July 18, 2025. No CodeDeploy required, no AppSpec files, no separate application resource. Set strategy: BLUE_GREEN on your ECS service, point it at two ALB target groups, and ECS manages the rest.

The mechanism: ECS stores an immutable snapshot of your service config called a service revision. When you deploy, ECS creates a new “green” task set registered to the secondary target group. Blue continues serving 100% of production traffic. After the green tasks pass health checks, ECS shifts the ALB listener rule weight from 100/0 to 0/100 (all-at-once), or incrementally for canary and linear strategies.

resource "aws_ecs_service" "my_service" {
  name            = "my-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 4

  deployment_configuration {
    strategy = "BLUE_GREEN"

    blue_green_configuration {
      deployment_ready_wait_time_in_seconds = 0  # all-at-once
      termination_wait_time_in_seconds      = 300

      deployment_lifecycle_hook {
        hook_target_arn = aws_lambda_function.smoke_test.arn
        lifecycle_stage  = "POST_SCALE_UP"
        role_arn         = aws_iam_role.ecs_hooks.arn
      }
    }
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.blue.arn
    container_name   = "my-service"
    container_port   = 8080
  }

  # Second target group for green traffic
  load_balancer {
    target_group_arn = aws_lb_target_group.green.arn
    container_name   = "my-service"
    container_port   = 8080
  }

  # Required: prevent Terraform from reverting ECS-managed task def updates
  lifecycle {
    ignore_changes = [task_definition]
  }
}

The 7 lifecycle hooks (PRE_SCALE_UP, POST_SCALE_UP, TEST_TRAFFIC_SHIFT, and 4 more) are Lambda functions that ECS polls every 30 seconds. Each hook returns SUCCEEDED, FAILED, or IN_PROGRESS. A hook that returns FAILED aborts the deployment and triggers rollback. This is where you run smoke tests, DB migration validation, or health checks against the test listener — before any production user sees the new version.

For teams already using CodeDeploy: AWS removed the CODE_DEPLOY controller type from the ECS console in early 2026 and published a migration guide. The native approach has no AppSpec files, longer lifecycle hook timeouts (up to 24 hours per stage vs CodeDeploy's 1-hour total limit), and supports ECS Service Connect which CodeDeploy never did.

Decision table — pick your strategy

Start with rolling update. Add blue/green only when your service hits one of the three failure modes. Use canary in production when your team needs evidence of gradual rollout — either for operational confidence or compliance.

Don't blue/green dev and staging environments — the ALB cost ($0.008/hour per LCU, roughly $7–15/month per ALB) adds up fast across 10+ environments. Use rolling update there, save blue/green for production. If you're already running environment scheduling to cut non-prod costs, adding a second ALB per environment would offset most of those savings.