# ECS Auto Scaling: Métricas de Alta Resolução vs. Abordagens Tradicionais

O lançamento de métricas de alta resolução (20 segundos) para o Amazon ECS muda o cálculo de auto scaling para cargas financeiras sensíveis à latência. Este artigo compara as quatro abordagens principais de scaling — target tracking com alta resolução, step scaling, scheduled scaling e preditivo — com trade-offs concretos, números reais e uma matriz de decisão para ambientes de produção.

- URL: https://fernando.moretes.com/blog/ecs-auto-scaling-metricas-de-alta-resolucao-vs-abordagens-tradicionais-amazon-ecs-i

- Markdown: https://fernando.moretes.com/blog/ecs-auto-scaling-metricas-de-alta-resolucao-vs-abordagens-tradicionais-amazon-ecs-i/article.md?lang=pt

- Published: 2026-06-18T21:06:38.000Z

- Category: AWS & Cloud

- Tags: ECS, Auto Scaling, CloudWatch, Fargate, FinancialGrade, Observability, Kubernetes, CostOptimization

- Reading time: 9 min

- Source: [Amazon ECS introduces new high-resolution metrics for faster service auto scaling](https://aws.amazon.com/blogs/aws/amazon-ecs-introduces-new-high-resolution-metrics-for-faster-service-auto-scaling/)

---

Quando o Amazon ECS anunciou suporte a métricas de alta resolução com intervalos de 20 segundos e reduziu o tempo de disparo de scale-out de 363 para 86 segundos — uma melhoria de 4,2x — a pergunta imediata para quem opera sistemas financeiros não foi 'devo habilitar isso?', mas sim 'isso substitui minha estratégia atual ou complementa?' Trabalho com plataformas de pagamento e trading que precisam absorver picos de demanda em janelas de segundos, não minutos. A resposta não é trivial: cada abordagem de scaling carrega um perfil distinto de custo, complexidade operacional, risco de over-provisioning e janela de exposição a falhas. Este artigo faz o bake-off honesto entre as quatro estratégias viáveis.

## O Problema Real: A Janela de Exposição em Sistemas Financeiros

Em sistemas de pagamento, a janela entre o início de um pico de demanda e o momento em que novos tasks estão prontos para receber tráfego é o intervalo de maior risco operacional. Durante esse período, os tasks existentes absorvem carga além do seu dimensionamento nominal, o que em Fargate significa CPU throttling e em EC2 significa contenção de recursos no host. Para um gateway de pagamentos processando 8.000 TPS em condições normais, um pico de 3x durante Black Friday pode elevar a taxa de erro de 0,01% para 3% em menos de dois minutos se o scaling não reagir a tempo.

O benchmark da AWS é revelador nesse contexto: antes das métricas de alta resolução, o ciclo completo de detecção → avaliação da política → disparo do Application Auto Scaling → provisionamento do task levava em média 386 segundos com target tracking padrão. Com métricas de 20 segundos, esse ciclo caiu para 109 segundos. Mas o número que realmente importa para engenheiros de confiabilidade é o **tempo de exposição ao risco**: os 277 segundos economizados representam quase 5 minutos a menos em que o sistema opera acima da capacidade nominal.

Isso tem implicações diretas no dimensionamento do baseline. Se você mantinha 40% de capacidade ociosa como buffer de segurança porque o scaling demorava 6 minutos, agora pode recalibrar esse buffer para 15-20% com o mesmo perfil de risco — o que em Fargate com 200 tasks de 2 vCPU/4GB representa uma economia mensal relevante. O trade-off, como sempre, está nos detalhes de configuração e no custo incremental do CloudWatch.

## Impacto Mensurável das Métricas de Alta Resolução

- **4.2x** — Mais rápido no disparo de scale-out. De 363s para 86s no tempo de detecção e disparo (benchmark AWS)
- **109s** — Ciclo completo de scaling. Do pico de demanda ao task novo pronto — 72% mais rápido que os 386s anteriores
- **~20%** — Redução potencial no baseline de tasks. Buffer de capacidade ociosa pode ser reduzido sem comprometer o SLO de disponibilidade

## As Quatro Estratégias: O Que Cada Uma Realmente Entrega

**Target Tracking com Alta Resolução (20s)** é a nova opção padrão para cargas reativas. Você define um target — digamos, 60% de CPU média — e o Application Auto Scaling ajusta o número de tasks para manter esse alvo. Com métricas de 20 segundos via `ECSServiceAverageCPUUtilizationHighResolution` ou `ECSServiceAverageMemoryUtilizationHighResolution`, o período de avaliação do CloudWatch Alarm cai de 3 períodos de 60s (3 minutos) para 3 períodos de 20s (1 minuto), o que explica boa parte do ganho. O custo adicional é real: CloudWatch cobra métricas de alta resolução por métrica/mês além do tier gratuito, e cada serviço ECS publica múltiplas dimensões.

**Step Scaling** foi durante anos a escolha de times que precisavam de controle granular sobre a resposta ao scaling. Você define bandas de utilização e ações correspondentes: se CPU > 70%, adicione 5 tasks; se CPU > 85%, adicione 15 tasks. O problema é a complexidade de manutenção: cada mudança no perfil de carga potencialmente requer retuning das bandas. Em ambientes financeiros com múltiplos serviços, isso vira dívida técnica rapidamente. Com o target tracking de alta resolução entregando comportamento agressivo sem essa configuração manual, o caso de uso do step scaling se estreita consideravelmente.

**Scheduled Scaling** permanece indispensável para eventos previsíveis: abertura de mercado às 9h, batch de fechamento às 18h, campanhas de marketing com horário definido. Não é uma alternativa ao target tracking — é um complemento. A combinação de scheduled scaling para pré-aquecer capacity + target tracking de alta resolução para absorver variações intraday é o padrão que recomendo para plataformas financeiras.

**Predictive Scaling** usa ML para analisar padrões históricos de 14 dias e provisionar capacity antecipadamente. É poderoso para cargas com sazonalidade estável, mas tem limitações importantes: requer pelo menos duas semanas de histórico, não reage a eventos inesperados, e pode gerar over-provisioning em períodos de baixa demanda se o padrão histórico incluir picos atípicos.

## Comparação Direta: Estratégias de Auto Scaling no ECS
| Critério | Critério | Target Tracking Alta Resolução (20s) | Step Scaling (60s) | Scheduled Scaling | Predictive Scaling |
| --- | --- | --- | --- | --- | --- |
| Tempo de disparo (scale-out) | ~86s (benchmark AWS) | ~180-360s típico | Pré-definido (0s de reação) | Antecipado (minutos antes) | — |
| Complexidade de configuração | Baixa — 1 métrica, 1 target | Alta — bandas, cooldowns, ajustes | Média — requer calendário de eventos | Baixa após setup — ML gerencia | — |
| Custo CloudWatch adicional | Sim — métricas de alta resolução pagas | Não — métricas padrão gratuitas | Não — sem métricas adicionais | Mínimo — usa histórico existente | — |
| Reação a picos inesperados | Excelente — 86s end-to-end | Boa — se bandas bem calibradas | Nenhuma — reativa apenas ao plano | Fraca — não detecta anomalias | — |
| Risco de over-provisioning | Baixo — escala precisa no target | Médio — depende do tuning das bandas | Alto — capacidade fixa pré-alocada | Médio-alto — padrões históricos atípicos | — |
| Adequação para sistemas financeiros | Alta — picos imprevisíveis, SLO rígido | Média — útil como fallback granular | Alta — eventos de mercado previsíveis | Média — cargas com sazonalidade estável | — |
| Maturidade operacional necessária | Baixa — simples de operar | Alta — requer SRE experiente | Média — requer gestão de calendário | Média — requer validação do modelo ML | — |

## Configuração Técnica: O Que Realmente Muda no Stack

Habilitar métricas de alta resolução não é apenas um toggle no console — tem implicações em toda a cadeia de observabilidade. Quando você ativa `20-second resolution metrics` na seção de Monitoring de um serviço ECS, o daemon de métricas do ECS passa a publicar no CloudWatch com `StorageResolution: 20` em vez de `StorageResolution: 60`. Isso significa que os alarmes associados precisam ser configurados com `Period: 20` e `EvaluationPeriods: 3` para manter o comportamento de 1 minuto de avaliação — qualquer alarme existente com `Period: 60` continuará funcionando mas não se beneficiará da resolução maior.

No Application Auto Scaling, a política de target tracking precisa referenciar explicitamente as novas métricas: `ECSServiceAverageCPUUtilizationHighResolution` em vez de `ECSServiceAverageCPUUtilization`. Isso é um breaking change silencioso para quem usa CloudFormation ou Terraform sem atualizar o recurso `AWS::ApplicationAutoScaling::ScalingPolicy` — o serviço continuará escalando, mas com a métrica de 60 segundos antiga.

Do ponto de vista de IAM, não há novas permissões necessárias: `cloudwatch:PutMetricData` e `application-autoscaling:PutScalingPolicy` já cobrem o caso. Mas para auditoria em ambientes financeiros, recomendo adicionar uma condition key `aws:RequestedRegion` na política do Application Auto Scaling para evitar que políticas de scaling sejam criadas inadvertidamente em regiões não aprovadas — um vetor de custo e compliance que já vi em produção.

No CloudFormation, a sequência de atualização importa: primeiro atualize o `AWS::ECS::Service` com `EnableECSManagedTags` e a configuração de métricas de alta resolução, aguarde o deployment completar (o serviço precisa gerar pelo menos um ponto de dado na nova resolução), e só então atualize a `ScalingPolicy`. Fazer as duas mudanças no mesmo stack update pode resultar em um alarme de alta resolução apontando para um serviço que ainda não publicou métricas nessa resolução, gerando um período de `INSUFFICIENT_DATA` que bloqueia o scaling.

## Fluxo de Decisão e Timing: Quatro Estratégias de Scaling no ECS

Comparação do ciclo completo de scaling para cada estratégia, desde a detecção do pico até o task novo pronto para tráfego. Os tempos refletem benchmarks AWS e experiência operacional em ambientes financeiros.

### 🟢 High-Res Target Tracking — 20s metrics

- CloudWatch 20s metric (data)
- CW Alarm 3×20s = 60s eval (security)
- App Auto Scaling trigger ~86s (compute)
- New ECS Task ready ~109s (compute)

### 🟡 Step Scaling — 60s metrics

- CloudWatch 60s metric (data)
- CW Alarm 3×60s = 180s eval (security)
- App Auto Scaling trigger ~180-360s (compute)
- New ECS Task ready ~386s (compute)

### 🔵 Scheduled Scaling — proactive

- Schedule Rule (cron/rate) (messaging)
- Pre-warmed Tasks t < 0 (before spike) (compute)

### 🟣 Predictive Scaling — ML-driven

- ML Model 14-day history (ai)
- Capacity Forecast minutes ahead (data)
- Pre-provisioned Tasks before traffic arrives (compute)

### Fluxos

- spike -> cw20: publica métrica 20s
- cw20 -> alarm20: avalia 3 períodos
- alarm20 -> aas20: dispara política
- aas20 -> task20: provisiona task
- spike -> cw60: publica métrica 60s
- cw60 -> alarm60: avalia 3 períodos
- alarm60 -> aas60: dispara política
- aas60 -> task60: provisiona task
- sched -> taskpre: escala antes do pico
- ml -> forecast: gera previsão
- forecast -> taskml: pré-provisiona

## Observabilidade e SLOs: O Que Monitorar com Alta Resolução

A adoção de métricas de 20 segundos muda o que faz sentido monitorar — e como. Com métricas de 60 segundos, um CloudWatch Dashboard com refresh de 1 minuto era suficiente para acompanhar o comportamento de scaling em tempo real. Com 20 segundos, você precisa de dashboards com refresh de 10-20 segundos para capturar a granularidade disponível, o que tem implicações no custo de GetMetricData se você tiver automações ou ferramentas de observabilidade consultando esses dados em alta frequência.

Para SLOs em sistemas financeiros, as métricas de alta resolução abrem a possibilidade de definir **error budget burn rate** com janelas menores. Se seu SLO é 99,95% de disponibilidade mensal, o error budget é ~21,6 minutos. Com scaling reagindo em 109 segundos em vez de 386, cada evento de pico consome menos error budget — o que significa que você pode tolerar mais eventos antes de acionar alertas de burn rate acelerado.

No OpenTelemetry, recomendo instrumentar o próprio ciclo de scaling como um span: capture o timestamp do primeiro ponto de dado acima do threshold, o timestamp do disparo do Application Auto Scaling (disponível via EventBridge com `source: aws.application-autoscaling`), e o timestamp do primeiro health check bem-sucedido do novo task. Esses três pontos definem o **scaling latency** real da sua plataforma — um SLI que poucos times medem explicitamente mas que é crítico para entender o comportamento sob carga.

Um detalhe operacional importante: o cooldown padrão do target tracking é 300 segundos para scale-in e 0 para scale-out. Com métricas de 20 segundos, o scale-out pode ser disparado múltiplas vezes em sequência antes que os novos tasks estejam prontos, resultando em over-scaling temporário. Recomendo configurar `ScaleOutCooldown: 120` para evitar esse comportamento em serviços com tempo de startup de task acima de 30 segundos.

## Matriz de Decisão: Qual Estratégia para Qual Contexto

### Target Tracking Alta Resolução (20s)

**Pros**
- 86s de disparo — menor janela de exposição ao risco
- Configuração simples: 1 métrica, 1 target, sem bandas
- Permite reduzir baseline de tasks em 15-25%
- Substitui step scaling na maioria dos casos de uso

**Cons**
- Custo adicional de CloudWatch para métricas de alta resolução
- Risco de over-scaling com cooldown mal configurado
- Requer atualização explícita de políticas existentes no IaC

**Verdict:** Escolha padrão para cargas com picos imprevisíveis e SLO rígido

### Step Scaling (60s)

**Pros**
- Controle granular sobre magnitude do scaling por banda
- Sem custo adicional de CloudWatch
- Útil quando diferentes intensidades de pico requerem respostas distintas

**Cons**
- Tempo de disparo 2-4x mais lento que alta resolução
- Alta complexidade de manutenção — requer retuning frequente
- Caso de uso se estreita com a chegada do target tracking de alta resolução

**Verdict:** Use apenas quando precisar de respostas de scaling dramaticamente diferentes por faixa de utilização

### Scheduled Scaling

**Pros**
- Zero latência de reação — capacity pronta antes do pico
- Sem custo adicional de métricas
- Ideal para eventos de mercado e campanhas com horário definido

**Cons**
- Inútil para picos não planejados
- Over-provisioning garantido durante períodos de baixa demanda
- Requer gestão ativa do calendário de eventos

**Verdict:** Complemento obrigatório ao target tracking em plataformas financeiras com eventos previsíveis

### Predictive Scaling

**Pros**
- Antecipa capacity antes do pico com base em padrões históricos
- Reduz dependência de configuração manual de schedules
- Combina bem com target tracking como camada de segurança

**Cons**
- Requer 14 dias de histórico — não funciona em serviços novos
- Não reage a eventos inesperados ou anomalias de demanda
- Pode gerar over-provisioning se histórico contiver picos atípicos

**Verdict:** Melhor para cargas com sazonalidade estável e bem documentada; use com target tracking como fallback reativo

> **O Padrão de Composição que Recomendo para Produção Financeira:** A resposta correta para a maioria dos sistemas financeiros não é escolher uma estratégia — é compor três. **Scheduled Scaling** para pré-aquecer capacity em eventos previsíveis (abertura de mercado, batch de fechamento, campanhas). **Target Tracking de Alta Resolução** como camada reativa principal para absorver variações intraday e picos inesperados. **Predictive Scaling** desabilitado por padrão, habilitado apenas para serviços com mais de 30 dias de histórico estável e revisado trimestralmente. Step Scaling deve ser depreciado ativamente — se você ainda tem políticas de step scaling em produção, o target tracking de alta resolução é o substituto natural com menos código para manter.

## Custo Real: Calculando o Trade-off CloudWatch vs. Economia de Compute

O argumento de custo para métricas de alta resolução é mais favorável do que parece à primeira vista, mas requer um cálculo honesto. O CloudWatch cobra métricas de alta resolução no tier de métricas customizadas: $0,30 por métrica/mês para as primeiras 10.000 métricas. Cada serviço ECS com alta resolução habilitada publica aproximadamente 4-6 métricas (CPU, Memory, RequestCount por dimensão de serviço e cluster). Para uma plataforma com 50 serviços ECS, isso representa 200-300 métricas adicionais, ou $60-90/mês em CloudWatch.

No lado da economia, o argumento é mais robusto. Considere um serviço Fargate rodando 100 tasks de 2 vCPU/4GB em us-east-1: o custo por task é aproximadamente $0,09/hora ($64,80/mês por task). Se o baseline pode ser reduzido de 100 para 80 tasks (-20%) porque o scaling reativo é 4x mais rápido, a economia mensal é 20 tasks × $64,80 = $1.296/mês. O custo adicional de CloudWatch de $60-90 representa menos de 7% da economia de compute — um ROI extremamente favorável.

O cálculo muda para serviços com muitas dimensões de métricas customizadas ou para contas com alto volume de GetMetricData. Se você tem dashboards, alertas e automações consultando métricas de alta resolução em alta frequência, o custo de API pode superar o custo de armazenamento das métricas. Recomendo usar **CloudWatch Metric Streams** para exportar métricas para um data store analítico (S3 + Athena ou Datadog) em vez de consultar via GetMetricData em loop — isso reduz o custo de API em 60-80% para casos de uso de observabilidade.

Para ambientes multi-conta com AWS Organizations, o custo de CloudWatch é consolidado mas cobrado por conta. Considere centralizar os alarmes de scaling em uma conta de observabilidade dedicada usando **CloudWatch cross-account observability** — isso simplifica o gerenciamento e permite comparar o comportamento de scaling entre contas de dev, staging e produção com uma única view.

## Anti-Padrões que Já Vi em Produção

- Habilitar métricas de alta resolução sem atualizar a política de scaling — o serviço publica métricas de 20s mas o alarme avalia em 60s, sem ganho de velocidade e com custo adicional.
- Manter ScaleOutCooldown em 0 com alta resolução — resulta em múltiplos scale-outs em cascata antes que os tasks anteriores estejam prontos, gerando over-scaling de 2-3x o necessário.
- Usar step scaling e target tracking de alta resolução no mesmo serviço simultaneamente — as políticas competem e o comportamento resultante é imprevisível; escolha uma.
- Não instrumentar o ciclo de scaling no sistema de observabilidade — sem medir scaling latency como SLI, você não sabe se o investimento em alta resolução está entregando o benefício esperado.
- Aplicar alta resolução em todos os serviços indiscriminadamente — serviços de background com SLO relaxado não justificam o custo adicional; reserve para serviços no caminho crítico de latência.

> **Nota do Curador:** Na prática, o que mais me impressionou nesse lançamento não foi o número de 4,2x — foi a simplificação operacional. Eu já mantive step scaling policies em plataformas de pagamento com 12 bandas de utilização, cada uma calibrada manualmente após incidentes de produção. Era dívida técnica disfarçada de controle. O target tracking de alta resolução entrega comportamento equivalente ou superior com uma fração da configuração. Minha recomendação imediata para qualquer time operando ECS em produção financeira: audite suas políticas de step scaling, identifique quais podem ser substituídas por target tracking de alta resolução, e meça o scaling latency antes e depois — você vai querer esse dado para justificar a mudança para stakeholders e para calibrar os cooldowns corretamente. A lição difícil que aprendi: complexidade de configuração não é sinônimo de controle; frequentemente é o oposto.

## Veredicto: Migre para Alta Resolução, Mas com Sequência Correta

O target tracking com métricas de alta resolução de 20 segundos é a escolha dominante para serviços ECS no caminho crítico de latência em ambientes financeiros. O ROI é claro: o custo adicional de CloudWatch ($60-90/mês para 50 serviços) é superado pela economia de compute que vem da redução do baseline de tasks (-15-25%), e a redução da janela de exposição ao risco de 386s para 109s tem valor direto no error budget do SLO. A migração deve seguir a sequência: (1) habilitar métricas de alta resolução no serviço ECS, (2) aguardar deployment e primeiro ponto de dado, (3) atualizar a ScalingPolicy para referenciar as novas métricas, (4) configurar ScaleOutCooldown entre 60-120s dependendo do tempo de startup do task, (5) instrumentar scaling latency como SLI no seu sistema de observabilidade. Step scaling deve ser depreciado ativamente. Scheduled scaling permanece como complemento obrigatório para eventos previsíveis. Predictive scaling é uma terceira camada para serviços com sazonalidade estável e histórico suficiente. A composição dessas três estratégias — não a escolha de uma — é o padrão de produção para plataformas financeiras de alta disponibilidade.

## Referências

- [Amazon ECS introduces new high-resolution metrics for faster service auto scaling](https://aws.amazon.com/blogs/aws/amazon-ecs-introduces-new-high-resolution-metrics-for-faster-service-auto-scaling/)
- [ECS Service Auto Scaling — AWS Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
- [Application Auto Scaling — Target Tracking Scaling Policies](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)
- [CloudWatch High-Resolution Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)
- [CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/)
- [AWS Well-Architected — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)
- [CloudWatch cross-account observability](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
- [Site Reliability Engineering — Google (SLO/Error Budget)](https://sre.google/sre-book/service-level-objectives/)