Blue/Green Nativo no ECS: o fim da dependência do CodeDeploy?

---

📌 Contexto: Este post é baseado no artigo oficial do AWS DevOps Blog publicado em fevereiro de 2026. A DeltaOps resume e contextualiza o conteúdo para equipes brasileiras que gerenciam workloads em ECS na AWS.

---

Em julho de 2025, a AWS embutiu Blue/Green deployment diretamente no Amazon ECS — sem CodeDeploy, sem peças móveis extras. Mas isso significa que o CodeDeploy virou legado? A resposta é: depende do seu cenário.

O que mudou em julho de 2025?

Por muito tempo, fazer um Blue/Green deployment em Amazon ECS com zero downtime exigia necessariamente o AWS CodeDeploy: você configurava um deployment group, integrações com CodePipeline, regras de traffic shifting e lifecycle hooks num serviço separado. Funcionava, mas adicionava complexidade operacional considerável.

Em julho de 2025, a equipe do ECS lançou o Blue/Green deployment nativo — toda a lógica de lifecycle hooks, bake time e rollback automático passou a viver dentro do próprio serviço ECS, sem a necessidade de gerenciar um serviço adicional.

✅ O que o ECS Nativo entrega agora:

• Lifecycle hooks via Lambda
• Bake time configurável
• Rollback automático por alarmes do CloudWatch
• Suporte a ALB com dois target groups
• Configuração via Terraform ou AWS CDK L2 (sem escape hatches)

Como funciona o modelo nativo?

O ECS-native blue/green provisiona um novo task set registrado num segundo target group (green) atrás do seu listener do Elastic Load Balancing. Quando o cutover é aprovado — manualmente ou por um lifecycle hook Lambda — o ECS faz uma troca all-at-once de 100% do tráfego para o ambiente green.

A versão blue permanece ativa durante o bake period configurado. Se algum alarme disparar durante esse período, o rollback é automático.

Exemplo de configuração em Terraform:

resource "aws_ecs_service" "this" {
  name            = "meu-servico"
  cluster         = aws_ecs_cluster.this.id
  task_definition = aws_ecs_task_definition.this.arn
  desired_count   = 3

  deployment_controller {
    type = "ECS" # Blue/Green nativo — sem CodeDeploy
  }

  deployment_circuit_breaker {
    enable   = true
    rollback = true
  }

  deployment_maximum_percent         = 200
  deployment_minimum_healthy_percent = 100

  # Alarmes do CloudWatch para rollback automático
  alarms {
    alarm_names = [
      aws_cloudwatch_metric_alarm.http_500_blue.alarm_name,
      aws_cloudwatch_metric_alarm.http_500_green.alarm_name,
    ]
    enable   = true
    rollback = true
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.blue.arn
    container_name   = "app"
    container_port   = 8080
  }

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.ecs_service.id]
    assign_public_ip = false
  }

  lifecycle {
    ignore_changes = [task_definition, desired_count]
  }
}

# Alarme de erros HTTP 500 — dispara rollback automático
resource "aws_cloudwatch_metric_alarm" "http_500_blue" {
  alarm_name          = "${var.stack_name}-Http-500-Blue"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "HTTPCode_Target_5XX_Count"
  namespace           = "AWS/ApplicationELB"
  period              = 60
  statistic           = "Sum"
  threshold           = 5

  dimensions = {
    TargetGroup  = aws_lb_target_group.blue.arn_suffix
    LoadBalancer = aws_lb.this.arn_suffix
  }
}

ECS Nativo vs. CodeDeploy: quando usar cada um?

	ECS Blue/Green Nativo	AWS CodeDeploy
Serviço adicional	❌ Não precisa	✅ Necessário
Traffic shifting	All-at-once apenas	Canary, Linear, All-at-once
Lifecycle hooks	✅ Via Lambda	✅ Via Lambda
Rollback automático	✅ Por alarmes	✅ Por alarmes
Multi-serviço coordenado	❌	✅ Via CodePipeline
Audit trail / governança	Básico	✅ Completo
Complexidade operacional	Baixa	Média/Alta
Suporte Terraform/CDK	✅ Nativo	Parcial

⚠️ Ponto de atenção: O ECS Nativo faz traffic shift all-at-once — 0% → 100% instantâneo para o green, seguido de bake time. Se você precisa de shift gradual (ex: 5% → 20% → 100%) com validação por métricas em cada etapa, o CodeDeploy continua sendo o caminho certo.

Guia de decisão rápido

Use ECS Blue/Green Nativo se:

• Você tem um serviço independente e o rollback por alarme é suficiente
• Quer reduzir a complexidade operacional do pipeline
• Está começando um projeto novo com Terraform ou CDK

Use AWS CodeDeploy se:

• Precisa de canary ou linear traffic shifting
• Tem deploy coordenado de múltiplos serviços via CodePipeline
• Exige auditoria formal e aprovações manuais no fluxo

Migrando do CodeDeploy para ECS Nativo

Se você já usa CodeDeploy com ECS e quer migrar, a AWS publicou um guia oficial de migração. O processo envolve mudar o Deployment Controller Type no CDK e reorganizar os lifecycle hooks para o módulo ECS.

O que isso significa para o seu ambiente?

Na prática, esse lançamento representa uma redução de complexidade operacional significativa para equipes que já usam ECS. Menos serviços para monitorar, menos pontos de falha potenciais e uma experiência de deploy mais coesa dentro do próprio ECS console.

Para equipes que adotam Infrastructure as Code com Terraform ou CDK, o ganho é ainda mais direto: a configuração inteira vive num único módulo, sem precisar gerenciar recursos do CodeDeploy separadamente no stack.

A AWS está consolidando mais funcionalidades dentro dos serviços core — e essa tendência deve continuar. Para equipes SRE que gerenciam múltiplos ambientes, menos moving parts significa menos toil e mais tempo para trabalho de valor.

---

💡 Recomendação DeltaOps: Para novos projetos em ECS, comece pelo modelo nativo. É mais simples, já tem suporte L2 no CDK e cobre a maioria dos casos de uso. Só adicione CodeDeploy quando o cenário exigir canary shift ou orquestração de múltiplos serviços.

---

Tags: Amazon ECS · Blue Green Deployment · AWS CodeDeploy · Terraform · DevOps · Zero Downtime · CI/CD · Fargate · SRE

Referência: Choosing between Amazon ECS Blue/Green Native or AWS CodeDeploy in AWS CDK — AWS DevOps Blog, fevereiro de 2026.