eng.
Conversar →
← Voltar para o blog
FinOps

FinOps na AWS: as 3 alavancas que cortam 30% do custo em 90 dias

REDGATOR ENGINEERING · ·6 min

Não é mágica. Todo mundo sabe o que fazer — só que ninguém faz na ordem certa, na prioridade certa, com a métrica certa. Veja como times reais cortam 25-35% em um trimestre.

FinOps na AWS: as 3 alavancas que cortam 30% do custo em 90 dias

Se você tem conta AWS acima de R$ 500 mil/mês e está lendo isto, é provável que:

  • Alguém falou “cloud ficou cara” na última reunião de finance
  • O dashboard de Cost Explorer mudou do verde para o amarelo
  • Um benchmark externo disse que você está gastando 30% a mais que pares

Temos uma notícia boa e uma ruim.

A ruim: não existe um serviço mágico a desligar. Se existisse, você já tinha desligado.

A boa: em praticamente todos os workloads que auditamos, há 25-35% de gordura em 3 alavancas previsíveis. E você pode executá-las em 90 dias sem quebrar nada.

Vamos ao que importa.

Alavanca 1 — Rightsizing (mês 1)

O problema

A maioria dos times dimensionou EC2, RDS e ECS/EKS com base em peak load teórico, não em uso real. O resultado:

  • EC2 m5.xlarge usando 15% de CPU média — deveria ser m5.large
  • RDS db.r6g.2xlarge com 8 GB de buffer pool em 32 GB de RAM — deveria ser db.r6g.large
  • EKS com requests declarados 3× o uso real — clusters superprovisionados

O que fazer

  1. Exportar CloudWatch metrics de 30 dias para todos EC2 e RDS
  2. Filtrar: CPU avg < 30%, Memory avg < 40%, Network avg < 20% da capacidade do tipo
  3. Listar candidatos a downsize (tipicamente 40-60% da frota)
  4. Aplicar em dev/staging primeiro, monitorar 7 dias, depois produção em waves

Ferramenta

  • Compute Optimizer (nativo AWS, gratuito) já faz 80% disso automaticamente. Ative e leia as recomendações.
  • Vantage, Spot.io, CloudZero agregam mais contexto em contas grandes (pagos).

Quanto economiza

Em workloads que não foram otimizados nos últimos 12 meses: 15-25% na conta total.

Risco

Baixo, se feito em waves e com rollback plan. Maior risco não é quebra técnica — é a reação de um time de aplicação que acha “estava funcionando, não mexe”.

Alavanca 2 — Commitments corretos (mês 2)

O problema

Reserved Instances, Savings Plans e Capacity Blocks dão 20-50% de desconto. Porém:

  • 70% dos clientes que auditamos têm commitment mal dimensionado (seja sub ou over)
  • Muitos usam standard RI quando deveriam usar Savings Plan (mais flexível)
  • Uns compraram 3 anos upfront em uma hora de euforia e agora não usam 40% dessa capacidade

O que fazer

  1. Calcular baseline estável: qual a menor carga de EC2 + RDS + Lambda + Fargate rodando 100% do tempo nos últimos 6 meses?
  2. Baseline × 85% = quantidade a comprometer (deixa 15% de folga para crescimento orgânico)
  3. Preferir Savings Plan Compute sobre RI para EC2 — dá flexibilidade de família, OS, região
  4. Separar commitments produção vs não-produção — nunca misture, staging/dev podem escalar mais
  5. Compromete 1 ano, não 3 — o ROI de 3 anos é 10-15% a mais que 1 ano, mas a incerteza técnica em 3 anos é alta

Ferramenta

  • AWS Cost Explorer — aba “Recommendations”
  • Savings Plans coverage report para ver se você está “coberto” ou “descoberto”

Quanto economiza

Em frotas com pouca ou nenhuma cobertura hoje: 10-20% na conta total.

Risco

Médio. Commitment é compromisso financeiro. Se você não tem certeza do baseline, não compre ainda. É melhor pagar on-demand por 2-3 meses a mais que carregar commitment errado por 12 meses.

Alavanca 3 — Desligar o que ninguém usa (mês 3)

O problema

Toda conta AWS tem lixo. Nada é mais previsível que isso.

  • Snapshots de EBS de 2022 que ninguém lembra
  • NAT gateways em VPCs mortas
  • RDS em dev que fica ligado no fim de semana
  • Load balancers sem target
  • Volumes gp2 que ainda não foram migrados para gp3 (40% mais baratos com mesmo desempenho)
  • Imagens ECR antigas que ocupam TBs
  • CloudWatch Logs com retention infinita

O que fazer

Semana 1 — limpar o óbvio (sem risco)

  • Snapshots não-associados a volumes ativos + mais de 180 dias → deletar
  • NAT gateways em VPCs sem instâncias → remover
  • gp2 → gp3 (scripted via AWS CLI, sem downtime)
  • Retention de CloudWatch Logs: default 30 dias

Semana 2 — desligar ambientes non-prod noturno/weekend

  • AWS Instance Scheduler (serviço AWS, gratuito) liga/desliga EC2 e RDS por tag
  • Economize 65% em dev/staging ligando 8-18h seg-sex

Semana 3 — rotação de imagens ECR

  • Lifecycle policy: manter últimas 10 tags, deletar resto
  • Médio: 40-60% do storage ECR some

Semana 4 — auditoria de load balancers, EIPs órfãos, Lambda que ninguém chama

Ferramenta

  • AWS Trusted Advisor (requer Business/Enterprise Support) tem checks “idle resources”
  • AWS Cost Anomaly Detection — avisa quando algo sobe abruptamente
  • Scripts próprios com AWS CLI para waste recorrente

Quanto economiza

Em contas sem governança: 5-15% na conta total. Em contas com governança madura: 2-5% (mas ainda vale).

Risco

Muito baixo. É quase todo lixo real.

A ordem importa

Se você inverter — comprar Savings Plan antes de fazer rightsizing — vai comprar commitment para capacidade que não precisa. Perde dinheiro ao invés de economizar.

A sequência correta é:

Mês 1: Rightsizing  →  reduz baseline
Mês 2: Commitments  →  compromete baseline reduzido
Mês 3: Desligar lixo → limpa o que ainda passou

O que não funciona

Vamos listar o que não funciona, baseado no que vimos falhar:

  • ❌ “Campanha interna de conscientização” — toda semana um email dizendo “pensem no custo”. Zero resultado mensurável.
  • ❌ “Migrar tudo para Lambda” — serverless não é mais barato por padrão. Em workloads com tráfego estável e previsível, EC2 + ECS é quase sempre mais barato.
  • ❌ “Multi-cloud para negociar com AWS” — raramente traz desconto adicional, e triplica complexidade operacional.
  • ❌ “Ir para uma cloud mais barata” — a diferença raw de preço entre AWS/Azure/GCP é < 10%. A diferença de custo total operacional pode inverter se seu time só domina uma.

O que realmente funciona é o boring e metódico: analisar, agir, medir, iterar.

Como começar

  1. Tire um dump do AWS Cost Explorer dos últimos 90 dias em CSV
  2. Calcule: spend por serviço, por conta, por tag (se tiver)
  3. Ative o Compute Optimizer e Trusted Advisor (se Business Support)
  4. Liste os 10 maiores gastos em detalhe
  5. Atribua um dono técnico para cada um
  6. Comece pela alavanca 1, service por service

Em 90 dias, se seguir a ordem, 25-35% de economia é alcançável com rigor.

Na Redgator: rodamos FinOps em 18 contas AWS, em médias/grandes empresas. Economia média nos primeiros 3 meses: 27%. Se quiser uma auditoria de custo gratuita (entregamos o relatório, você decide se contrata), fale com um especialista.

Publicado em 22/03/2026. Última revisão: 22/03/2026.

AWSFinOpscustootimizaçãocloud