Daemon crítico ou não-crítico: o contrato de falha do ECS

O modelo sidecar-por-task resolve distribuição e falha em economia e governança. Uma instância que roda 40 tasks roda 40 cópias do coletor de logs; a 128 MiB cada, são 5 GiB de RAM gastos duplicando a mesma função. Pior que o desperdício é a deriva: a versão do agente passa a ser propriedade de cada time de aplicação, e o time de segurança descobre no auditoria que três serviços ainda rodam uma imagem de sete meses atrás.

O ECS já tinha a estratégia de escalonamento DAEMON para o launch type EC2, mas ela é apenas colocação, um daemon por instância, sem garantia de que ele esteja de pé antes da primeira task de aplicação atender tráfego. Para telemetria isso é um buraco no gráfico. Para um agente de runtime security, é uma janela em que a instância processa transação sem cobertura.

Managed Daemons, GA em 1º de abril de 2026 para capacity providers do ECS Managed Instances, fechou esse buraco invertendo a relação: a instância só transiciona a task de aplicação para RUNNING depois que o daemon está rodando. O preço dessa garantia foi um acoplamento rígido, qualquer daemon que falhasse levava a instância a drenar e ser substituída. Correto para um agente de conformidade. Absurdo para um exportador de métricas. O lançamento de setembro não adiciona uma funcionalidade nova; ele desfaz um acoplamento que nunca deveria ter sido único.

O padrão tem três recursos distintos. Primeiro, um daemon task definition: um tipo de recurso próprio, com ARN próprio (daemon-task-definition/...), separado do task definition de aplicação. Segundo, um daemon, criado com CreateDaemon, que amarra essa definição a um cluster e a um ou mais capacity providers do Managed Instances. Terceiro, as instâncias EC2 provisionadas por esses capacity providers, em cada uma das quais o ECS mantém exatamente uma task de daemon.

A primeira garantia é de ordem: o ECS provisiona a instância, sobe a task de daemon e só então promove a task de aplicação a RUNNING. Medições independentes publicadas em abril de 2026 mostraram o daemon alcançando RUNNING de 18 a 21 segundos antes da aplicação, com a instância mantida em REGISTERING nesse intervalo. Essa ordem vale para todo daemon, crítico ou não. É o ponto que mais vejo entendido errado: ao marcar um daemon como não-crítico você não perde a garantia de que o agente sobe antes do tráfego; perde apenas a garantia de que ele continua de pé.

A segunda garantia é de remediação, e é ela que o interruptor critical controla. Vale registrar como o ECS remedia: ele não reinicia o contêiner, ele drena e substitui a instância inteira. É deliberadamente brutal, um agente que morreu pode ter deixado probes eBPF desanexadas, regras de rede meio aplicadas, buffers perdidos. Trocar a instância é a única forma barata de voltar a um estado conhecido.

A regra cabe em uma linha: marque como crítico o agente cuja ausência muda o que o sistema tem permissão de fazer; marque como não-crítico o agente cuja ausência muda apenas o que você consegue ver. Um EDR de runtime, um enforcer de política de rede, um sidecar de mTLS ou um agente de integridade de arquivos exigido por PCI DSS caem no primeiro grupo, sem eles, a instância não deveria estar apta a processar uma transação. Um coletor OTel de métricas, um exportador de nó, um agente de profiling contínuo caem no segundo.

A nuance mora no roteador de logs. Em ambiente financeiro, o log frequentemente é a trilha de auditoria: "o que você consegue ver" vira "o que você consegue provar", e o Fluent Bit deixa de ser auxiliar. Não classifique por categoria de ferramenta; classifique pela obrigação regulatória que aquele fluxo sustenta. Se o buffer local do agente aguenta a janela de indisponibilidade sem perder evento, não-crítico é defensável; se ele perde, é crítico.

O corolário de design é o que mais rende na prática: como a criticidade é por daemon, e um capacity provider aceita múltiplos daemons, não empacote agentes de contratos diferentes no mesmo task definition. Um task definition com o EDR e o coletor de métricas juntos força o contrato mais estrito sobre os dois, e transforma um vazamento de memória do coletor em substituição de frota. Dois daemons, dois ciclos de release, dois donos, duas criticidades.

Crítico demais. Uma revisão ruim do agente faz a task oscilar, e cada oscilação vira substituição de instância. Numa frota de 60 instâncias com o drain percentage no padrão de 25%, são 15 substituições simultâneas por onda; com o tempo medido de ~4min50s por onda, uma mudança de uma linha no agente custa cerca de 20 minutos de rotação de frota. O impacto direto na conta é modesto e calculável: a taxa de gerenciamento do Managed Instances para um c6a.2xlarge é de US$ 0,037/hora por instância (Oregon), então 60 instâncias somam ~US$ 1.620/mês só de fee, mais o EC2 e o overlap durante o drain. A fatura cara é outra: reescalonamento de tasks de aplicação, conexões drenadas, caches frios, JIT frio.

Dois defaults conspiram aqui. O bake time padrão é 0 minuto, ou seja, terminada a última onda, a janela em que o circuit breaker observa alarmes para fazer rollback é nula. Uma regressão que só aparece sob carga passa direto.

Não-crítico demais. O modo falha aberto não emite dor: a instância continua ACTIVE, o SLO da aplicação não se move, e a cobertura do agente cai em silêncio. Some-se a armadilha operacional documentada: as configurações de daemon não são persistidas entre updates, e critical tem default true. Um UpdateDaemon disparado por pipeline sem --no-critical explícito re-arma o churn de frota inteiro sem que ninguém tenha pedido isso. É exatamente o tipo de mudança que só aparece no próximo incidente.