Auto-scaling na nuvem: como dimensionar sem desperdiçar (e sem susto na fatura)

Elasticidade é a característica mais vendida da computação em nuvem — e a mais mal implementada. A maioria dos times configura auto-scaling para subir, mas esquece de configurar para descer. O resultado: instâncias ociosas rodando 24 horas por dia pagando à toa. Este artigo explica como dimensionar corretamente e como isso se conecta diretamente à sua fatura.

O que é elasticidade na nuvem

Elasticidade é a capacidade de expandir e contrair recursos computacionais automaticamente conforme a demanda. Na prática, significa que em picos de tráfego você tem mais servidores, e às 3h da manhã com tráfego zerado, você tem o mínimo necessário — e paga por isso.

O que muda entre os provedores é o mecanismo de implementação:

• AWS — Auto Scaling Groups (ASG) para EC2; Application Auto Scaling para serviços gerenciados (ECS, DynamoDB, Aurora).
• Google Cloud — Managed Instance Groups (MIG) com Autoscaler; no GKE, o Cluster Autoscaler e o HPA do Kubernetes.
• Azure — Virtual Machine Scale Sets (VMSS); no AKS, Cluster Autoscaler integrado.

Por que o auto-scaling sozinho não resolve o custo

Três armadilhas que todo time encontra:

• Scale-down muito conservador: a política padrão de muitos times é escalar para cima rápido e para baixo devagar (para evitar instabilidade). Resultado: capacidade ociosa constante. A regra prática: scale-up em 2 minutos, scale-down em 15 minutos após estabilização.
• Ambientes de desenvolvimento rodando 24/7: dev e staging não precisam rodar fora do horário comercial. Um scheduler simples que desliga às 20h e liga às 8h economiza até 65% do custo desses ambientes.
• Instâncias superdimensionadas: a instância que foi escolhida "por segurança" na migração roda com 15% de CPU em média. Rightsizing (ajustar para o tipo correto) costuma ser a maior oportunidade de economia — sem nenhuma mudança de arquitetura.

Métricas corretas para acionar o auto-scaling

CPU ainda é a métrica mais usada, mas não é sempre a mais útil. Para aplicações web, o número de requisições por segundo ou a latência P99 são melhores indicadores de quando escalar. Para filas, o tamanho da fila é o sinal correto.

Nos três clouds é possível usar métricas customizadas do Prometheus ou CloudWatch/Cloud Monitoring para acionar o auto-scaling — o que dá muito mais precisão do que CPU média.

FinOps: a disciplina que une elasticidade e custo

FinOps é a prática de dar visibilidade e responsabilidade sobre os custos cloud para as equipes técnicas — sem paralisar a operação. O auto-scaling bem configurado é uma das ferramentas, mas o FinOps vai além: Reserved Instances e Savings Plans para workloads previsíveis, revisão de dados em storage S3/GCS/Azure Blob que ninguém acessa há meses, e tagueamento de recursos para saber exatamente qual squad está gastando o quê.