Amazon ECS ganha métricas de CPU e memória a cada 20 segundos para auto scaling mais rápido

O ECS publica por padrão métricas de CPU e memória a cada 60 segundos. Para tráfego com picos bruscos, isso atrasa o target tracking, e muitos times acabam superdimensionando o serviço para compensar. Agora há a opção de 20 segundos, e o ECS também otimizou o caminho que leva a medição da tarefa até o CloudWatch. São duas mudanças que se somam: dados mais frequentes e mais recentes para a política de scaling.

No benchmark da AWS, o tempo para acionar o scale-out caiu 76%, de 363 para 86 segundos, e o tempo entre o acionamento e a colocação das novas tarefas caiu 72%, de 386 para 109 segundos. No teste de carga com perfil de rampa gradual (Rust, 1 vCPU por tarefa, target de 60% de CPU, de 1 a 128 tarefas, em us-west-2), o tempo de violação de SLA no Fargate caiu 69%, de 2.013 para 633 segundos. No ECS Managed Instances a queda foi de 98%, de 1.692 para 30 segundos, porque novas tarefas podem entrar em instâncias já ativas, muitas vezes com a imagem em cache. O scale down também encurtou: de 1.943 e 2.343 segundos para 42 e 37 segundos. Os perfis Java com picos repetidos e Node.js tiveram ganho menor, de 20% a 49%.

Para ativar, são dois passos: habilitar as métricas de 20 segundos no serviço (e esperar o deployment terminar) e anexar uma política de target tracking com ECSServiceAverageCPUUtilizationHighResolution ou ECSServiceAverageMemoryUtilizationHighResolution. Funciona em Fargate, Managed Instances e EC2, sem exigir Container Insights. Não há cobrança pelo recurso, mas métricas a 20 segundos contam como alta resolução no CloudWatch e são cobradas por métrica.

O recurso já havia aparecido antes. Em 18 de junho de 2026, o CEVIU noticiou "Amazon ECS introduz novas métricas de alta resolução para auto scaling de serviços", e em 24 de junho de 2026, "Amazon ECS adiciona métricas de alta resolução para acelerar o auto scaling de serviços", já citando scale-out até 76% mais rápido. O número de 76% é o mesmo de agora. O que entra de novo é o detalhamento do benchmark: perfis de carga, comparação entre Fargate e Managed Instances, resultados de SLA e de scale down, e orientação sobre quando vale ligar o recurso.

Para quem opera serviços com picos bruscos, a leitura é que dá para trocar parte da folga de capacidade por reação mais rápida, desde que o custo das métricas de alta resolução seja menor que o buffer que você deixa de manter. Faz sentido ligar só onde o lag de scaling aparece em latência ou disponibilidade. Em carga estável, os 60 segundos padrão tendem a bastar. Vale medir no seu workload antes de reduzir o baseline, já que os números vêm de testes da AWS.