CPU ≥ 5%: o threshold de auto scaling que inflou a conta EC2 em 14×

O sintoma: picos de custo sem pico de uso

O relatório de custos de uma aplicação transacional na AWS mostrava EC2 oscilando de forma absurda: dias de US$11/dia intercalados com dias de US$160+/dia, sem nenhuma correlação com aumento de tráfego real. 99% do custo de EC2 vinha de um único Auto Scaling Group de instâncias c6g.2xlarge.

O caso mais gritante: 1 e 2 de fevereiro custaram US$271,56, contra ~US$22,92 esperados — US$248,64 a mais em dois dias. Pico diário de US$162,34 contra uma baseline de US$11,46: 14× a conta normal.

A causa raiz: um threshold de scale-up ridículo

O alarme de scale-out do ASG estava configurado para CPU ≥ 5% por 3 datapoints de 60s. Cinco por cento. Qualquer microvariação de carga — e principalmente cada deploy, que sobe CPU momentaneamente — passava do gatilho e o ASG criava instâncias novas. Como o scale-down era conservador, a frota inflada demorava a voltar, e cada instância c6g.2xlarge extra custa por hora.

Auto scaling não é "quanto mais elástico, melhor". Um gatilho sensível demais transforma ruído em fatura — e deploys em incidentes de custo.

Como medir: Cost Explorer por USAGE_TYPE

Antes de mexer, é preciso provar de onde vem o custo. O Cost Explorer via CLI, agrupando por tipo de uso, isola o BoxUsage do ASG:

aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[].Groups[?contains(Keys[0], `BoxUsage`)]' --output table

Foi isso que revelou os picos diários concentrados nos dias de deploy — não em dias de tráfego alto.

O fix: subir o threshold e separar deploy de escala

A correção principal foi elevar o gatilho de scale-up de 5% para uma faixa realista (40–50%), com período de avaliação maior, de modo que só carga sustentada — não ruído nem deploy — provoque escala. Estimativa de economia: ~US$150/mês só nesse ASG, eliminando a frota-fantasma.

# antes (gatilho ridículo)
ScaleUpThreshold: 5      # CPU% por 3x60s  → qualquer deploy escala

# depois (carga sustentada de verdade)
ScaleUpThreshold: 45     # CPU% por 5x60s
ScaleDownThreshold: 25   # deadband saudável entre subir e descer

Cuidado complementar: o deadband entre scale-up e scale-down precisa ser largo o suficiente para não criar flapping, mas não tão largo que a frota fique presa (assunto de outro post).

Lições

1. Threshold de scale-up baixo = custo, não resiliência. 5% de CPU é ruído. Comece em 40–50% de carga sustentada e ajuste com dados.

2. Deploy escala a frota se o gatilho for sensível. Picos de custo concentrados nos dias de deploy são a assinatura do problema.

3. Meça por USAGE_TYPE antes de agir. O Cost Explorer agrupado por BoxUsage prova qual ASG/instância gera o custo, em vez de adivinhar.

Conclusão

Elasticidade é ótima quando responde a demanda real. Um gatilho de 5% responde a fantasmas: ruído de métrica e o próprio pipeline de deploy. A frota inflava, ninguém olhava o alarme, e a conta crescia 14× em silêncio. Uma linha de configuração — o threshold certo — devolveu o custo ao tamanho do uso.