Sua conta da AWS, Azure ou Google Cloud chega todo mês. E todo mês ela aumenta um pouco. Você olha as centenas de serviços rodando, as dezenas de instâncias, os armazenamentos de dados – e não sabe exatamente para onde está indo tanto dinheiro. A pior parte? Grande parte desse custo é desperdício: recursos superdimensionados, instâncias ligadas 24/7 sem necessidade, dados antigos ocupando espaço caro.
FinOps é a disciplina que coloca você de volta no controle. É uma prática operacional e cultural que combina finanças, engenharia e operações para otimizar gastos em cloud – sem sacrificar performance ou escalabilidade.
Neste post, vamos mostrar como implementar FinOps na prática, com métricas, ferramentas e estratégias que geram economia imediata. Incluindo resultados reais de clientes Jacobus que reduziram custos em cloud entre 30% e 50%.
O que é FinOps?
FinOps (Financial Operations) é um conjunto de práticas que torna a gestão de custos em cloud uma responsabilidade compartilhada entre times de engenharia, finanças e produto. O objetivo não é só cortar gastos, mas otimizar o valor gerado por cada dólar gasto em cloud.
Os três pilares do FinOps
| Pilar | O que faz | Exemplo |
|---|---|---|
| Informar | Dá visibilidade e accountability | Dashboards por time, tagging de recursos |
| Otimizar | Reduz desperdício e melhora eficiência | Redimensionar instâncias, comprar Reserved Instances |
| Operar | Cria processos contínuos | Alertas de orçamento, políticas de shutdown automático |
Estratégia 1: Tagging – a base de tudo
Se você não sabe quem está gastando o quê, não pode otimizar. Tagging (etiquetagem de recursos) é a prática de adicionar metadados a cada recurso da cloud: time, projeto, ambiente, centro de custo.
Exemplo de tags essenciais:
| Tag | Valor | Por que |
|---|---|---|
cost-center | marketing, engenharia, produto | Aloca gasto por departamento |
environment | dev, staging, prod | Diferencia custo de desenvolvimento vs produção |
project | checkout-v2, migration-2026 | Identifica custo de projetos específicos |
owner | time-plataforma | Saber quem é responsável |
auto-shutdown | true/false | Controla desligamento automático fora do horário |
Como implementar:
- Defina política obrigatória de tags para novos recursos.
- Use ferramentas como AWS Config ou Azure Policy para validar.
- Crie dashboards no AWS Cost Explorer ou CloudHealth agrupados por tags.
Resultado: você descobre, por exemplo, que o ambiente de desenvolvimento de um time custa R$ 15k/mês – e metade disso são instâncias rodando 24/7 sem necessidade.
Estratégia 2: Rightsizing – do tamanho certo
Rightsizing é o processo de ajustar o tamanho das instâncias (EC2, RDS, Kubernetes nodes) à demanda real. A maioria das empresas superdimensiona recursos “por via das dúvidas”.
Como fazer rightsizing:
- Analise métricas de utilização – CPU, memória, I/O. Para a maioria dos workloads, utilizar abaixo de 40% da CPU é sinal de superdimensionamento.
- Identifique candidatos – Use ferramentas como AWS Compute Optimizer, Azure Advisor ou Google Cloud Recommender.
- Redimensione gradualmente – Comece por instâncias de desenvolvimento/homologação. Para produção, faça teste de carga após o redimensionamento.
Exemplo real (cliente Jacobus):
| Serviço | Antes | Depois | Economia mensal |
|---|---|---|---|
| API principal (Go) | 4 instâncias (t3.xlarge) | 4 instâncias (t3.large) | R$ 1.200 |
| Banco de dados | db.r5.xlarge | db.r5.large | R$ 800 |
| Workers (Go) | 6 instâncias (c5.xlarge) | 6 instâncias (c5.large) | R$ 1.500 |
Total mensal economizado: R$ 3.500 (cerca de 35% do custo original).
Estratégia 3: Savings Plans e Reserved Instances (RIs)
Se seu workload é previsível (ex: produção 24/7), compensa comprar capacidade reservada. Os descontos são significativos:
| Modelo | Desconto típico | Flexibilidade | Ideal para |
|---|---|---|---|
| On-Demand | 0% | Máxima | Testes, workloads imprevisíveis |
| Savings Plans | 30-60% | Média (família de instâncias) | Workloads consistentes |
| Reserved Instances (RIs) | 40-75% | Baixa (instância específica) | Workloads estáveis, previsíveis |
Exemplo prático:
- Custo on-demand de uma instância c5.large: R$ 300/mês
- Savings Plan (3 anos, pagamento antecipado): ~R$ 120/mês
- Economia: 60% → R$ 180/mês por instância.
Se você tem 20 instâncias em produção, a economia anual ultrapassa R$ 43.000.
Cuidado: reserve apenas o que você realmente vai usar. Instâncias reservadas e não utilizadas são desperdício puro.
Estratégia 4: Desligamento de ambientes não produtivos
Ambientes de desenvolvimento e homologação geralmente ficam ligados 24/7, mas só são usados em horário comercial. Desligá-los fora do expediente gera economia imediata.
Como implementar:
- Use scripts de automação (AWS Lambda, Azure Automation, Google Cloud Scheduler) para desligar recursos às 20h e ligar às 8h.
- Marque recursos com tag
auto-shutdown: true. - Para bancos de dados, faça snapshot antes de desligar.
Economia potencial: Um ambiente de desenvolvimento com 10 instâncias (cada R200/me^s)custaR 2.000/mês. Desligado 16h por dia + finais de semana, o uso real é de ~30% → economia de R$ 1.400/mês.
Estratégia 5: Spot Instances para workloads tolerantes a falhas
Spot Instances são capacidade ociosa de cloud com desconto de até 90%, mas que podem ser interrompidas com aviso de 2 minutos. Perfeitas para workloads tolerantes a falhas.
Ótimos casos para Spot:
- Workers de processamento em lote
- Pipelines de CI/CD (executores do GitHub Actions)
- Ambientes de teste e desenvolvimento
- Processamento de dados não crítico
Para workloads em Go: aplicações concorrentes se beneficiam especialmente de Spot, pois podem distribuir trabalho entre instâncias spot e on-demand.
Exemplo: um cliente Jacobus roda workers de processamento de eventos NATS em Spot Instances. Economia de 70% no custo de computação da parte assíncrona do sistema.
Estratégia 6: Armazenamento em camadas (storage tiering)
Dados antigos não precisam estar em armazenamento caro.
| Camada | Custo relativo | Latência | Ideal para |
|---|---|---|---|
| SSD (gp3, io2) | 1x | <1ms | Dados quentes, bancos de produção |
| HDD (st1, sc1) | 0,5x | ~10ms | Logs recentes, backups temporários |
| Archive (Glacier, Archive) | 0,05x | minutos/horas | Logs antigos, backups de longo prazo |
Lifecycle rules: configure políticas automáticas (ex: após 30 dias mover para HDD, após 90 dias para Archive).
Exemplo: um cliente que armazenava 50TB de logs de acesso em SSD reduziu o custo de armazenamento de R7.500/me^sparaR 600/mês movendo para camada de archive após 30 dias.
Estratégia 7: Monitoramento contínuo com dashboards e alertas
Implemente um dashboard de FinOps com:
- Custo por time/projeto (usando tags)
- Custo por ambiente (dev, staging, prod)
- Eficiência: custo por requisição, custo por usuário ativo
- Forecast de custo para os próximos meses
Alertas configuráveis:
- Orçamento mensal (ex: alerta quando atingir 80% do orçamento)
- Pico inesperado (ex: +50% de custo em 24h)
- Recursos sem tags (para forçar governança)
Ferramentas gratuitas/embutidas: AWS Cost Explorer (com Anomaly Detection), Azure Cost Management, Google Cloud Billing.
Quanto dá para economizar? Dados reais
| Estratégia | Economia potencial típica | Esforço |
|---|---|---|
| Rightsizing | 20-40% | Médio |
| Savings Plans / RIs | 30-60% | Baixo (compra única) |
| Desligamento de ambientes dev | 50-70% (sobre esses ambientes) | Baixo |
| Spot Instances | 60-90% (sobre essas cargas) | Médio |
| Storage tiering | 50-90% (sobre dados antigos) | Baixo |
| Combinação típica (cliente Jacobus) | 30-50% de redução total | Médio |
Ferramentas recomendadas
| Nome | Tipo | Diferencial |
|---|---|---|
| AWS Cost Explorer | Nativa | Integrada, Anomaly Detection |
| Azure Cost Management | Nativa | Integração com Power BI |
| Google Cloud Billing | Nativa | Recomendações de rightsizing |
| CloudHealth (VMware) | Terceiro | Multi-cloud, governança |
| Vantage | Terceiro | Mais simples, Terraform integrado |
| OpenCost | Open source | Nativo Kubernetes |
Erros comuns em FinOps
| Erro | Consequência | Correção |
|---|---|---|
| Focar só em corte de custo | Pode afetar performance | Otimize por eficiência (custo/requisição) |
| Reservar capacidade sem usar | RIs/SPs subutilizados | Monitore utilização antes de comprar |
| Não taggear recursos | Não sabe quem gastou o quê | Política obrigatória de tags |
| Desligar recurso crítico | Incidente de produção | Teste desligamento automático em dev primeiro |
Caso real: empresa de e-commerce reduz custo em 42%
Um cliente marketplace com cerca de 80 microsserviços em Go tinha fatura mensal de cloud de R$ 120 mil. A Jacobus implementou FinOps:
- Tagging de todos os recursos por time e ambiente.
- Rightsizing de instâncias (API Go passou de t3.xlarge para t3.large).
- Savings Plans de 1 ano para produção.
- Desligamento automático de ambientes dev/staging fora do horário comercial.
- Spot Instances para workers assíncronos (processamento de eventos NATS).
- Storage tiering para logs (30 dias em HDD, depois Archive).
Resultados:
- Fatura mensal: R120k→R 70k (-42%)
- Economia anual: R$ 600 mil
- Investimento (consultoria + ferramentas): R$ 80 mil
- Payback: menos de 2 meses
Conclusão
FinOps não é um projeto único – é uma prática contínua de otimização. Comece pequeno: implemente tagging, identifique os recursos mais caros, faça rightsizing. Depois avance para Savings Plans, desligamento automático e Spot Instances. A cada mês, revise seus dashboards e busque novas oportunidades.
Na Jacobus Software, aplicamos FinOps em todos os projetos que entregamos. Nossos clientes economizam, em média, entre 30% e 50% em custos de cloud – sem sacrificar performance, disponibilidade ou capacidade de escala.
Se sua fatura de cloud cresce sem controle, FinOps é a resposta.
💰 Quer reduzir seus custos em cloud?
Nossos especialistas analisam sua conta AWS/Azure/GCP, identificam desperdícios e implementam estratégias FinOps com ROI garantido.