eng.
Conversar →
← Voltar para o blog ← Back to the 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

AWS FinOps: the 3 levers that cut 30% of cost in 90 days

REDGATOR ENGINEERING · ·6 min

No magic. Everyone knows what to do — they just don't do it in the right order, with the right priority, against the right metric. Here's how real teams cut 25-35% in a quarter.

AWS FinOps: the 3 levers that cut 30% of cost in 90 days

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.

If your AWS bill is above $100k/month and you’re reading this, chances are:

  • Somebody said “cloud got expensive” in the last finance review
  • Cost Explorer dashboard turned from green to yellow
  • An external benchmark told you you’re spending 30% more than peers

Good news and bad news.

Bad news: there’s no magic service to turn off. If there were, you’d have done it already.

Good news: in virtually every workload we’ve audited, there’s 25-35% of fat in 3 predictable levers. And you can execute them in 90 days without breaking anything.

Let’s get to it.

Lever 1 — Rightsizing (month 1)

The problem

Most teams sized EC2, RDS, and ECS/EKS based on theoretical peak load, not actual usage. The result:

  • EC2 m5.xlarge running at 15% average CPU — should be m5.large
  • RDS db.r6g.2xlarge with an 8 GB buffer pool out of 32 GB RAM — should be db.r6g.large
  • EKS with declared requests 3× actual usage — over-provisioned clusters

What to do

  1. Export 30 days of CloudWatch metrics for all EC2 and RDS
  2. Filter: CPU avg < 30%, Memory avg < 40%, Network avg < 20% of type capacity
  3. List candidates for downsize (typically 40-60% of the fleet)
  4. Apply to dev/staging first, monitor for 7 days, then production in waves

Tooling

  • Compute Optimizer (native AWS, free) already does 80% of this automatically. Turn it on and read the recommendations.
  • Vantage, Spot.io, CloudZero add more context on large accounts (paid).

How much it saves

For workloads not optimized in the last 12 months: 15-25% of the total bill.

Risk

Low, if done in waves with a rollback plan. The bigger risk isn’t technical breakage — it’s the application team reaction of “it was working, don’t touch it.”

Lever 2 — Correct commitments (month 2)

The problem

Reserved Instances, Savings Plans, and Capacity Blocks give 20-50% discount. However:

  • 70% of customers we audit have misdimensioned commitments (either under or over)
  • Many use standard RI when they should use Savings Plan (more flexible)
  • Some bought 3 years upfront in a moment of euphoria and now don’t use 40% of that capacity

What to do

  1. Calculate stable baseline: what’s the smallest EC2 + RDS + Lambda + Fargate load running 100% of the time over the last 6 months?
  2. Baseline × 85% = amount to commit (leaves 15% slack for organic growth)
  3. Prefer Savings Plan Compute over RI for EC2 — gives family, OS, region flexibility
  4. Separate production vs non-production commitments — never mix them, staging/dev can scale more
  5. Commit for 1 year, not 3 — the 3-year ROI is 10-15% more than 1-year, but technical uncertainty at 3 years is high

Tooling

  • AWS Cost Explorer — “Recommendations” tab
  • Savings Plans coverage report to see if you’re “covered” or “uncovered”

How much it saves

For fleets with little or no coverage today: 10-20% of the total bill.

Risk

Medium. Commitment is a financial obligation. If you’re unsure of your baseline, don’t buy yet. Better to pay on-demand for 2-3 more months than to carry the wrong commitment for 12 months.

Lever 3 — Turn off what nobody uses (month 3)

The problem

Every AWS account has trash. Nothing is more predictable than this.

  • EBS snapshots from 2022 nobody remembers
  • NAT gateways in dead VPCs
  • RDS in dev left on over the weekend
  • Load balancers without targets
  • gp2 volumes not yet migrated to gp3 (40% cheaper with same performance)
  • Old ECR images consuming TBs
  • CloudWatch Logs with infinite retention

What to do

Week 1 — clean the obvious (no risk)

  • Snapshots not associated with active volumes + older than 180 days → delete
  • NAT gateways in VPCs with no instances → remove
  • gp2 → gp3 (scripted via AWS CLI, zero downtime)
  • CloudWatch Logs retention: default 30 days

Week 2 — shut down non-prod environments overnight/weekend

  • AWS Instance Scheduler (AWS service, free) starts/stops EC2 and RDS by tag
  • Save 65% in dev/staging by running 8am-6pm Mon-Fri

Week 3 — ECR image rotation

  • Lifecycle policy: keep the last 10 tags, delete the rest
  • Average: 40-60% of ECR storage disappears

Week 4 — audit of load balancers, orphan EIPs, Lambdas nobody calls

Tooling

  • AWS Trusted Advisor (requires Business/Enterprise Support) has “idle resources” checks
  • AWS Cost Anomaly Detection — alerts when something spikes
  • Custom scripts with AWS CLI for recurring waste

How much it saves

For accounts with no governance: 5-15% of the total bill. For accounts with mature governance: 2-5% (still worth it).

Risk

Very low. It’s almost all real trash.

Order matters

If you invert it — buying a Savings Plan before rightsizing — you’ll commit to capacity you don’t need. You lose money instead of saving.

The correct sequence is:

Month 1: Rightsizing  →  reduces baseline
Month 2: Commitments  →  commits to reduced baseline
Month 3: Turn off trash → cleans what still slipped through

What doesn’t work

Let’s list what doesn’t work, based on what we’ve seen fail:

  • ❌ “Internal awareness campaign” — a weekly email saying “think about cost”. Zero measurable result.
  • ❌ “Migrate everything to Lambda” — serverless isn’t cheaper by default. For workloads with stable, predictable traffic, EC2 + ECS is almost always cheaper.
  • ❌ “Multi-cloud to negotiate with AWS” — rarely brings additional discount, and triples operational complexity.
  • ❌ “Move to a cheaper cloud” — raw price difference between AWS/Azure/GCP is < 10%. The difference in total operational cost can flip if your team only knows one.

What really works is the boring and methodical: analyze, act, measure, iterate.

How to start

  1. Pull an AWS Cost Explorer dump of the last 90 days as CSV
  2. Calculate: spend per service, per account, per tag (if you have any)
  3. Turn on Compute Optimizer and Trusted Advisor (if Business Support)
  4. List the 10 biggest expenses in detail
  5. Assign a technical owner to each
  6. Start with lever 1, service by service

In 90 days, if you follow the order, 25-35% savings are achievable with discipline.

At Redgator: we run FinOps in 18 AWS accounts at mid/large companies. Average savings in the first 3 months: 27%. If you want a free cost audit (we deliver the report, you decide whether to engage), talk to a specialist.

Published 03/22/2026. Last revision: 03/22/2026.

AWSFinOpscustootimizaçãocloud