Gastei 8 reais para cortar 500 dólares por mês da conta da AWS

Uma consultoria em parceria com a própria AWS analisou a conta da empresa e apontou os alvos óbvios: computação e banco de dados. O S3 foi descartado como oportunidade de economia.

O S3 acabou sendo a maior economia que eu encontrei. E me custou 46 centavos para provar.

No fim, três achados derrubaram quase 20% da fatura mensal. Nenhum deles envolveu mudar arquitetura, reescrever serviço ou renegociar contrato.

Por que eu fui olhar

Trabalhei um tempo em empresas de cloud privada, onde a infraestrutura era compartilhada entre os serviços internos. Ali esses valores não eram preocupação de ninguém, passavam batido.

Quando o custo vira boleto, a pergunta muda. Será que esse valor tá bem dimensionado? Não tem como reduzir? Precisamos disso tudo?

"Cloud pública é cara mesmo", "o dólar está em alta", "não compensa migrar". São frases que a gente ouve todo dia trabalhando com AWS, Azure ou Oracle. Todas plausíveis, e nenhuma delas verificável sem abrir a fatura.

O caminho óbvio já estava tomado

O primeiro lugar em que qualquer pessoa olha é o Cost Explorer, onde os gastos do mês aparecem separados por categoria. E em estratégia de economia os alvos são sempre os mesmos: computação e banco de dados, evitando o hiperdimensionamento dos serviços.

Esse terreno já estava coberto. O time em que eu trabalho é muito competente e, além disso, tivemos acesso a uma consultoria gratuita em parceria com a AWS que atacou exatamente esses dois pontos.

Sobrou pra mim o que ninguém tinha olhado. Separei em duas frentes: alto impacto e itens incomuns.

20 minutos clicando no billing

Não usei ferramenta de análise, script, nem export de fatura.

Abri o Billing, selecionei o mês anterior e fui expandindo cada item, um por um. O critério era simples: se o valor era significativo e eu não sabia exatamente o que aquilo era, ia atrás.

Levou 20 minutos.

Dois dos três achados morreram em poucas pesquisas. O terceiro virou projeto.

Alto impacto: S3

Um repositório de 14 TB acumulados em mais de 7 anos, com 4,6 milhões de objetos, tudo em Standard.

Eu tinha certeza de que dava pra economizar bastante usando classes diferentes. A objeção do time era legítima: e se der errado e o custo aumentar?

Foi fácil resolver isso com dado. O S3 Storage Class Analysis custa 0,10 dólar por milhão de objetos monitorados por mês, então para os meus 18 milhões a fatura da análise foi de 1,83 dólares.

Deixei rodando um mês e, no fim, eu não tinha mais palpite, tinha o padrão real de acesso de cada prefixo.

Com isso na mão, três perguntas ficaram respondíveis.

Disponibilidade: mudar de classe não altera durabilidade nem disponibilidade apenas o custo de recuperação, e a análise mostrou que, para o nosso padrão de acesso, isso era irrelevante.

Preço: quanto cada prefixo passaria a custar em cada classe.

Retorno: transição de classe é cobrada por objeto, e com 4,6 milhões de objetos isso não é detalhe. Eu precisava saber em quanto tempo se pagava.

A abordagem foi agressiva (padrão 0 - 30 SI - 90 Glacier). A economia ficou em torno de 500 dólares por mês, e o custo da transição se pagou dentro do próprio mês em que foi feita.

Praticamente 8 reais de investigação para seis mil dólares por ano.

Itens incomuns

Essa parte é igual a procurar gasto na fatura do cartão. Você não está caçando o valor mais alto, está caçando a linha que não deveria estar ali. E ao olhar linha por linha eu achei duas.

O ECR, que guarda as imagens Docker, tinha 1,3 TB de imagens custando 134,54 dólares por mês. A causa? Nenhuma regra de lifecycle, em nenhum repositório, por anos. Cada deploy gerava uma imagem nova e nenhuma antiga era apagada. São 4 serviços principais, mas dezenas de funções Lambda, e cada uma com seu próprio repositório. Muitos repositórios, nenhum com regra, ninguém olhando. Correção? Apenas criar uma regra apagando as imagens que já não têm utilidade. A linha caiu de 134,54 para 2,51 dólares, uma redução de 98%.

O Extended Support, embutido na cobrança do RDS, na faixa de 100 dólares por mês. Ele existe por um único motivo: a versão do banco saiu do suporte padrão da AWS. Não é cobrança por uso, por volume ou por configuração, é cobrança por estar desatualizado. E entra sozinha, sem ninguém pedir. Correção? Atualizar o banco.

O que eu deixei passar

Comecei pelo achado mais difícil. O S3 exigiu um mês de análise e uma discussão com o time, enquanto o ECR e o Extended Support renderam 230 dólares por mês e me custaram meia hora somada. Se eu tivesse varrido a fatura inteira antes de abrir qualquer frente, teria capturado o dinheiro fácil primeiro e chegado na conversa sobre o S3 já com resultado no bolso.

Também deixei coisa na mesa de propósito. Savings Plans, RDS Reserved Instances e reserva de capacidade são economias reais, mas exigem compromisso de 1 a 3 anos. Não é decisão de quem está lendo fatura numa tarde de terça, é decisão de planejamento, e precisa de outra conversa.

Ferramenta automática e consultoria olham o que é comum a todo mundo. O desperdício mora no que é específico da sua conta.

Nenhum dos três achados estava escondido. Estavam na primeira tela do Billing, em texto, esperando alguém expandir o item e perguntar o que aquilo significava. Duas das três correções foram configuração de meia hora.

Não era problema de arquitetura. Era problema de ninguém ter olhado.

E se você precisa de um argumento pra começar a olhar: a investigação que rendeu 500 dólares por mês custou apenas 8 reais.

Você tem alguma dessas histórias com cloud pública? Me conta qual foi o seu achado mais bobo com a maior economia.