Como cortei mais de 80% do custo de uma SaaS na AWS sem parar o produto

Quando cheguei, a conversa sobre custo já tinha um tom meio resignado. A fatura da AWS vinha subindo havia meses, cada tentativa anterior de “apertar o cinto” tinha durado pouco, e a sensação dentro do time era de que a operação tinha vida própria. O produto funcionava, os clientes estavam ativos, mas o custo andava num ritmo que nenhuma reunião conseguia frear.

Não era um caso de “desligar máquina parada”. Era uma plataforma construída para entregar valor rápido, que nunca tinha sido revisada com a pergunta “isso está bem colocado para o jeito como roda hoje?”. Dá para fazer software rodar bem por um tempo sem olhar para FinOps, mas uma hora a conta chega.

Uma nota antes de qualquer coisa

Este case envolve AWS e Cloudflare, e uma parte da solução foi mover responsabilidades de uma para a outra. Isso não é uma crítica à AWS. A AWS é uma plataforma sólida e continuou sendo usada em vários pontos centrais da operação. O que estava errado era a arquitetura, que não tinha sido desenhada para aproveitar a AWS de forma eficiente. O problema estava menos na ferramenta e mais na forma como ela vinha sendo usada.

O ponto de partida

A curva dos meses anteriores deixava claro que, sem intervenção, o custo ia continuar subindo. Mas o incômodo inicial nem era o valor em si. Era outro: ninguém sabia dizer, com alguma precisão, quanto custava cada cliente. Existia um rateio estimado, feito com base no “tamanho do tenant”, que servia para relatórios internos, mas não resistia a uma pergunta séria. Sem custo real por tenant, qualquer discussão de preço, margem ou churn virava achismo.

Havia um agravante: menos de 10% da operação estava documentada. Não tinha desenho de arquitetura confiável, não tinha mapa de dependências, não tinha histórico de por que cada serviço foi escolhido. Muito do processo inicial não foi “otimizar”, foi investigar: abrir o código, seguir rota por rota e puxar fio de configuração até entender o que estava rodando ali. Foi um trabalho quase arqueológico, com a documentação sendo escrita junto, conforme as decisões iam se firmando.

O que foi mudado e por quê

A pergunta útil deixou de ser “quanto recurso falta?” e passou a ser “onde esse fluxo está perdendo controle?”. Esse reframing destravou tudo. O trabalho andou em três frentes ao mesmo tempo.

Medição

Antes de cortar qualquer coisa, construí uma calculadora interna para entender o peso real de cada linha da fatura, não pelo nome do serviço, mas pelo que ele representava na operação. Ali ficou claro que data transfer era a linha dominante, seguida por CDN, WAF e SSL multi-tenant no agregado. CPU não era o vilão principal. A borda era. Em vez de discutir custo por impressão, o time passou a discutir custo por evidência.

Código e arquitetura

Havia desperdício dentro do próprio código. Em alguns fluxos de React e Next.js, componentes buscavam o mesmo endpoint várias vezes. Mesmo com cache do Next.js, isso gerava custo de CPU e processamento no servidor. Em produção com muitos tenants, isso vira consumo recorrente pago sem entregar valor novo. Esses fluxos foram corrigidos.

Havia também responsabilidades mal posicionadas. Regras de segurança como rate limit estavam numa camada que fazia cada request carregar custo de memória e processamento desnecessário. A proteção fazia sentido; o problema era onde rodava. Mover esse peso para uma camada mais adequada melhorou a relação entre proteção e custo.

E havia modelo de compute mal encaixado. A plataforma usava ECS com auto-scaling, o que sempre embutia margem ociosa paga. Onde esse modelo não se justificava mais, a migração para Lambda trocou custo por capacidade reservada por custo por execução, removendo a folga paga que vinha sendo tratada como inevitável.

Nada disso envolveu uma reescrita. Envolveu paciência para diagnóstico fino, num código que em vários trechos era o único documento existente sobre como o sistema funcionava.

Escolha certa de ferramenta

AWS continuou onde fazia sentido. Mas CDN, WAF, SSL multi-tenant e data transfer, no agregado, saíam muito mais caros do que na Cloudflare. SSL for SaaS e Workers cobriram a borda com um custo-benefício que a arquitetura anterior não alcançava.

Cloudflare tem CPU mais caro em alguns cenários, mas o ganho em borda e transferência compensou com folga. O critério nunca foi ideológico. Foi entender onde cada carga rodava melhor, com o menor custo aceitável de complexidade. Tratar AWS e Cloudflare como concorrentes é perder dinheiro. Tratar as duas como ferramentas com forças diferentes foi o que permitiu uma queda dessa ordem.

O que foi acontecendo na fatura

A queda veio em ondas. Os primeiros meses trouxeram cortes na casa de um dígito, vindos de ajustes de código e dimensionamento. Com a primeira leva de refactorings, a queda passou dos 20% e alcançou a casa dos 30%.

A onda mais forte veio quando a migração de borda começou a valer para tráfego real. O custo caiu para menos da metade sobre o ponto de partida. Houve meses em que o valor voltou a subir um pouco, o que é normal quando se migra carga mantendo parte do tráfego no modelo antigo. Não tratei isso como recuo, e sim como custo natural de uma transição feita com o produto rodando.

No último mês cheio antes desta publicação, a redução acumulada estava na casa dos 70%. Com o desenho final em regime, a projeção aponta para algo próximo de 85%.

Tudo isso com o produto andando

Nada disso parou o desenvolvimento. O roadmap continuou correndo. O time publicou novas funcionalidades, incluindo capacidades com IA generativa, que trazem seu próprio conjunto de desafios de custo, latência e arquitetura. Não era só cortar. Era reduzir desperdício enquanto se construía algo que, por natureza, já nasce caro.

Isso exigiu escolher bem as batalhas. Nem toda otimização valia a pena naquele mês, porque competia com feature que não podia atrasar. Nem toda feature nova foi aceita do jeito como chegou, porque algumas traziam decisões de custo que só fariam sentido depois da próxima onda de refactoring.

O lado que não aparece na tabela

É tentador reduzir esse case a “cortei custo da AWS”. Mas os resultados mais úteis nem estão no gráfico de economia.

Passamos a saber quanto cada tenant custa para a empresa. Isso muda conversa de precificação, decisão sobre clientes que consomem muito e pagam pouco, e forma como o comercial negocia planos. Sai do campo “eu acho” e entra no campo “eu mostro”.

Os web vitals ficaram mais consistentes entre regiões, o que importa para um produto que existe para entregar conteúdo web. Incidentes ficaram mais raros e mais fáceis de isolar, inclusive porque agora existia documentação onde antes existia memória oral.

E o time respirou. Quando o custo parou de ser sombra sobre toda decisão técnica, deu para voltar a discutir produto e evolução sem que cada ideia esbarrasse em “mas quanto isso vai nos cobrar?”. Reter gente boa ficou mais fácil, e isso por si só já é economia, do tipo que não aparece na fatura.

O que eu tiro desse processo

Custo alto costuma ser o resultado de decisões antigas que continuam rodando sem revisão. Algumas estão na infraestrutura. Outras estão no código. Outras estão em responsabilidades que foram parar na camada errada e ficaram lá tempo demais. Quando esse tipo de revisão é feito com medição, sai a tentativa de economizar no escuro e entra engenharia aplicada em cima do que realmente pesa.

Não existe “a melhor cloud”. Existe a cloud certa para cada pedaço do problema. Foi isso que fez a diferença aqui, sem prejudicar as pessoas que estavam construindo o produto.