A conta da cloud também é um problema de engenharia

Pedir 4 CPUs "por garantia" parece inofensivo. Multiplique por 200 pods, 24 horas por dia, 30 dias por mês. Uma reflexão sobre custo como requisito de engenharia, e não só problema do financeiro.

Fala pessoal, tudo bem?

Durante muito tempo, custo de infraestrutura era assunto de compras. O servidor era comprado, depreciado em alguns anos, e pronto. Na cloud, a lógica inverteu: cada decisão técnica vira uma linha na fatura, todo mês, para sempre.

Um requests exagerado, um ambiente de teste que ninguém desligou, um disco órfão de um cluster apagado em 2024. Nenhum deles chama atenção sozinho. Juntos, viram a conversa desconfortável do fim do trimestre.

FinOps, em uma frase: trazer o custo para perto de quem toma as decisões técnicas, para que ele seja considerado na hora de decidir, e não só na hora de pagar.

Onde o dinheiro costuma vazar

Exemplo ilustrativo: CPU de um cluster Capacidade dos nodes 100% Reservado (requests) 80% Usado de verdade 25% Pago, reservado e parado O scheduler respeita o requests, não o uso. Node "cheio" de requests sobe outro node, e outra fatura.

Os suspeitos de sempre:

• Requests superdimensionados, copiados de um exemplo ou definidos "por segurança".
• Ambientes não produtivos ligados 24/7, inclusive fins de semana.
• Recursos órfãos: discos, IPs públicos, snapshots e load balancers que sobraram.
• Logs e métricas sem retenção definida, crescendo para sempre.
• Tráfego entre zonas e regiões, que quase ninguém olha até a fatura chegar.

Exemplo: comparando o pedido com o uso

# o que cada pod está USANDO agora
$ kubectl top pods -n app-pagamentos

# o que cada pod está PEDINDO
$ kubectl get pods -n app-pagamentos -o custom-columns=\
POD:.metadata.name,\
CPU_REQ:.spec.containers[*].resources.requests.cpu,\
MEM_REQ:.spec.containers[*].resources.requests.memory

# o quanto cada node já está reservado
$ kubectl describe nodes | grep -A 5 "Allocated resources"

Se o pod pede 2 de CPU e usa 150m o dia inteiro, você encontrou dinheiro parado. Olhe em uma janela de dias, não de minutos, para não cortar o que é pico real.

💡 Novidade que ajuda: o Kubernetes 1.37 trouxe em beta o scale to zero no HPA e o "last used time" em PVCs. O primeiro desliga o que está ocioso; o segundo ajuda a achar volume esquecido.

Custo como mais um sinal de qualidade

No SRE falamos de latência, erro, tráfego e saturação. Vale incluir um quinto olhar: quanto custa servir cada requisição. Uma mudança que deixa o serviço 5% mais rápido e 300% mais caro talvez não seja uma melhoria.

Prática	Esforço	Impacto típico
Desligar ambientes de teste fora do horário	Baixo	Alto
Etiquetar recursos por time e projeto	Baixo	Alto (visibilidade)
Revisar requests pelo uso real	Médio	Alto
Política de retenção de logs	Baixo	Médio
Instâncias spot/preemptivas para lotes	Médio	Alto

⚠️ Cuidado com o corte cego: reduzir request até o pod começar a sofrer throttling ou OOMKilled não é economia, é incidente adiado. Custo é um sinal a equilibrar com confiabilidade, não a única meta.

Considerações Finais

FinOps não é sobre gastar menos a qualquer custo. É sobre gastar de propósito: saber quanto cada coisa custa, quem é dono dela e se ela ainda precisa existir.

E a melhor parte: quase sempre o primeiro passo não exige ferramenta nenhuma. Exige olhar.

Abs e até a próxima!!!

:wq!