Reduzir custo de cloud não é sobre cortar tudo que parece caro — é sobre eliminar o que não gera valor sem tocar no que gera. A diferença entre as duas abordagens é a diferença entre otimização inteligente e um incidente de produção às 2 da manhã.
As 5 alavancas de otimização
Não existe ordem universal — cada ambiente tem seu maior desperdício. Mas o mapa das alavancas é consistente:
1. Rightsizing de instâncias
A oportunidade mais direta. Instâncias superdimensionadas são a forma mais silenciosa de desperdiçar dinheiro em cloud — ninguém reclama, o sistema funciona, e a fatura simplesmente é mais alta do que precisaria ser.
Como identificar: CPU e memória médias abaixo de 20% por 2–4 semanas, sem picos relevantes. Como executar: ferramentas nativas (AWS Compute Optimizer, Azure Advisor) fazem as recomendações automaticamente. Impacto típico: 20–40% de redução no custo de compute.
2. Reservas e compromissos de longo prazo
Para cargas estáveis, on-demand é o modelo mais caro. Reserved Instances de 1 ano geram 30–45% de desconto. De 3 anos, 50–70%. Savings Plans têm flexibilidade maior com desconto similar.
Como identificar candidatos: instâncias rodando 24/7 há mais de 3 meses sem mudança de tipo. Impacto típico: 30–50% de redução no custo das instâncias reservadas.
3. Eliminação de recursos ociosos
Volumes não anexados, snapshots antigos, IPs elásticos não utilizados, load balancers sem target, funções Lambda sem invocação há meses, bancos de dados de homologação ligados 24/7. Cada um desses itens paga sozinho, sem fazer nada.
Como identificar: ferramentas de CSPM (Cloud Security Posture Management) ou scripts simples de inventário. Impacto: variável, mas histórico de empresas com cloud por mais de 2 anos frequentemente identifica 5–15% da fatura em recursos completamente ociosos.
4. Otimização de armazenamento
Storage parece barato por GB, mas acumula. Três oportunidades comuns:
Tiering de storage: dados acessados raramente devem estar em tiers baratos (S3 Glacier, Azure Archive). Dados em S3 Standard ou Azure Hot que não são acessados há 90 dias deveriam estar em tier mais barato — isso pode reduzir o custo de storage em 60–80% para esses dados.
Snapshots e backups redundantes: muitas empresas têm snapshots diários retidos por 90 dias e backups em múltiplos destinos sem política de ciclo de vida. Definir retenção adequada pode reduzir custos de backup significativamente.
Deduplicação e compressão: para armazenamento de logs e dados de analytics, compressão pode reduzir volume de storage em 60–80%.
5. Revisão de arquitetura
A alavanca com maior potencial e maior esforço. Alguns exemplos de mudanças arquiteturais que reduzem custo:
- Serverless para cargas intermitentes: substituir instâncias sempre ligadas por Lambda/Functions para APIs com tráfego esporádico pode reduzir custo de 80–90% para esses workloads
- CDN para reduzir egresso: servir conteúdo estático via CDN reduz custo de egresso de dados e melhora latência para usuários finais
- Banco de dados gerenciado vs instância: às vezes migrar de banco self-managed em EC2 para RDS/Cloud SQL gerenciado reduz custo operacional e de instância combinados
- Containerização e Kubernetes: workloads conteinerizados têm melhor utilização de recursos que VMs individuais
Como priorizar: impacto vs esforço
Não tente fazer tudo ao mesmo tempo. Use uma matriz simples:
| Alavanca | Impacto típico | Esforço | Risco | Prioridade |
|---|---|---|---|---|
| Eliminar recursos ociosos | 5–15% | Baixo | Baixo | Alta |
| Reservas/Savings Plans | 20–40% (sobre o aplicado) | Baixo | Baixo | Alta |
| Rightsizing | 20–40% (compute) | Médio | Médio | Alta |
| Otimização de storage | 10–30% (storage) | Médio | Baixo | Média |
| Revisão arquitetural | 30–60% (workloads revisados) | Alto | Médio | Média–Baixa |
Comece pelas ações de alto impacto e baixo esforço (eliminar ociosos e reservas). Avance para rightsizing com análise cuidadosa. Revisão arquitetural fica para quando as alavancas mais simples já foram exploradas.
O que não fazer
Não corte indiscriminadamente sem análise. Reduzir instâncias de produção sem dados de utilização — ou pior, desligar instâncias “que parecem desnecessárias” — é o caminho mais rápido para um incidente.
Não faça rightsizing de produção sem janela e sem monitoramento. Mesmo instâncias claramente superdimensionadas precisam de processo controlado para ajuste — coleta de métricas, validação em não-produção, janela de manutenção, alertas pós-mudança.
Não elimine redundância para reduzir custo. Multi-AZ, backups, replicas de leitura — existem por razões de disponibilidade e recuperação. Eliminar redundância para economizar cria risco que o custo economizado não justifica.
Não trate FinOps como evento único. Um projeto de otimização que reduz 30% do custo e depois é esquecido resulta em retorno ao patamar anterior em 6–12 meses. Otimização de cloud é prática contínua, não projeto com data de entrega.
Como criar cultura de FinOps
O problema de custo de cloud raramente é técnico — é cultural. Quando ninguém sente o custo do que consome, ninguém tem incentivo para otimizar.
Showback antes de chargeback: comece mostrando para os times quanto eles consomem (sem transferir o custo ainda). Apenas a visibilidade já muda comportamento.
Responsabilidade clara: defina quem é responsável pelo custo de cloud de cada produto ou projeto. Um dono de produto que vê o custo de infraestrutura do produto dele junto às métricas de receita toma decisões diferentes.
Custo como critério de design: em revisões de arquitetura, custo de infraestrutura deve aparecer ao lado de performance e segurança como critério de avaliação — não como reflexão posterior.
Rituais de revisão: reunião mensal de custo de cloud, com presença de TI, produto e finanças. Não precisa ser longa — 30 minutos para olhar os maiores gastadores, anomalias e progresso das otimizações planejadas.
Resultados realistas nos primeiros 6 meses
Empresas que implementam FinOps pela primeira vez, com ambiente de cloud de médio porte (USD 10.000–100.000/mês), geralmente conseguem:
- Primeiros 30–60 dias: identificação de 15–30% de oportunidade de redução (análise, sem execução ainda)
- 60–90 dias: redução de 10–20% implementada (ociosos eliminados, reservas feitas)
- 3–6 meses: redução acumulada de 20–40% no custo de compute, com processos contínuos estabelecidos
Esses números assumem que a empresa não tinha nenhuma prática de FinOps antes. Para empresas que já têm algumas práticas, o espaço é menor — mas ainda existe.
A Adentro oferece visibilidade de custo e processo de rightsizing em conjunto com clientes de cloud privada — ajustando contratos para refletir uso real e garantindo que você paga pelo que precisa, não pelo que foi provisioned no passado.