FinOps na prática: os 5 desperdícios de custo mais comuns em contas AWS de médio porte

Se a sua empresa gasta entre US$ 1.000 e US$ 10.000 por mês com AWS e nunca fez uma revisão estruturada de custos, é quase certo que você está deixando dinheiro na mesa. Não estamos falando de centavos: em contas de médio porte, desperdícios recorrentes facilmente ultrapassam 20% a 35% do faturamento mensal — valores que, acumulados ao longo de um ano, representam o orçamento de um projeto inteiro.

A disciplina de FinOps (Financial Operations) existe justamente para trazer visibilidade, responsabilidade e otimização contínua ao consumo de cloud. Mas antes de implementar frameworks sofisticados, o primeiro passo é pragmático: identificar e eliminar os desperdícios mais óbvios.

Neste artigo, mapeamos os 5 padrões de desperdício mais frequentes que encontramos em auditorias de contas AWS de empresas mid-market — e mostramos como corrigi-los.

1. Instâncias EC2 ociosas ou superdimensionadas

O problema

Este é, de longe, o desperdício mais comum. Instâncias EC2 que rodam 24/7 com utilização média de CPU abaixo de 10% ou memória alocada muito acima do consumo real. Cenários típicos incluem:

• Ambientes de desenvolvimento e homologação ligados fora do horário comercial e nos finais de semana
• Instâncias de produção superdimensionadas por "segurança" durante o provisionamento inicial, mas nunca redimensionadas
• Instâncias órfãs de projetos encerrados que ninguém desligou

O impacto

Uma instância m5.xlarge (4 vCPUs, 16 GB RAM) custa aproximadamente US$ 140/mês em On-Demand na região us-east-1. Se sua conta tem 20 instâncias nesse perfil rodando ociosas, são US$ 2.800/mês desperdiçados — US$ 33.600/ano.

Como resolver

• AWS Compute Optimizer: analise as recomendações de rightsizing. O serviço compara métricas de utilização com os tipos de instância disponíveis e sugere downsizing
• Políticas de start/stop automatizado: use AWS Instance Scheduler ou scripts Lambda com EventBridge para desligar ambientes não-produtivos fora do expediente. Economia típica: 65% do custo desses ambientes
• Savings Plans e Reserved Instances: para workloads estáveis de produção, compromissos de 1 ou 3 anos reduzem custos em 30% a 60% versus On-Demand
• Revisão trimestral obrigatória: institua um processo de revisão de rightsizing a cada 90 dias

2. Volumes EBS não utilizados e snapshots acumulados

O problema

Quando uma instância EC2 é terminada, seus volumes EBS não são automaticamente excluídos (a menos que a flag DeleteOnTermination esteja habilitada). O resultado: dezenas de volumes available (desanexados) acumulando custo silenciosamente.

Somam-se a isso os snapshots de EBS — backups incrementais que muitas empresas configuram com políticas de retenção generosas (ou sem política alguma). É comum encontrar contas com centenas de snapshots de volumes que já não existem.

O impacto

• Volume EBS gp3 de 500 GB não utilizado: ~US$ 40/mês
• 200 snapshots de 100 GB cada (armazenamento incremental médio de 30 GB): ~US$ 300/mês em armazenamento S3
• Em contas com histórico de 2+ anos sem limpeza, esse custo facilmente ultrapassa US$ 1.000/mês

Como resolver

• Auditoria imediata: liste todos os volumes com status available via AWS CLI: aws ec2 describe-volumes --filters Name=status,Values=available
• AWS Data Lifecycle Manager (DLM): configure políticas de retenção automática para snapshots (ex.: manter apenas os últimos 30 dias)
• Tag de expiração: implemente tags como DeleteAfter com datas, e use Lambda para limpeza automatizada
• Habilite DeleteOnTermination como padrão nos launch templates

3. Transferência de dados entre regiões e AZs sem planejamento

O problema

A AWS cobra por transferência de dados em diversos cenários que passam despercebidos:

• Entre Availability Zones (AZs): US$ 0,01/GB em cada direção (US$ 0,02/GB ida e volta)
• Entre regiões: US$ 0,02/GB ou mais, dependendo das regiões
• Para a internet (egress): a partir de US$ 0,09/GB após o free tier

Arquiteturas que distribuem microsserviços entre múltiplas AZs sem considerar a afinidade de comunicação, ou que replicam dados entre regiões sem necessidade real, geram custos significativos.

O impacto

Uma aplicação que transfere 10 TB/mês entre AZs gera um custo de ~US$ 200/mês apenas em data transfer — um custo que não aparece associado a nenhum serviço específico e frequentemente é ignorado.

Para transferências de egress de 50 TB/mês, o custo pode ultrapassar US$ 4.000/mês.

Como resolver

• VPC Endpoints (Gateway e Interface): elimine o tráfego via internet para serviços AWS como S3 e DynamoDB. O Gateway Endpoint para S3 é gratuito
• CloudFront como CDN: para conteúdo estático e APIs, o custo de transferência via CloudFront é significativamente menor que egress direto do EC2/ALB
• Afinidade de AZ: posicione serviços que se comunicam intensamente na mesma AZ quando possível, usando topology-aware routing
• AWS Cost Explorer com filtro de Data Transfer: monitore mensalmente os custos de transferência por tipo e tome ações corretivas

4. Recursos de banco de dados superdimensionados e sem otimização

O problema

Bancos de dados gerenciados (RDS, Aurora, ElastiCache, Redshift) são frequentemente os maiores itens de custo em contas AWS mid-market — e também os mais superdimensionados. Padrões comuns:

• Instâncias RDS Multi-AZ em ambientes de desenvolvimento (o Multi-AZ dobra o custo)
• Clusters Aurora provisionados para workloads que seriam melhor atendidos pelo Aurora Serverless v2
• Instâncias ElastiCache dimensionadas para picos que ocorrem 2 horas por dia
• Retenção de backups automatizados configurada para 35 dias quando 7 seriam suficientes
• Storage de RDS alocado em excesso (o RDS não reduz storage automaticamente)

O impacto

Um cluster Aurora db.r5.2xlarge Multi-AZ custa aproximadamente US$ 1.400/mês. Se a utilização média é de 15%, migrar para Aurora Serverless v2 pode reduzir esse custo para US$ 200–400/mês — uma economia de 70% ou mais.

Como resolver

• Performance Insights e CloudWatch: analise métricas de CPU, memória, IOPS e conexões ativas para identificar superdimensionamento
• Aurora Serverless v2: ideal para workloads com padrões variáveis de uso. Escala automaticamente entre um mínimo e máximo de ACUs
• Desabilite Multi-AZ em não-produção: economia imediata de 50% no custo da instância
• Reserved Instances para RDS: para bancos de produção estáveis, RIs de 1 ano com pagamento parcial upfront economizam ~35%
• Revise a retenção de backups: ajuste para o mínimo necessário conforme sua política de RPO

5. Ausência de governança de tags e falta de visibilidade de custos

O problema

Este não é um desperdício direto, mas é o multiplicador de todos os outros. Sem uma estratégia de tagging consistente, é impossível:

• Saber quem está gastando quanto e por quê
• Identificar recursos órfãos ou de projetos encerrados
• Implementar chargebacks ou showbacks por equipe/projeto
• Criar alertas de budget granulares

Em nossa experiência, mais de 60% das contas AWS mid-market têm menos de 50% dos recursos tagueados corretamente.

O impacto

A falta de visibilidade não gera custo por si só, mas impede a detecção e correção de todos os outros desperdícios. Empresas sem governança de tags levam, em média, 3x mais tempo para identificar anomalias de custo.

Como resolver

• Defina uma política de tags obrigatórias: no mínimo Environment, Project, Owner, CostCenter
• AWS Tag Policies (Organizations): force a conformidade de tags em toda a organização
• Service Control Policies (SCPs): bloqueie a criação de recursos sem tags obrigatórias
• AWS Cost Allocation Tags: ative tags de alocação de custo no Billing Console para que apareçam no Cost Explorer
• Dashboards de custo por tag: crie dashboards no QuickSight ou Cost Explorer com breakdown por projeto, equipe e ambiente
• Revisão mensal de compliance de tags: use AWS Config Rules para monitorar e reportar recursos não conformes

Resumo: os 5 desperdícios e seu impacto estimado

Os principais desperdícios de custos na AWS e como priorizá-los:

• 01 — Instâncias EC2 Superdimensionadas: Compute com capacidade acima do necessário para a carga real. Economia potencial: 20–40% do custo EC2. Complexidade: Baixa 🟢
• 02 — RDS Subutilizado ou Mal Configurado: Instâncias de banco de dados com recursos ociosos ou configuração inadequada. Economia potencial: 25–50% do custo RDS. Complexidade: Média 🟡
• 03 — Snapshots e Dados Obsoletos no S3: Armazenamento retido sem política de ciclo de vida ou limpeza. Economia potencial: 10–30% do custo Storage. Complexidade: Baixa 🟢
• 04 — NAT Gateway com Tráfego Excessivo: Custos elevados de transferência via NAT sem otimização de rotas. Economia potencial: 30–60% do custo NAT. Complexidade: Média-Alta 🔴
• 05 — Ambientes de Desenvolvimento Sempre Ligados: Ambientes dev/staging rodando 24/7 sem necessidade. Economia potencial: 40–70% do custo Dev. Complexidade: Baixa-Média 🟡

Priorize pelo ROI: baixa complexidade + alta economia.

Conclusão: o primeiro passo é visibilidade

FinOps não é um projeto com data de término — é uma disciplina contínua. Mas todo programa de otimização de custos AWS começa pelo mesmo lugar: visibilidade sobre o que está sendo gasto e por quê.

Os 5 desperdícios que detalhamos neste artigo são os mais recorrentes em contas de médio porte, e a boa notícia é que a maioria pode ser corrigida em semanas, não meses. O retorno sobre o investimento de tempo é imediato.

Próximos passos

• Faça uma auditoria inicial usando AWS Cost Explorer, Compute Optimizer e Trusted Advisor
• Priorize as correções pelo impacto financeiro estimado (comece pelo EC2 e bancos de dados)
• Implemente governança de tags para garantir visibilidade contínua
• Estabeleça revisões mensais de custo com responsáveis definidos

Se você quer acelerar esse processo e ter um diagnóstico profissional da sua conta AWS, a Ascendra pode ajudar. Somos parceiros AWS especializados em otimização de custos e implementação de práticas FinOps para empresas mid-market.

Precisa de ajuda para implementar FinOps na sua empresa? Fale com nossos especialistas e receba um diagnóstico gratuito da sua conta AWS.