Otimização de custo cloud: do FinOps às decisões de engenharia

As quatro camadas de custo cloud

Otimização de custo cloud é normalmente apresentada como um problema de ferramenta: pegue um dashboard de cost management, encontre recursos ociosos, compre reservas. As ferramentas importam, mas tratam apenas de uma pequena parte da história. A disciplina real de custo opera em quatro camadas, em ordem de alavancagem:

1. Visibilidade. Você não pode otimizar o que não consegue medir. Atribuição de custo a times, serviços e ambientes é a base.
2. Otimização de taxa. Comprar compute mais barato via commitments, savings plans e instâncias spot.
3. Otimização de uso. Rodar menos recursos ou recursos menores via rightsizing, autoscaling e desligamento automatizado.
4. Otimização arquitetural. Desenhar sistemas cuja natureza consome menos cloud para o mesmo valor de negócio.

Times que param nas duas primeiras camadas normalmente deixam metade do potencial de economia na mesa. A máquina virtual mais barata é a que você nunca precisou ligar.

Visibilidade é inegociável

A primeira coisa que um programa de custo precisa é uma resposta mensal crível para "para onde foi o dinheiro?" Se a conta é um único item por cloud, a conversa nem começa. O detalhamento mínimo útil é por ambiente (prod / não-prod), por serviço ou time, e por categoria de custo (compute / storage / rede / serviços gerenciados / data transfer).

O mecanismo é tagueamento consistente. Todo recurso carrega tags de dono, ambiente, serviço e centro de custo. Os relatórios do provedor então agregam por tag. A maioria dos provedores também suporta cost categories ou views customizadas para deixar a visão legível.

Quando você tem os dados, compartilhe. Times de engenharia que veem o próprio custo começam a tomar decisões diferentes quase imediatamente. Só a visibilidade, sem mudança de política, costuma reduzir gasto entre 5 e 15 porcento por efeitos comportamentais.

Otimização de taxa: comprometa, mas com inteligência

Para workloads estáveis, savings plans, instâncias reservadas e committed-use discounts reduzem gasto de compute em 30 a 70 porcento. São economias grandes e bem documentadas. O risco é se comprometer com capacidade da qual você não precisa mais.

Algumas regras que funcionam:

• Comprometa apenas o piso. Olhe os últimos 12 meses de uso e comprometa o menor baseline mensal, não a média. O que estiver acima do piso fica on-demand.
• Prefira commitments flexíveis. Compute Savings Plans (AWS) ou CUDs flexíveis (GCP) costumam ser melhores do que reservas específicas de família de VM para organizações cujas cargas mudam ao longo do tempo.
• Distribua prazos. Mix de commitments de 1 ano e 3 anos balanceia otimização com flexibilidade.
• Use compute spot/preemptível para cargas elásticas. Jobs em batch, build agents, workers stateless. Economias de 60 a 90 porcento em relação ao on-demand são comuns; o trade-off é lidar com interrupções.

Reveja a carteira de commitments todo trimestre. Cargas mudam. Commitments perfeitos há seis meses podem virar ociosos.

Otimização de uso: rightsize e desligue

A carga mais barata é a que não roda. Depois de visibilidade e otimização de taxa, as próximas maiores economias vêm de rodar menos.

• Rightsize de compute. A maior parte das cargas é provisionada para um pico que nunca acontece. Ferramentas contínuas de rightsizing (AWS Compute Optimizer, Azure Advisor, GCP Recommender) dão sugestões acionáveis.
• Autoscaling agressivo. HPA, scaling baseado em fila, autoscaling preditivo. Médias estáveis escondem realidade picada.
• Desligar não-produção à noite e nos finais de semana. Ambientes de dev e staging rodando 24/7 custam como produção entregando metade do valor. Automação que os desliga fora do horário útil é um dos projetos de maior ROI em custo.
• Excluir recursos órfãos. Volumes desanexados, snapshots antigos, load balancers ociosos, IPs sem uso. Todo cloud tem. Varreduras automatizadas regulares mantêm sob controle.
• Tiering de storage. Mova dados pouco acessados para camadas mais frias. A diferença de preço é enorme. Lifecycle rules automatizam.

Arquitetura é, de longe, a maior alavanca

As vitórias de otimização que compõem ano após ano são arquiteturais. Uma carga que cabe no modelo de custo do cloud é dramaticamente mais barata do que uma que briga com ele. Alguns padrões de alta alavancagem:

Cultura de engenharia é o que torna a economia sustentável

Os programas de custo que mantêm os ganhos são aqueles em que engenheiros enxergam custo como parte da qualidade do design, assim como latência ou confiabilidade. Os elementos culturais que constroem isso:

• Showback ou chargeback. Times veem o próprio gasto. Sem isso, custo é problema de outra pessoa.
• Custo como requisito não funcional. Reviews de design incluem "quanto isso vai custar para operar?" lado a lado com performance e segurança.
• Unit economics em dashboards. Custo por pedido, por usuário ativo, por requisição. Tendência importa mais do que valor absoluto.
• Dono de custo por serviço. Alguém é responsável pela tendência de custo de cada serviço relevante.
• Celebrar vitórias de custo. Reconhecimento público para engenheiros que reduzem custo sem prejudicar a experiência do usuário.

Métricas que valem acompanhar

Gasto total é uma vanity metric. Unit economics e eficiência é que dizem se o programa está funcionando.

• Custo por unidade de negócio. Custo por pedido, por usuário, por transação, por gigabyte processado.
• Cobertura de commitments. Percentual do compute elegível sob savings plans ou reservas.
• Utilização dos commitments. Percentual da capacidade comprometida efetivamente usada. Abaixo de 95 porcento significa que comprometeu demais.
• Percentual de recursos ociosos. Compute e storage rodando abaixo dos limiares úteis de utilização.
• Cobertura de tags. Percentual do gasto atribuível a um time ou serviço. Gasto sem tag é gasto não gerenciado.