Auto Scaling para Economia

Auto Scaling é mais conhecido como ferramenta de disponibilidade e desempenho, mas seu papel financeiro é igualmente decisivo: elasticidade bem configurada é o mecanismo que paga por capacidade apenas quando ela trabalha. O custo de uma infraestrutura dimensionada para o pico e ociosa no vale é o oposto da promessa da nuvem, e o overprovisioning permanente é o desperdício mais comum e mais invisível de todas as contas de nuvem. O padrão cobre dois mecanismos distintos: escala dinâmica, que reage a métricas de carga em tempo real, e escala agendada, que antecipa padrões previsíveis de tráfego e desliga ambiente fora do horário. Somado ao right-sizing, que ajusta o tamanho das unidades pela utilização real medida, o auto scaling transforma a curva de custo em curva de consumo. O arquivo cobre a economia como objetivo explícito, os mecanismos de agendamento, o desligamento de ambientes não produtivos, o right-sizing orientado a dados e as métricas de eficiência que provam o resultado.

Conceito

A economia da elasticidade vem de uma identidade simples: custo é capacidade provisionada multiplicada por tempo, e a nuvem cobra pelo provisionado, não pelo usado. Provisionar para o pico anual significa pagar o pico nas 8.760 horas do ano, ainda que o pico dure 200. O auto scaling reduz o termo capacidade na maior parte do tempo, e cada hora em que uma réplica ociosa não existe é economia líquida sem perda de desempenho, desde que as políticas acompanhem a demanda de perto.

Essa afirmação tem uma condição de contorno que separa desenho maduro de acidente: escala para economizar exige que o caminho de redução seja tão confiável quanto o de aumento. Serviços que escalam rápido para cima e lento para baixo pagam hora inteira de capacidade residual toda vez que o tráfego cai, e o prejuízo acumulado rivaliza com o de não escalar. O cooldown, o período de estabilização das métricas e o critério de redução são, no plano financeiro, os componentes mais importantes da política.

• Provisionamento por pico: capacidade fixa dimensionada para demanda máxima, custo constante e desperdício proporcional à variação.
• Escala dinâmica: capacidade segue métricas de carga, com política de aumento e de redução explícitas.
• Escala agendada: capacidade segue calendário conhecido, sem esperar métrica e sem custo de reação.
• Right-sizing: ajusta o tamanho das unidades provisionadas pela utilização observada, complementando a escala horizontal.

A distinção entre os mecanismos tem um caso de fronteira que merece atenção: eventos de demanda conhecida, mas esporádica, como lançamentos, Black Friday e transmissões ao vivo. Agendamento sozinho paga capacidade por dias em volta do evento, e dinâmica sozinha reage tarde em saltos verticais de tráfego. A combinação correta agenda uma faixa base conservadora para a janela do evento e deixa o target tracking absorver a variação em volta dela, custo e risco equilibrados.

O problema que resolve

O primeiro alvo é o custo de capacidade ociosa. Um serviço com pico de 40 réplicas às 12h e vale de 6 réplicas às 3h paga, sem auto scaling, 40 réplicas nas 24 horas, o que representa cerca de 85% de horas pagas sem trabalho. Esse padrão é a norma em e-commerce, em sistemas internos e em qualquer negócio com horário comercial, e o auto scaling agendado resolve a maior parte dele sem nenhuma engenharia sofisticada.

O segundo alvo é a inércia de ambiente de desenvolvimento e homologação. Ambientes não produtivos somam frequentemente 20% a 40% da conta e trabalham 40 horas por semana, ou seja, menos de um quarto do tempo. Desligá-los fora do horário e nos fins de semana é a otimização com melhor relação entre esforço e retorno em praticamente qualquer organização, e é executável inteiramente com infraestrutura como código.

O terceiro alvo é a assimetria entre time de engenharia e dono de orçamento. Sem um mecanismo automático que vincule capacidade a demanda, toda revisão de custo vira conversa manual sobre desligar coisas, e a conversa sempre perde para a preocupação de disponibilidade. Políticas de escala com números explícitos transformam essa negociação em configuração revisável, com piso garantido para disponibilidade e teto que protege o orçamento, e é justamente essa objetividade que faz a prática sobreviver ao tempo.

Escala agendada

A escala agendada é o mecanismo de escolha quando a demanda é previsível por calendário, e tem duas aplicações canônicas. A primeira é o tráfego de negócio com forma conhecida, com aumento suave antes do horário de pico, às 7h de segunda a sexta, e redução depois das 20h; agendar com antecedência evita o atraso de reação das políticas dinâmicas, pois instâncias de cold start não nascem no segundo do pico. A segunda é o ciclo de ambientes não produtivos, ligando o ambiente no início do expediente e desligando ao fim, com exceções automatizadas para fins de semana de deploy ou de teste de carga.

# Escala agendada de Auto Scaling Group para economia (perfil em UTC)
scheduled_actions:
  - name: escala-abertura-7h
    schedule: "0 10 * * 1-5"      # 07h em -03:00, seg a sex
    min_size: 4
    max_size: 12
    desired_capacity: 6
  - name: escala-pico-almoco
    schedule: "0 14 * * 1-5"      # 11h local, antecipa o almoço
    desired_capacity: 10
  - name: escala-encerramento-20h
    schedule: "0 23 * * 1-5"      # 20h local, reduz para o vale
    desired_capacity: 2
    min_size: 2
  - name: fim-de-semana-minimo
    schedule: "0 5 * * 6,0"       # 02h de sábado e domingo
    desired_capacity: 2
    min_size: 2

Para ambientes completos, a alternativa ao ajuste de réplicas é o desligamento total por agendamento, desativando RDS fora do expediente, parando clusters ECS ou EKS de homologação e escalando para zero filas de consumo. Escalar para zero é a expressão máxima da economia por elasticidade, e funciona bem para workers assíncronos que não precisam existir sem mensagem na fila.

Escala dinâmica

A escala dinâmica cobre o que o calendário não prevê, e a política de referência em AWS é o target tracking, que mantém uma métrica alvo, como 60% de CPU ou 1.000 requisições por instância, ajustando a frota automaticamente para cima e para baixo. Para fins financeiros, o ajuste fino relevante está no passo de redução: políticas de scale-in com reserva, mantendo mínimo de réplicas e capacidade de absorver ruído curto de métrica sem oscilar, economizam mais que políticas agressivas de aumento, porque o excesso é a regra e o pico é a exceção.

# Políticas de target tracking em um ASG com foco em eficiência
target_tracking_policies:
  - name: cpu-alvo-60
    target_value: 60                 # alvo de utilização por instância
    predefined_metric: ASGAverageCPUUtilization
    scale_in_cooldown: 600           # 10 min antes de reduzir de novo
    scale_out_cooldown: 180          # reagir rápido para subir
  - name: fila-consumida-por-worker
    target_value: 50                 # 50 mensagens pendentes por worker
    customized_metric: FilaPendentesPorInstancia
    scale_in_cooldown: 900           # redução conservadora
min_size: 2                          # piso para disponibilidade
max_size: 30                         # teto que protege a conta

O teto de escala máxima é o anteparo financeiro do desenho: sem max_size claro, um bug que gera loop de carga escala a conta em horas, e o alarme de orçamento chega tarde demais. Combinar o teto com alarme de escala que atinge 80% do máximo fecha o circuito de proteção.

Right-sizing orientado a dados

Right-sizing é o complemento vertical da elasticidade horizontal, e o dado que o sustenta é a utilização medida em produção, nunca a estimativa de arquitetura. A rotina prática cruza métricas de CPU, memória, IOPS e tráfego de rede por recurso em uma janela de duas a quatro semanas, elimina recursos recém-criados da análise e classifica cada um em três destinos: manter, reduzir tamanho ou redesenhar. Recursos com utilização máxima abaixo de 20% ao longo do período são candidatos diretos a uma ou duas classes menores.

• Janela mínima de observação: duas semanas cobre ciclos semanais; quatro semanas captura rotinas mensais como fechamento e batch pesado.
• Métrica de memória obrigatória: CPU sozinha engana, e CloudWatch agent com métricas de memória é pré-requisito para right-sizing honesto.
• P99 antes da média: dimensionar pela média destrói a cauda; o tamanho novo precisa comportar o percentil 99 de demanda.
• Mudança reversível: right-sizing é aplicado por lote pequeno, com janela de reversão, pois o custo de uma classe acima é menor que um incidente.

Overprovisioning e seus custos

O custo do excesso de provisionamento é mais amplo que a linha da fatura de EC2. Capacidade provisionada paga em banco de dados, como IOPS reservadas em RDS ou unidades de throughput em DynamoDB, segue a mesma lógica e costuma ser a parcela de desperdício mais caras. Excesso de réplica também multiplica sidecars, agentes de telemetria e licenças, e cada nó adicional carrega a sobra operacional de milhares de megabytes de memória de infraestrutura. Em escala, a conta do desperdício não lineariza, ela compõe.

A resposta estrutural é política, não heroísmo pontual: cota de ambiente por time com revisão, exigência de utilização mínima para aprovar nova capacidade e comparação de custo por unidade de trabalho entre versões. Times que veem o custo da própria capacidade na fatura do sprint corrigem o excesso naturalmente, e é por isso que tagging e showback, tratados em arquivo próprio, são pré-requisitos dessa disciplina.

Serverless desloca o problema, mas não o elimina. Lambda cobra por GB-segundo executado, e funções com memória superestimada desperdiçam na mesma proporção que instâncias grandes ociosas; ferramentas de profiling de Lambda que testam combinações de memória e potência de CPU ajustam o tamanho ao mínimo que respeita a latência alvo. O mesmo vale para contêineres em Fargate, onde a combinação de vCPU e memória escolhida no task definition é a versão moderna do right-sizing, e para provisioned concurrency, que reintroduz a pergunta de quantos ambientes quentes manter e em que horário.

Métricas de eficiência

Economia precisa de métrica para se sustentar politicamente, e as três medidas centrais formam um painel mínimo. Custo por requisição, ou por mil requisições, normaliza o gasto pela demanda e revela se a eficiência melhora com o crescimento. Custo por tenant e custo por ambiente dão a leitura de atribuição, e o coeficiente de utilização, a fração de capacidade provisionada que efetivamente trabalha, mede o tamanho do bolso ocioso remanescente.

A leitura combinada importa mais que cada número isolado. Custo por mil requisições subindo com utilização estável indica que a demanda está mudando de forma, e não que o time desperdiça; utilização baixa com custo por requisição estável pode ser arquitetura intencional de latência baixa. A métrica abre a pergunta, e o contexto responde.

A publicação da eficiência por time, no formato de ranking simples e revisão trimestral, é o mecanismo que converte métrica em comportamento. Times em competição saudável de eficiência encontram otimizações que nenhum comitê central encontraria, e o ranking evita a antipatia típica de controles financeiros impostos de cima, porque a comparação é entre unidades de trabalho equivalentes e não entre negócios de natureza distinta.

Erros comuns

• Politicamente por métrica errada: escala por CPU em aplicação I/O bound não economiza nem protege, pois a CPU nunca é o gargalo real.
• Cooldown simétrico demais: redução tão lenta quanto o aumento paga horas de capacidade residual todos os dias, invertendo a economia.
• Agendamento sem fuso correto: horários em UTC contra tráfego local, e o ambiente desliga no meio do expediente.
• Desligar o que não deve desligar: agente de backup, sincronização noturna ou teste de segurança dependente do ambiente fora do horário.
• Right-sizing pela média: réplica dimensionada pela média de CPU quebra no percentil 99 e vira incidente em poucos dias.
• Auto scaling como desculpa: postergar correção de arquitetura ineficiente prometendo que a elasticidade compensa o desperdício.
• Janela de warm-up ignorada: métrica de aplicação fria distorce o target tracking logo após o aumento, causando oscilação de frota.
• Escala sem teto: max_size indefinido ou generoso demais transforma um bug de loop de carga em estouro de fatura em horas.

Boas práticas

Comece pela economia de maior retorno e menor risco, que é o ciclo de ambientes não produtivos, medindo a economia obtida e publicando o número, pois esse primeiro resultado compra credibilidade para otimizações seguintes. Para cargas produtivas, combine escala agendada no esqueleto diário com escala dinâmica nas bordas de variação, e alinhe o período de redução ao perfil real de decadência do tráfego. Execute right-sizing em ciclos trimestrais com dados de utilização completos e mudanças em lote reversível. Por fim, ancore tudo nas métricas de eficiência por unidade de trabalho, porque elasticidade que só reduz números absolutos, mas piora o custo por requisição, é economia de fachada.

Documente o piso, o teto e a política de escala de cada serviço em infraestrutura como código e submeta essas decisões a revisão como qualquer mudança de produção, pois escala é contrato de disponibilidade e de orçamento ao mesmo tempo. Revise os agendamentos quando o negócio mudar de forma, incluindo fusos de campanhas internacionais e calendários sazonais, já que a economia agendada envelhece na velocidade do calendário comercial.

Meça cada otimização com antes e depois na mesma métrica de unidade de trabalho, e mantenha o histórico em um registro vivo de decisões de FinOps, porque o relato de economia provada é o capital que financia a próxima rodada de ajustes. Elasticidade gerida com essa disciplina entrega a promessa original da nuvem, pagar por trabalho e não por ociosidade, com a conta para demonstrar.