Amazon ECS Managed Daemons: controle independente de agentes no seu cluster

Se você já operou clusters ECS com EC2, sabe a dor: pra rodar um agente de monitoramento ou logging em cada instância, você tinha que embutir isso na task definition da aplicação como sidecar, ou bake no AMI, ou usar a DAEMON scheduling strategy dos ECS Services. Qualquer atualização no agente significava coordenar com os times de aplicação, mexer em task definitions e redeployar serviços. Quando você gerencia centenas de services, isso vira um pesadelo operacional.

A AWS lançou o Amazon ECS Managed Daemons pra resolver exatamente isso. É uma funcionalidade nova dentro do ECS Managed Instances que permite deployar e gerenciar agentes de infraestrutura (monitoring, logging, tracing, segurança) de forma completamente independente das aplicações.

O problema que existia antes

Antes do Managed Daemons, as opções pra rodar agentes em instâncias ECS eram:

• Sidecar na task definition: cada task carregava o agente junto. Atualizar o agente = atualizar a task definition = redeploy da aplicação. Além disso, se você tem 50 tasks rodando na mesma instância, são 50 cópias do mesmo agente consumindo recursos
• Bake no AMI: funciona, mas atualizar o agente significa criar um novo AMI, atualizar o launch template e fazer rolling replacement das instâncias
• DAEMON scheduling strategy: melhor opção até então, mas ainda acoplada ao conceito de ECS Service, sem garantias de ordenação (o daemon podia não estar pronto quando a aplicação subia)

Nenhuma dessas opções dava pro time de plataforma controle independente sobre os agentes. Sempre havia acoplamento com o ciclo de vida das aplicações.

Como o Managed Daemons funciona

O conceito é simples: você cria uma daemon task definition (separada das task definitions normais), depois cria um daemon associado ao cluster e a um ou mais capacity providers do tipo Managed Instances. O ECS garante que exatamente uma instância do daemon roda em cada EC2 provisionada por aqueles capacity providers.

Ciclo de vida garantido

O ponto mais importante: o ECS garante a ordem de execução. O daemon task inicia ANTES das application tasks e drena POR ÚLTIMO. Isso significa que quando sua aplicação começa a processar requests, o agente de logging/tracing/monitoring já está operacional. Sem gaps de coleta.

Se o daemon task parar ou ficar unhealthy, o ECS automaticamente drena e substitui a instância inteira. Isso é um auto-repair que garante cobertura consistente sem intervenção manual.

Daemon task definition

É um novo tipo de task definition, separado das task definitions de aplicação, com seus próprios parâmetros e validação. Suporta:

• Containers privilegiados (necessário pra agentes de segurança e monitoring que precisam de acesso ao host)
• Linux capabilities adicionais
• Mount de paths do filesystem do host
• Network mode daemon_bridge, que permite comunicação com application tasks mantendo isolamento de rede

Essas capabilities são essenciais pra agentes que precisam de visibilidade em métricas de host, processos e system calls.

Deploy e rolling updates

Quando você atualiza um daemon pra uma nova revisão da task definition, o ECS faz um rolling deployment automático:

1. Drena uma porcentagem configurável das instâncias simultaneamente (padrão: 25%)
2. Provisiona novas instâncias com o daemon atualizado
3. Inicia o daemon primeiro na nova instância
4. Migra as application tasks pra nova instância
5. Termina as instâncias antigas

Essa abordagem "start before stop" garante que não há gaps na cobertura do daemon durante o update. Seus agentes de logging e monitoring continuam operacionais durante todo o processo.

O ECS também oferece proteção com circuit breaker integrado. Você pode configurar:

• Bake time: tempo que o ECS espera após atualizar todas as instâncias antes de considerar o deployment completo. Durante esse período, ele monitora CloudWatch alarms e faz rollback automático se algum alarme disparar
• CloudWatch alarms: alarmes que o ECS monitora durante o deployment pra decidir se faz rollback

Exemplo prático: CloudWatch Agent como daemon

Vamos ver como configurar o CloudWatch Agent como managed daemon.

Via Console

1. No console do ECS, vá em Daemon task definitions no menu lateral
2. Crie uma nova daemon task definition com:

- Imagem: public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest

- CPU: 1 vCPU, Memória: 0.5 GB

- Task execution role: ecsTaskExecutionRole

1. No cluster, vá na aba Daemons e clique em Create daemon
2. Selecione a daemon task definition criada e o capacity provider do tipo Managed Instances
3. Configure o drain percentage e alarmes se necessário

Via CLI

Crie a daemon task definition e depois o daemon:

Criar o daemon
aws ecs create-daemon --cli-input-json '{
    "clusterArn": "arn:aws:ecs:us-east-1:123456789012:cluster/meu-cluster",
    "daemonName": "cloudwatch-agent",
    "daemonTaskDefinitionArn": "arn:aws:ecs:us-east-1:123456789012:daemon-task-definition/cw-agent:1",
    "capacityProviderArns": [
        "arn:aws:ecs:us-east-1:123456789012:capacity-provider/meu-cp"
    ]
}'

Verificar o status:

Listar daemons
aws ecs list-daemons --cluster-arn arn:aws:ecs:us-east-1:123456789012:cluster/meu-cluster

Detalhes do daemon
aws ecs describe-daemons --daemon-arn arn:aws:ecs:us-east-1:123456789012:daemon/meu-cluster/cloudwatch-agent

Atualizar pra nova versão:

aws ecs update-daemon \
    --daemon-arn arn:aws:ecs:us-east-1:123456789012:daemon/meu-cluster/cloudwatch-agent \
    --daemon-task-definition-arn arn:aws:ecs:us-east-1:123456789012:daemon-task-definition/cw-agent:2

Casos de uso

Observabilidade

O caso mais óbvio. Deployar CloudWatch Agent, Datadog Agent, New Relic Agent ou qualquer outro coletor de métricas/logs/traces como daemon. Um agente por instância, compartilhado por todas as tasks, com lifecycle independente.

Segurança

Agentes de segurança como Falco, Sysdig ou agentes de EDR que precisam de acesso privilegiado ao host. O suporte a containers privilegiados e Linux capabilities torna isso viável sem gambiarras.

Networking

Service meshes e proxies que precisam rodar em cada instância. Envoy, Consul Connect ou agentes de rede customizados.

Compliance

Agentes de auditoria e compliance que precisam estar presentes em 100% das instâncias, com garantia de que estão rodando antes de qualquer workload.

Managed Daemons vs DAEMON scheduling strategy

| Aspecto | Managed Daemons | DAEMON Strategy |

|---|---|---|

| Plataforma | ECS Managed Instances | EC2 launch type |

| Ordenação | Daemon inicia antes das apps | Sem garantia de ordem |

| Auto-repair | Substitui instância se daemon falhar | Tenta reiniciar o service |

| Rolling update | Start before stop, sem gaps | Pode ter gaps durante update |

| Circuit breaker | Integrado com bake time e alarms | Básico |

| Task definition | Tipo separado (daemon task def) | Task definition normal |

| Isolamento | Lifecycle independente | Acoplado ao ECS Service |

Limitações

• Funciona apenas com ECS Managed Instances, não com Fargate ou EC2 launch type tradicional
• O daemon não provisiona instâncias sozinho. Instâncias só são criadas quando application tasks precisam de capacidade
• Cada UpdateDaemon precisa incluir todas as configurações desejadas. Settings omitidos voltam pro default (não há merge com a configuração anterior)
• Disponível em todas as regiões AWS, sem custo adicional (você paga apenas pelo compute consumido pelos daemon tasks)

Conclusão

O ECS Managed Daemons resolve um problema real de separação de responsabilidades em clusters de containers. Times de plataforma ganham controle independente sobre agentes de infraestrutura, sem depender dos times de aplicação pra fazer deploy ou update. A garantia de ordenação (daemon antes da app) e o auto-repair eliminam classes inteiras de problemas operacionais.

Se você usa ECS com EC2 e precisa rodar agentes em todas as instâncias, vale migrar pra Managed Instances + Managed Daemons. A experiência operacional é significativamente melhor do que qualquer alternativa anterior.