Otimização de custo

Otimizar custo de nuvem tem uma ordem que importa. Comece pelo desperdício puro (o que não entrega valor nenhum), depois ajuste o que está superdimensionado, e só então negocie preço com compromissos. Fazer na ordem inversa é o erro clássico: comprar reserva de três anos para instâncias que estavam grandes demais congela o desperdício por três anos.

1. Desligue o que ninguém usa

O item com melhor retorno e menor risco. Recursos que aparecem em toda conta:

# volumes desanexados
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].{id:VolumeId,gb:Size,criado:CreateTime}' --output table
# IPs elásticos alocados sem uso
aws ec2 describe-addresses --query 'Addresses[?!AssociationId].PublicIp'
# balanceadores sem alvo saudável, snapshots antigos, imagens não usadas,
# clusters de teste, bancos de POC que viraram permanentes

Some a isso o log em debug em produção, retenção infinita e ambientes de projetos encerrados. Vale um mutirão trimestral com a lista acima — costuma render mais que meses de ajuste fino.

2. Ambientes que não precisam ficar ligados

Desenvolvimento e homologação raramente são usados fora do horário comercial. Desligar das 20h às 8h e nos fins de semana corta cerca de 65% do tempo ligado.

# agendamento simples: escalar para zero à noite, voltar de manhã
kubectl scale deployment --all --replicas=0 -n homologacao
# em nuvem: instance scheduler, ou um cron chamando a API

Funciona para instâncias, clusters de teste e bancos não críticos. Combine com ambiente efêmero por pull request e TTL automático — o ambiente nasce, serve e morre sozinho.

3. Rightsizing com dado, não com achismo

Superdimensionamento é a regra, não a exceção: o padrão é provisionar “com folga” e nunca revisar.

# Kubernetes: quanto foi pedido contra quanto é usado, por workload
sum by (namespace, pod) (rate(container_cpu_usage_seconds_total[7d]))
  / sum by (namespace, pod) (kube_pod_container_resource_requests{resource="cpu"})

Olhe percentil alto de 14 a 30 dias (p95/p99), não a média — dimensionar pela média gera throttling no pico. Reduza em passos, observe latência e erro, e repita. Nunca faça rightsizing sem olhar a métrica de sintoma junto.

Aproveite também para revisar família de instância: gerações mais novas costumam entregar mais desempenho pelo mesmo preço, e processadores ARM (Graviton, Ampere) reduzem 20–40% quando a sua stack compila para eles.

4. Spot e interrupção

Instâncias spot custam uma fração e podem ser retomadas com aviso curto. Servem bem para: workers de fila, CI, processamento em lote, ambientes não produtivos e — com cuidado — parte da capacidade de serviços sem estado.

O que torna spot seguro:

• Misture spot com sob demanda: a base do serviço em capacidade garantida, o excedente em spot.
• Diversifique tipos e zonas — interrupção costuma atingir um tipo específico.
• Trate o aviso de interrupção: drene o nó, encerre com graça, tenha PodDisruptionBudget.
• Nunca em banco, nem em nó de control plane, nem em job longo sem ponto de retomada.

5. Compromissos: reservas e planos de economia

Depois de eliminar desperdício e ajustar tamanho, negocie preço. Descontos de 20% a 60% em troca de compromisso de 1 ou 3 anos.

A regra prática: comprometa apenas a linha de base — o consumo que existiria mesmo no mês mais fraco, tipicamente 60% a 70% do uso atual. O restante fica sob demanda e spot. Prefira instrumentos flexíveis (Savings Plans, compromisso por gasto e não por SKU), e prazo de 1 ano quando a arquitetura ainda muda.

Revise a cobertura mensalmente: compromisso ocioso é desperdício com contrato.

6. Armazenamento e ciclo de vida

{
  "Rules": [{
    "ID": "arquivar-relatorios",
    "Status": "Enabled",
    "Filter": { "Prefix": "relatorios/" },
    "Transitions": [
      { "Days": 30,  "StorageClass": "STANDARD_IA" },
      { "Days": 90,  "StorageClass": "GLACIER_IR" }
    ],
    "Expiration": { "Days": 1825 },
    "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
  }]
}

Atenção a três detalhes: classes frias cobram por recuperação (ruim para dado acessado com frequência), versionamento sem regra de expiração acumula versões antigas para sempre, e uploads multipart incompletos ocupam espaço invisível no console.

7. Tráfego: o custo que ninguém prevê

Repetindo o que a página de rede na nuvem mostra, porque é onde mais aparece surpresa: NAT Gateway processando o que deveria ir por endpoint privado, tráfego entre zonas em aplicações conversadoras, e saída direta da região em vez de CDN. Ative Flow Logs, meça, e trate os três.

Faça disso um hábito

Otimização em mutirão volta ao ponto inicial em seis meses. O que sustenta é:

• Revisão mensal de 30 minutos com os maiores gastos por time.
• Estimativa de custo no pull request, para decidir antes de gastar.
• Metas por time em custo unitário, não em custo absoluto — o assunto da próxima página.

E o principal: não otimize o que não importa. Uma equipe passando um mês para economizar R$ 300 mensais custou mais caro que o problema.

Próximo passo: troque “gastamos muito” por uma métrica que sobrevive ao crescimento em Unit economics.