Quem já abriu o AWS Cost Explorer numa segunda-feira e levou um susto sabe do que eu estou falando. A fatura veio 40% acima do esperado, ninguém sabe explicar o que aconteceu, e o CFO já mandou um e-mail com o assunto em caixa alta. Essa cena se repete em empresas de todos os tamanhos no Brasil.

O problema raramente é a AWS ser cara. O problema é que a flexibilidade do modelo pay-as-you-go cobra um preço: se ninguém cuida, o consumo escala sozinho. E a conta chega.

Saber como reduzir custos AWS não exige uma consultoria de seis meses nem uma reestruturação de arquitetura. Existem ajustes que você aplica hoje e que aparecem, literalmente, na fatura do mês seguinte. São sete. E nenhum deles exige derrubar o ambiente de produção.

1. AWS Budgets e alertas: comece por aqui, antes de qualquer outra coisa

Parece básico demais para estar em primeiro lugar? Pois é exatamente por parecer básico que quase ninguém configura direito.

O AWS Budgets permite criar alertas por conta, por serviço ou por tag. Você define um teto mensal (digamos, R$ 25.000) e configura notificações quando o consumo atingir 50%, 80% e 100% desse valor. Dá para disparar e-mail, notificação no Slack via SNS ou até acionar uma Lambda que desliga recursos automaticamente.

Na minha experiência, o simples fato de alguém receber o alerta já muda o comportamento. Antes do alerta, ninguém olhava. Depois, pelo menos uma pessoa para e pergunta: “por que estamos a 80% no dia 15?”

A configuração leva menos de dez minutos por conta. Se você tem uma estrutura multi-account com AWS Organizations, dá para consolidar tudo. Não tem desculpa para não fazer isso hoje.

Dica que pouca gente usa

Crie um budget separado só para transferência de dados (Data Transfer). Esse custo costuma ser invisível até ficar enorme. Mas isso eu explico melhor no final do artigo.

2. Right-sizing com AWS Compute Optimizer

Instâncias EC2 superdimensionadas são o desperdício mais comum em qualquer ambiente AWS. E o motivo é humano: quando alguém provisiona uma máquina, sempre escolhe um tamanho “pra garantir”. Ninguém quer ser o responsável por um sistema lento. Então sobe um m5.xlarge onde um m5.large daria conta. Multiplique isso por 50, 100 instâncias, e você tem um rombo considerável.

O AWS Compute Optimizer analisa o uso real de CPU, memória e rede das suas instâncias nos últimos 14 dias (ou mais, se você habilitar métricas estendidas) e recomenda o tipo e o tamanho correto. Não é achismo. São dados reais de utilização.

Um caso que vi recentemente: uma empresa de logística em São Paulo rodava 38 instâncias m5.2xlarge para uma aplicação de rastreamento. O Compute Optimizer mostrou que 31 delas tinham uso médio de CPU abaixo de 12%. A migração para m5.large (metade do tamanho) economizou quase 45% naquela linha da fatura. Sem nenhum impacto em performance.

O ponto de atenção é memória. O Compute Optimizer usa métricas do CloudWatch, que por padrão não coleta RAM. Instale o CloudWatch Agent nas instâncias para ter recomendações mais precisas. Sem isso, a ferramenta só enxerga CPU e rede, o que pode levar a sugestões agressivas demais para workloads memory-intensive.

3. Savings Plans e Reserved Instances para carga estável

Se você tem instâncias que rodam 24/7 (banco de dados, aplicação core, servidor de integração) e está pagando On-Demand, está jogando dinheiro fora. Simples assim.

Savings Plans oferecem descontos de até 72% em troca de um compromisso de uso por 1 ou 3 anos. Existem dois tipos que importam aqui:

• Compute Savings Plans: flexíveis. O desconto vale para qualquer família de instância, região e até para Fargate e Lambda. Você se compromete com um valor por hora de uso, não com um tipo específico de máquina
• EC2 Instance Savings Plans: menos flexíveis, mais baratos. Você trava família e região, mas ganha desconto maior

As Reserved Instances (RIs) ainda existem e fazem sentido para RDS e ElastiCache, onde os Savings Plans não se aplicam. Para EC2 puro, os Savings Plans são mais práticos porque não te prendem a uma instância específica.

Como calcular sem erro

O truque é olhar o baseline. Abra o AWS Cost Explorer, filtre por EC2, e veja o consumo dos últimos 3 meses. O menor valor consistente (aquele patamar que nunca cai abaixo) é o candidato seguro para Savings Plans. Tudo acima desse patamar você mantém On-Demand ou Spot.

Quem faz FinOps AWS na prática sabe que o erro mais comum é comprar Savings Plans demais no entusiasmo. Se o compromisso ficar acima do uso real, você paga por algo que não consome. Comece conservador, cubra 60-70% do baseline, e ajuste no próximo ciclo.

4. Spot Instances para carga tolerante a interrupção

Spot Instances custam até 90% menos que On-Demand. Noventa por cento. Esse desconto é real, mas vem com uma condição: a AWS pode reclamar a instância com dois minutos de aviso.

Para workloads que toleram interrupção, isso é ouro. Processamento em batch, renderização, pipelines de CI/CD, treinamento de modelos de machine learning, crawlers. Qualquer coisa que possa ser retomada de onde parou.

A prática recomendada é usar Spot Fleet ou EC2 Auto Scaling com diversificação de tipos de instância. Se você configura o fleet para aceitar m5.large, m5a.large, m4.large e c5.large, a chance de todas as opções serem interrompidas ao mesmo tempo cai drasticamente.

Uma coisa que me incomoda é quando vejo equipes descartando Spot por medo sem nunca terem testado. A realidade é que, para cargas de processamento que já têm retry automático, Spot funciona muito bem. O risco é gerenciável. A economia, não dá para ignorar.

Para aplicações web com Auto Scaling, uma estratégia mista também funciona: base com On-Demand (ou Savings Plans), picos com Spot. Se a Spot for interrompida, o Auto Scaling sobe outra. O usuário nem percebe.

5. Classes de armazenamento e lifecycle no S3

O S3 é um dos serviços mais usados e, ao mesmo tempo, um dos mais mal gerenciados em termos de custo. O problema não é o preço por GB (que é baixo). O problema é o volume. Empresas acumulam terabytes de logs, backups antigos, versões de arquivos que ninguém vai acessar de novo, e tudo fica na classe Standard.

A diferença de preço entre as classes é brutal:

Classe S3	Custo aproximado por GB/mês (São Paulo)	Melhor uso
Standard	US$ 0,0245	Acesso frequente
Infrequent Access (IA)	US$ 0,0138	Acesso esporádico (1-2x por mês)
Glacier Instant Retrieval	US$ 0,005	Arquivo com acesso raro mas imediato
Glacier Deep Archive	US$ 0,00099	Retenção regulatória, acesso quase nunca

A mágica está nas Lifecycle Policies. Você cria regras automáticas: após 30 dias sem acesso, move para IA. Após 90 dias, vai para Glacier. Após 365 dias, Deep Archive ou exclusão. Isso roda sozinho, sem intervenção manual.

Para quem tem buckets com versionamento habilitado (e deveria ter, para dados críticos), não esqueça de criar lifecycle para versões anteriores também. Já vi buckets onde as versões antigas ocupavam três vezes mais espaço que os arquivos atuais. Tudo pagando preço Standard.

Outro ponto: ative o S3 Intelligent-Tiering para buckets com padrão de acesso imprevisível. Ele move os objetos automaticamente entre tiers sem cobrança de retrieval. Tem uma taxa de monitoramento por objeto, mas para a maioria dos cenários compensa.

6. Limpeza de snapshots, volumes EBS órfãos e IPs públicos

Essa é a parte que ninguém gosta de fazer, mas que dá resultado imediato. É a faxina.

Três itens que costumam acumular custo sem que ninguém perceba:

Snapshots EBS antigos. Cada snapshot é incremental, mas o primeiro de cada volume é completo. Se você tem snapshots de 2022 de instâncias que já foram terminadas, está pagando por armazenamento de dados que provavelmente nunca vai restaurar. Um script simples com AWS CLI lista snapshots sem volume associado. Apague o que não precisa.

Volumes EBS órfãos. Quando você termina uma instância EC2, o volume root pode ser deletado automaticamente, mas volumes adicionais (data disks) muitas vezes ficam “disponíveis” sem estar attachados a nada. Cada um continua gerando custo. Um ambiente com 200 instâncias pode facilmente ter 30 ou 40 volumes órfãos. Já vi empresas pagando mais de R$ 3.000 por mês em volumes que ninguém usava.

Elastic IPs não associados. Um Elastic IP associado a uma instância rodando é gratuito. Um Elastic IP alocado mas não associado custa US$ 0,005 por hora. Parece pouco, mas 10 IPs parados custam quase US$ 40 por mês. E eles se acumulam silenciosamente.

Esse tipo de limpeza não exige planejamento estratégico. Exige disciplina. Agende uma revisão mensal, ou melhor: automatize com Lambda + EventBridge. O custo de manter esses recursos parados não aparece em nenhuma linha de destaque no Cost Explorer. Fica diluído. E é justamente por isso que ninguém olha.

Se a sua empresa opera em múltiplas nuvens, o raciocínio é o mesmo. Publicamos um guia sobre como reduzir custos no Azure que segue a mesma lógica de limpeza e otimização.

7. Tags por centro de custo e o AWS Cost Explorer como ferramenta de gestão

Aqui é onde a redução de custos deixa de ser um esforço técnico e vira governança. Sem tags, você sabe que gastou R$ 80.000 na AWS no mês. Com tags, você sabe que o time de marketing gastou R$ 12.000 em ambientes de homologação que ficaram ligados o fim de semana inteiro.

A diferença é enorme. Quando o custo tem dono, alguém responde por ele.

O mínimo que toda empresa deveria ter em tags:

• CostCenter (centro de custo ou departamento)
• Environment (produção, homologação, desenvolvimento)
• Project (projeto ou produto)
• Owner (responsável técnico)

Ative essas tags como “Cost Allocation Tags” no Billing Console. Sem essa ativação, o Cost Explorer não consegue filtrar por elas. É um passo que muita gente esquece.

Com as tags funcionando, o AWS Cost Explorer se transforma. Você consegue criar visualizações por time, por ambiente, por projeto. Consegue identificar que o ambiente de dev está custando 60% do que custa produção (o que normalmente não faz sentido). Consegue mostrar pro gestor de cada área quanto ele está gastando, o que por si só já gera economia porque as pessoas começam a desligar o que não precisam.

FinOps AWS na prática: não é só ferramenta, é processo

Quem trabalha com FinOps AWS sabe que o Cost Explorer e os Budgets são o começo, não o fim. A prática de FinOps envolve ciclos contínuos de visibilidade, otimização e operação. Mas sem a base de tags e alertas, nenhum ciclo funciona.

Uma coisa que funciona bem em empresas brasileiras de médio porte: criar uma reunião mensal de 30 minutos, só sobre custos de nuvem. Participam o responsável técnico, alguém de financeiro e o gestor da conta. Abre o Cost Explorer, olha os gráficos, discute os picos. Não precisa de framework sofisticado. Precisa de ritmo.

Para quem opera em mais de um provedor, vale entender como uma estratégia multi-cloud afeta a gestão de custos, porque a complexidade aumenta rápido quando as faturas vêm de dois lugares diferentes.

Quanto custa realmente economizar na AWS?

Os sete ajustes acima não exigem investimento significativo. Budgets e tags são gratuitos. Compute Optimizer tem um nível free. Lifecycle policies no S3 não têm custo de configuração. A limpeza de recursos órfãos, no máximo, demanda algumas horas de um analista com acesso ao CLI.

O retorno, por outro lado, costuma ser expressivo. Empresas que nunca fizeram uma revisão de custos estruturada costumam encontrar entre 20% e 35% de economia potencial. Não é um número inventado: é o que a prática mostra consistentemente em ambientes que cresceram sem governança de FinOps.

O desafio real não é técnico. É criar o hábito de olhar. De ter alguém que se importa com a fatura. De tratar cloud como custo operacional que precisa de gestão, não como cartão de crédito corporativo que ninguém confere.

O custo esquecido: transferência de dados (egress)

Eu deixei esse ponto para o final de propósito, porque ele merece atenção especial.

Transferência de dados para fora da AWS (egress) é um dos custos mais traiçoeiros do ambiente. Tráfego entre regiões, entre AZs, para a internet, para outros provedores de nuvem. Cada um desses caminhos tem um preço diferente, e nenhum é zero.

O preço de egress para internet na região de São Paulo começa em US$ 0,15 por GB para os primeiros 10 TB por mês. Parece pouco até você perceber que uma aplicação com CDN mal configurada ou uma integração que puxa dados de uma região para outra pode facilmente transferir centenas de GB por dia.

Algumas formas de mitigar:

• Use VPC Endpoints para acessar serviços AWS (S3, DynamoDB, SQS) sem sair pela internet. O tráfego fica dentro da rede AWS e o custo cai
• Mantenha os serviços que se comunicam na mesma AZ quando possível. Tráfego entre AZs custa US$ 0,01/GB em cada direção
• Para distribuição de conteúdo, o CloudFront frequentemente sai mais barato que servir direto do S3 ou do EC2, porque o preço de transferência pelo CloudFront é menor que o egress padrão
• Revise integrações com APIs externas. Se o seu sistema puxa relatórios pesados de uma API fora da AWS várias vezes ao dia, cache local pode economizar mais do que você imagina

A transferência de dados é aquela linha da fatura que cresce devagar, sem disparar alarme, até que um dia alguém percebe que ela representa 15% do gasto total. Configure um Budget específico para Data Transfer. Sério.

Por onde começar: um roteiro rápido

Se você leu até aqui e está pensando “ok, mas por onde começo”, a ordem importa. Faça assim:

1. Configure AWS Budgets com alertas para hoje. Dez minutos
2. Ative as Cost Allocation Tags e padronize pelo menos CostCenter e Environment. Essa semana
3. Rode o Compute Optimizer e identifique instâncias oversized. Analise nesta semana, aplique na próxima
4. Faça a limpeza de snapshots, volumes EBS órfãos e Elastic IPs. Uma tarde resolve
5. Crie Lifecycle Policies nos buckets S3 com mais de 100 GB. Priorize os maiores
6. Analise o baseline de uso para Savings Plans. Compre com calma, depois de duas semanas de observação
7. Avalie Spot Instances para workloads de batch e CI/CD. Teste em ambiente de homologação primeiro

Esse roteiro funciona para empresas que nunca fizeram FinOps e também para quem já tem alguma maturidade mas nunca sistematizou o processo.

Para empresas que querem ir além do que dá para fazer internamente, a Omega Brasil faz a gestão de AWS com revisão de custos incluída, identificando os cortes mais rápidos e ajudando a implementar as mudanças sem risco para o ambiente de produção.

E se o desafio não é só nuvem, mas a TI como um todo, vale olhar onde mais existem desperdícios em TI que passam despercebidos no orçamento.

A Omega Brasil faz a revisão de custos do seu ambiente AWS e aponta os cortes mais rápidos. Solicite uma análise.