ECS Early Success Criteria: onde termina o rollback do seu deploy

Até agora, um rolling deployment do ECS só fechava quando quatro coisas eram verdade ao mesmo tempo: a revisão alvo chegava a 100% do desired count com todas as tasks rodando e saudáveis, nem o circuit breaker nem o alarme do CloudWatch disparavam rollback, o bake time do alarme passava, e as tasks da revisão fonte eram limpas. É um contrato de tudo ou nada, desenhado para frota homogênea que sobe em segundos.

O earlySuccessCriteria, disponível para a estratégia ROLLING em todas as regiões comerciais e no GovCloud (US), quebra esse contrato em dois. Você declara um healthyPercent, a fração do desired count que precisa estar rodando e saudável na revisão alvo, e o ECS fecha o deployment ali. Com desired count 100 e healthyPercent 90, o deployment vira SUCCESSFUL na task 90; as dez restantes sobem depois, por service scaling comum.

O caso que motiva isso é fácil de reconhecer: inferência acelerada por GPU. A cauda de uma frota em capacidade especializada não sobe na mesma velocidade que a cabeça, a variável é a disponibilidade de hardware, não o seu contêiner. O deployment fica aberto esperando duas tasks que dependem de instância, o pipeline atrás dele fica em fila, e o deploy seguinte não começa. O mesmo vale para o outro lado da troca: serviço com conexão longa, cuja revisão fonte demora para drenar e segura o deployment aberto por um motivo que não tem nada a ver com a saúde do código novo.

Ler isso como deploy mais rápido é ler errado. O healthyPercent não é um acelerador, é a declaração de onde termina a proteção automática. A documentação é explícita: depois que o ECS completa o deployment, o circuit breaker e o rollback por alarme deixam de reverter o serviço, inclusive durante a subida das tasks restantes por service scaling.

Traduzindo para plantão: com desired count 100 e healthyPercent 90, as dez últimas tasks sobem sem rede. Se a nonagésima quinta falhar por um motivo que só aparece com carga real, connection pool estourando, um secret que só resolve numa AZ, um limite de licença por instância, o ECS a substitui pela mesma revisão alvo, repetidamente, sem voltar para a revisão anterior. O modo de falha não é o deployment falhar; é o deployment passar e o serviço degradar devagar, com o pipeline já verde e a equipe já em outra tarefa.

O circuit breaker ainda protege a janela que sobrou, e vale saber com que sensibilidade. O tipo padrão BOUNDED_PERCENT multiplica o valor (padrão 50) pelo desired count e limita o resultado entre 3 e 200: com 100 tasks desejadas são 50 falhas toleradas antes do rollback; com 400, o teto de 200 vale. Pior: com resetOnHealthyTask em true, o padrão, o contador zera a cada task saudável, então falhas intercaladas nunca somam. Encurtar a janela protegida com healthyPercent e deixar o circuit breaker no padrão permissivo é aplicar dois relaxamentos ao mesmo tempo e chamar isso de agilidade.

Três restrições fecham o intervalo antes de qualquer opinião. Primeira: o healthyPercent precisa ser maior ou igual ao minimumHealthyPercent do serviço. Se você manteve o padrão de 100% de serviço replica, não existe intervalo nenhum, baixar o minimumHealthyPercent é pré-requisito, e ele governa quantas tasks o scheduler pode parar durante a troca, o que é uma decisão de capacidade, não de velocidade.

Segunda: o valor é arredondado para cima sobre o desired count. Com 3 tasks e 50%, o deployment fecha em 2. Com 10 e 80%, em 8. Em serviço pequeno cada ponto percentual vale uma task inteira, e o ganho de tempo tende a zero: o earlySuccessCriteria só paga em frota grande ou em capacidade lenta.

Terceira: o ECS lança ao menos uma task na revisão alvo e espera ela ficar saudável antes de avaliar o percentual. E uma task só conta como saudável depois de passar os health checks configurados, com load balancer, isso significa o health check do target group, e com contêiner essencial com health check definido, os dois.

Daí em diante é decisão de risco, e ela é condicional. Use 90% ou mais quando o serviço é stateless atrás de ALB e o health check exercita dependência real, não um /healthz que devolve 200 sem tocar em nada. Fique em 100%, ou não ligue o recurso, quando a cauda de tasks carrega estado, shard ou licença por instância. E se a motivação é o pipeline demorar, meça antes: em rolling deployment, o tempo costuma morar no healthCheckGracePeriodSeconds, no startPeriod do health check do contêiner e no deregistration delay do target group, nenhum deles muda com a regra de sucesso.

O recurso não inventa status novo. O ciclo continua IN_PROGRESS → SUCCESSFUL, os eventos de service deployment state change no EventBridge e os registros do CloudTrail são os mesmos, e um deployment que fechou cedo aparece normalmente quando você filtra ListServiceDeployments por SUCCESSFUL. Isso é excelente para compatibilidade e péssimo para auditoria: nenhum consumidor do seu event bus consegue distinguir subiu inteiro de subiu 90% e o resto virou problema do autoscaling. Se o seu processo de mudança precisa dessa distinção, e sob BACEN, PCI-DSS ou SOX ele precisa, a fonte é o DescribeServiceDeployments, que devolve a configuração de early success criteria junto com o deployment.

Há uma armadilha silenciosa nos contadores. Enquanto o deployment está em andamento, o DescribeServiceDeployments devolve contagem viva; depois que ele fecha, devolve um snapshot do momento do fechamento, nos dois modos de cleanup. Um dashboard que lê task count dali vai mostrar 90 para sempre, mesmo com 100 tasks rodando e mesmo com a revisão fonte ainda drenando. A contagem viva está no DescribeServices, e só nele.

Então o alarme que importa muda de lugar. Antes, uma regra de EventBridge com eventName igual a SERVICE_DEPLOYMENT_FAILED cobria a maior parte do risco de release; agora ela cobre apenas a janela até o healthyPercent. O que passa a merecer alarme é a diferença entre desiredCount e runningCount da revisão alvo alguns minutos depois do sucesso, o número de substituições de task por revisão, e a idade das tasks da revisão fonte no modo DEFERRED. Nenhum desses três vem de graça.