Cloud cost: o que acontece quando você ignora a fatura da AWS por 3 meses
A AWS não cobra por usar — cobra por esquecer. Instâncias paradas, snapshots acumulados, transferência de dados que ninguém percebeu. Uma história de aprendizado caro.
Em algum momento de 2022, abri o dashboard de billing da AWS e a conta tinha triplicado em três meses. Não tínhamos crescido em usuários. Não tínhamos lançado nova infra significativa. O custo simplesmente foi subindo, item por item, sem ninguém percebendo.
Quando fui investigar, encontrei o seguinte:
Uma instância EC2 de tipo anterior (m4, já descontinuado) que rodava um ambiente de teste que ninguém usava há dois meses. Era o quarto do custo mensal que eu pensava que tínhamos.
Snapshots de EBS acumulados por seis meses de backups diários sem política de retenção. Snapshots são baratos individualmente — mas seis meses de backups diários de um volume de 500GB somam fast.
Transferência de dados entre availability zones. A AWS cobra por dados que cruzam de uma AZ para outra dentro da mesma região. Nosso serviço estava fazendo queries de uma AZ para um banco de dados em outra AZ, em loop, a cada segundo. O custo de transfer era invisível no dashboard porque se misturava com outros itens de rede.
NAT Gateway. Esse foi o mais surpreendente. Tínhamos instâncias privadas que faziam requests para a internet — para download de dependencies, para chamadas de API externas. Cada gigabyte que passa pelo NAT Gateway tem um custo. Não é alto. Mas quando você tem múltiplos serviços fazendo isso continuamente, acumula.
O problema fundamental: cloud tem um modelo de cobrança complexo com dezenas de dimensões de custo. Armazenamento. Compute. Transferência de dados. Requests. Operações de IO. Endereços IP elásticos alocados mas não utilizados. Cada um tem sua lógica de preço, e a combinação é difícil de estimar intuitivamente.
Data centers físicos têm custo fixo alto mas previsível. Cloud tem custo variável que pode ser muito baixo ou muito alto dependendo do que você faz. Essa variabilidade é uma feature — você não paga por capacity ociosa. Mas é também um risco se você não monitorar ativamente.
O que mudei depois desse episódio:
Budget alerts no AWS. Você define um threshold — por exemplo, "me avisa se o custo projetado para o mês exceder 20% do orçamento" — e recebe um email automaticamente. Custa nada, previne surpresas.
Cost Explorer semanal. Uma vez por semana, olho o breakdown por serviço e por tag. Se algo aumentou significativamente sem uma razão óbvia, investigo. O padrão se estabelece rápido e anomalias ficam visíveis.
Tags em tudo. Taggear recursos com environment: production / staging / test e team: backend / platform / frontend permite filtrar custos por categoria. Sem tags, você tem um número total e não sabe o que está contribuindo.
Política de limpeza para ambientes de teste. Automação que desliga ou termina recursos de staging/test automaticamente após 24h sem uso. Humanos esquecem — automação não esquece.
A mentalidade que falta na maioria dos devs: cloud cost é responsabilidade de engenharia, não só de infra ou de finance.
Quando você abre um PR adicionando uma nova feature que faz chamadas para uma API externa, você está mudando o custo de operação. Quando você escolhe armazenar arquivos no S3 em vez de num banco de dados, você está fazendo uma decisão econômica. Quando você deixa um container rodando ocioso porque "pode ser útil depois", você está gastando dinheiro da empresa.
FinOps não é uma função separada — é consciência de custo integrada às decisões de engenharia.
Um conselho prático: habilita o Cost and Usage Report (CUR) da AWS e aponta para um bucket S3. Com Athena, você consegue fazer queries granulares sobre seus custos — por serviço, por recurso específico, por hora. É um nível de visibilidade que o Cost Explorer não dá por padrão.
Essa semana: abre o billing dashboard do seu cloud provider e olha o breakdown por serviço dos últimos 3 meses. Tem algo que cresceu sem razão clara? Tem um serviço que você não reconhece? Investiga isso antes de fechar a aba.