Beanstalk Cluster Mode: o postmortem que escrevi antes do incidente

O cenário: uma equipe de pagamentos com nove serviços em ambientes Standard separados migra todos para Cluster Mode nas mesmas três subnets privadas. O primeiro create-environment cria a stack beanstalk-cluster-{uuid} em cerca de dez minutos; os outros oito entram no mesmo cluster sem criar nada. A conta de EC2 cai porque o EKS Auto Mode empacota os containers, e a equipe comemora.

O gatilho: um engenheiro com eks:* na role de administrador nota um node pool que parece ocioso e o edita direto no EKS, como faria em qualquer cluster da empresa. O Beanstalk compara o cluster com a configuração service-managed que ele espera, registra ERROR Cluster drift detected no evento do ambiente e pausa a manutenção daquele cluster.

A consequência: a partir desse momento, o serviço não coloca ambiente novo nesse cluster, não aplica atualização de add-on e, o ponto que dói, rejeita qualquer update-environment dos nove ambientes. Os replicas continuam rodando; o tráfego continua chegando pelo ALB. O que morre é a capacidade de mudar. Duas horas depois, um bug no serviço de conciliação exige hotfix e o deploy falha com uma mensagem que ninguém do plantão tinha visto.

O retro que segue não procura culpado. Procura a fronteira que faltou.

Subnets por domínio de falha, não por VPC: a decisão mais barata do dia zero é a mais cara de corrigir depois, mudar subnet de ambiente existente é rejeitado, e a saída é criar ambiente novo e trocar CNAME em blue/green. Eu alocaria um conjunto de subnets por regime de SLO e de compliance: um cluster para o que está no escopo do PCI DSS e carrega dados de cartão, outro para o que pode ficar duas horas sem hotfix, outro para dev. Separar produção de desenvolvimento já é o caso que a própria documentação cita como comum.

Humanos sem escrita no EKS do serviço: o drift só existe porque alguém pôde editar. Uma SCP ou uma policy de permissão com Deny em eks:Update, eks:Delete e eks:Create condicionada a aws:ResourceTag das stacks beanstalk-cluster- deixa o caminho de mudança passando obrigatoriamente pelo update-environment. Leitura pode ficar liberada; é o que o runbook de verificação de deleção precisa.

node-pool para o que não pode disputar CPU: sem ele, replicas de ambientes diferentes dividem o mesmo nó. Dar ao serviço de ledger um valor de node-pool que nenhum outro ambiente usa tira o vizinho barulhento do caminho, mas mudar esse valor reinicia todos os replicas, decida na criação.

Um application-role por ambiente: a rede entre ambientes é bloqueada por padrão, mas a saída não é restrita e credencial compartilhada anula a separação. Role por ambiente, escopada ao que ele acessa, é o mínimo.

O retro do drift escondia um segundo incidente esperando a vez. Os padrões dos namespaces aws:elasticbeanstalk:eks:* são razoáveis para demo e perigosos para produção financeira.

Probes desligadas: readiness, liveness e startup vêm com enabled=false. Sem readiness, um replica novo recebe tráfego do ALB antes de abrir o pool de conexões; sem liveness, um processo travado fica no ar até alguém notar. Ligue as três, com period-seconds abaixo do padrão de 30 e failure-threshold de 3, o que dá 90 segundos de detecção no pior caso.

cpu de 250m sem cpu-limit: a reserva é pequena e o teto não existe. Um replica com vazamento de CPU disputa o nó com quem estiver do lado. Defina cpu-limit e memory-limit (o padrão de memória é 1Gi) por serviço, medidos.

Escala por CPU a 80%: sem trigger explícito, o serviço escala entre min-replica=1 e max-replica=10 por utilização de CPU. Para fila de pagamentos, scaler-type=metrics-api lendo o backlog do seu endpoint é a métrica que importa; min-replica=1 em produção é um único ponto de falha com nome bonito.

Secrets sem application-role: a opção secrets e a scaler-auth-secret montam via identidade do pod, que só existe com application-role definido. Sem ele, a montagem falha e os replicas nunca sobem, silenciosamente, no primeiro deploy.

Log groups sem retenção: os quatro /aws/elasticbeanstalk/* são compartilhados por conta e região e nascem sem política de expiração; cada deploy cria stream novo. Defina retenção no dia um.

O argumento do Cluster Mode é custo por aplicação caindo conforme o número de aplicações sobe. A conta tem três parcelas fixas que o Standard não tinha.

Control plane: US$ 0,10 por cluster por hora, cerca de US$ 73 por mês por conjunto de subnets. Cada fronteira de falha que eu recomendei acima custa isso. Passado o período de suporte padrão do Kubernetes, o suporte estendido sobe para US$ 0,60/h, e como a versão fica fixa pela vida do cluster, esse relógio corre desde a criação.

EKS Auto Mode: taxa de gestão por instância além do EC2. No exemplo da página de preços, uma m5a.xlarge custa US$ 0,172/h de EC2 mais US$ 0,02064/h de Auto Mode: 12% em cima do compute.

Métricas custom: o Standard publica em AWS/ElasticBeanstalk, gratuito. O Cluster Mode publica em ElasticBeanstalk/Infrastructure, /System e /Application, namespaces custom cobrados por métrica, e as duas métricas de container saem por replica. Vinte replicas viram dezenas de métricas pagas antes de a aplicação emitir a primeira delas.

O próprio post de lançamento cita a régua: abaixo de cerca de US$ 500 por mês de carga, o overhead do EKS supera a economia e o Standard continua melhor. Minha leitura: o modo compensa quando você tem de seis a oito serviços do mesmo domínio, cada um subutilizando uma instância dedicada hoje, e uma plataforma disposta a pagar US$ 73 por fronteira de falha extra. Com dois serviços, é uma migração para pagar mais e mudar menos.