O custo de cloud em dólar é uma das maiores pressões silenciosas sobre a margem de empresas de tecnologia e donos de SaaS no Brasil. A fatura cresce mês a mês, o câmbio piora o cenário e pouca gente sabe explicar exatamente para onde o dinheiro está indo. Neste artigo mostro o que eu mudaria hoje, na ordem, para reduzir essa conta, com potencial de chegar a até 70% em cenários de muito desperdício, sem sacrificar performance.
Um aviso de honestidade: esse número é um teto possível, não uma promessa. O resultado real depende de quanto desperdício existe, do perfil de carga e do quanto da arquitetura pode mudar. O método, porém, é replicável.
Por que o custo de cloud estrangeiro pesa tanto
Três fatores se somam. O primeiro é a cobrança em dólar, que transforma qualquer ineficiência em risco cambial. O segundo é o modelo de precificação, com muitos itens cobrados separadamente: computação, armazenamento, IPs, balanceadores, snapshots e, principalmente, tráfego de saída (egress). O terceiro é cultural: times provisionam rápido para entregar e raramente voltam para limpar.
Por isso, o custo de cloud raramente cai com uma única decisão. Ele cai com um conjunto de ajustes pequenos, medidos e repetidos. Se você quer a visão complementar, vale ler também o post Custo de Cloud: como reduzir até 70% com DevOps na prática.
O que eu mudaria hoje, na ordem certa
1. Primeiro, visibilidade antes de qualquer corte
Não se otimiza o que não se enxerga. Antes de desligar qualquer coisa, eu padronizaria tags por projeto, ambiente e responsável, e separaria a fatura por produto. Com isso, o custo de cloud deixa de ser uma linha única e vira uma conta por cliente, por funcionalidade ou por squad.
- Tags obrigatórias em todo recurso novo;
- Alertas de orçamento por ambiente;
- Revisão mensal curta com engenharia e financeiro na mesma mesa.
2. Rightsizing e eliminação de desperdício
Aqui costuma estar o ganho mais rápido. Máquinas superdimensionadas, ambientes de homologação ligados 24 horas, discos órfãos, snapshots antigos e IPs reservados sem uso aparecem em quase toda auditoria. Eu olharia métricas reais de CPU, memória e rede de pelo menos algumas semanas e reduziria o tamanho das instâncias com margem de segurança.
Ambientes de teste e desenvolvimento podem ser agendados para desligar fora do horário comercial. É um ajuste simples, com impacto direto no custo de cloud e zero efeito para o cliente final.
3. Arquitetura: egress, storage e serviços gerenciados
Depois da limpeza, vem o desenho. Eu revisaria três pontos:
- Tráfego de saída: dados que saem da cloud costumam custar caro; CDN, compressão e cache reduzem esse volume.
- Armazenamento em camadas: dados frios não precisam ficar em disco de alta performance.
- Serviços gerenciados: eles poupam trabalho operacional, mas alguns têm preço alto para cargas previsíveis; avalie caso a caso se um serviço próprio, bem automatizado, entrega o mesmo resultado por menos.
4. Infraestrutura como código e deploy automatizado
Sem automação, a otimização vira projeto pontual e o desperdício volta. Com infraestrutura como código, cada recurso nasce com tamanho, tags e ciclo de vida definidos, e fica fácil revisar mudanças em pull request. Somar um pipeline confiável reduz erro humano e permite recriar ambientes sob demanda. Um bom ponto de partida é o tutorial de deploy automatizado com GitHub Actions e Docker.
5. Migração planejada, inclusive para cloud brasileira
Se o custo de cloud continua alto mesmo após os ajustes, o próximo passo é questionar onde cada carga deve rodar. Cargas previsíveis, com uso constante, costumam se beneficiar de provedores com preço em reais e menor custo de tráfego. Como fundador da Kubmix, uma cloud brasileira, tenho interesse nesse tema e deixo isso claro: a decisão deve vir de testes, não de discurso.
Minha recomendação é migrar por etapas:
- Escolha uma carga de baixo risco e meça latência, disponibilidade e custo real;
- Mantenha o rollback documentado e testado;
- Só então avance para cargas mais críticas, mantendo serviços muito específicos onde fizer sentido, em uma arquitetura híbrida.
Como cortar sem perder performance
Reduzir gasto sem medir qualidade é jogar no escuro. Antes de cada mudança, defina indicadores claros e compare antes e depois:
- Latência e taxa de erro dos serviços principais;
- Utilização de CPU e memória com margem para picos;
- Custo por cliente ou por transação, a métrica que realmente importa para um SaaS.
Esse último indicador muda a conversa. Em vez de comemorar uma fatura menor, você acompanha se o custo de cloud por unidade de receita está caindo enquanto o produto cresce. É isso que protege margem e permite precificar com segurança.
Outro cuidado é não mexer em tudo ao mesmo tempo. Aplique uma mudança por vez, observe e registre o ganho. Assim você sabe o que funcionou e consegue defender cada decisão perante o time e a diretoria.
Conclusão
Controlar o custo de cloud não é um corte único, e sim uma disciplina: enxergar a conta, limpar o desperdício, ajustar a arquitetura, automatizar com código e decidir com dados onde cada carga deve rodar. Em muitos casos, o potencial de economia é grande, podendo chegar perto de 70% quando o ponto de partida é desorganizado, mas o caminho seguro passa por medir tudo. Comece pela visibilidade e pelo rightsizing nesta semana; o restante você constrói em cima de números reais.
