Por que sua fatura de cloud cresce todo mês sem você mudar nada

Você não subiu uma feature nova. Não escalou o time. O tráfego do produto está estável há três meses. Mesmo assim, a fatura de cloud chegou mais alta que a do mês anterior, de novo.

O primeiro instinto é abrir o console e procurar o recurso errado: alguma instância esquecida ligada, algum bug de configuração. Às vezes é isso. Na maioria das vezes, não tem nenhum vilão único para encontrar.

Esse padrão não é bug de billing nem coincidência. É o resultado esperado de como provedores de nuvem cobram: por consumo variável, não por capacidade fixa.

Cada camada de elasticidade que resolveu um problema de performance no passado, autoscaling, replicação entre zonas, storage em camadas, adicionou uma dimensão de custo que ninguém monitora ativamente no dia a dia. A fatura sobe porque a arquitetura foi desenhada para responder a demanda, não para conter gasto.

O tamanho real do problema

O relatório FinOps in Focus, da Harness (2025) projetou US$ 44,5 bilhões em desperdício de infraestrutura cloud para 2025. Isso equivale a 21% de todo o gasto corporativo em nuvem no mundo.

O State of the Cloud Report 2025, da Flexera, chegou a um número parecido pelo outro lado: 84% das organizações apontam a gestão de gasto em cloud como o principal desafio atual. O orçamento planejado já está sendo ultrapassado em 17% na média.

Nenhum desses números descreve empresas mal geridas. Descreve o comportamento padrão de uma arquitetura elástica quando ninguém está olhando para ela todo dia.

O provisionamento nunca fica parado

Por que o autoscaling não volta sozinho

Autoscaling resolve pico de tráfego, mas raramente volta ao tamanho original com a mesma agilidade com que cresce. A causa costuma ser configuração assimétrica: o time define alarmes agressivos para escalar (scale-out a 60% de uso de CPU, por exemplo) e limites bem mais conservadores para reduzir (scale-in só abaixo de 15%). O autoscaler sobe rápido e desce devagar, quando desce.

Segundo o levantamento da Harness, 71% dos times de desenvolvimento não fazem spot orchestration e 61% não fazem rightsizing das instâncias depois que elas sobem. O resultado é um parque de máquinas maior do que o necessário, travado no limiar do pior dia do trimestre por causa de alarmes mal calibrados, rodando o mês inteiro nesse tamanho.

Isso não aparece como uma linha de custo isolada na fatura. Aparece distribuído em dezenas de recursos pequenos, cada um alguns reais acima do necessário. Juntos, formam a diferença entre a conta que você esperava e a que chegou. Sem um processo recorrente de revisão de instâncias, esse excesso vira base, não pico.

Quem deveria estar revisando isso

O problema raramente é técnico. Rightsizing existe como prática há anos, e a maioria das ferramentas de cloud já expõe métrica de utilização por instância.

O que falta é rotina: alguém revisando esses números toda semana, com autoridade para desligar ou redimensionar o que sobrou de um pico que já passou. Sem esse dono, o dimensionamento de pico vira o dimensionamento padrão.

Recursos que continuam cobrando depois que o motivo acabou

Os recursos órfãos mais comuns

Volume de disco de um teste que terminou em março. Load balancer de uma versão do produto que já foi descontinuada. IP elástico reservado para uma migração que nunca aconteceu.

Nenhum desses itens aparece em um dashboard de performance, porque nenhum deles está fazendo nada. É por isso que continuam ativos: ninguém recebe alerta de que um recurso parado está sendo cobrado.

O tempo que leva para alguém notar

Menos da metade das equipes tem visibilidade em tempo real sobre isso. Segundo a mesma pesquisa da Harness, 43% enxergam recursos ociosos e 39% enxergam recursos órfãos.

Na prática, o tempo médio entre um recurso virar lixo e alguém notar é de 31 dias. Multiplique isso pelo número de squads rodando workloads em paralelo, e o acúmulo deixa de ser marginal.

Tráfego entre zonas cobra pelo que se move

Onde o tráfego se esconde

Storage parado tem custo previsível. Egress, a saída de dado para a internet, e tráfego cross-AZ são cobrados por gigabyte transferido, não por gigabyte armazenado. Na era de Kubernetes e microsserviços, arquiteturas distribuídas movem dado o tempo todo: um pod na Zona A consultando um banco na Zona B, backup incremental, tráfego roteado de forma ineficiente através de um NAT Gateway, sincronização de cache entre réplicas.

Cada uma dessas operações é invisível no código. Só fica visível na fatura, semanas depois.

O preço de mais resiliência

Dobrar a resiliência de uma aplicação, replicando serviços em múltiplas zonas, quase sempre dobra parte do custo de rede junto. Isso acontece mesmo sem dobrar o tráfego de usuário final.

A conta reflete decisões de arquitetura tomadas meses atrás, executadas em silêncio todo mês desde então.

Capacidade reservada é decidida com pouco dado real

A desconexão entre FinOps e dev

Compromissos de capacidade reservada, Reserved Instances ou Savings Plans, deveriam reduzir custo. Na prática, segundo o mesmo relatório da Harness, 55% dos desenvolvedores dizem que essas decisões de compra são baseadas em estimativa, não em dado real de uso.

Do lado da governança, 52% dos líderes de engenharia apontam a desconexão entre FinOps e times de desenvolvimento como causa direta de desperdício. Apenas 32% dos times têm automação real para impor política de custo.

O efeito prático: quem decide a arquitetura não vê a fatura, e quem vê a fatura não decide a arquitetura. Cada lado otimiza para o próprio objetivo, entrega rápida de um lado, orçamento fechado do outro, e o custo variável fica sem dono.

Um compromisso que ninguém revisita

Um erro comum de arquitetura: o time reserva capacidade baseando-se no pico de tráfego do ano anterior, uma Black Friday, por exemplo, em vez de comprometer apenas a linha de base constante do sistema. Doze meses depois, o provedor continua faturando esse compromisso superdimensionado todo mês, independente de o produto ter crescido, encolhido ou mudado de arquitetura no meio do caminho.

Ninguém tomou uma decisão errada ao buscar o desconto do compromisso de longo prazo. O erro foi aplicar esse modelo de reserva sobre uma métrica de pico elástico, em vez do baseline. Faltou um gatilho para revisar essa decisão depois.

Onde previsibilidade entra na conta

Faturamento em real, painel único

Parte desse problema é estrutural ao modelo de cloud pública global: preço em dólar, cobrança por dezenas de métricas separadas, região e zona influenciando o valor final do mesmo recurso.

Uma base sólida de infraestrutura no Brasil ataca justamente esse ponto. O Locaweb Cloud roda em data center brasileiro, com faturamento em real e gerenciamento das máquinas virtuais centralizado em um único painel. A plataforma também não cobra por tráfego de entrada ou saída, o que remove de vez a variável de egress e cross-AZ que mais surpreende quem migra de uma cloud pública global. Isso elimina boa parte da fragmentação de custo que aparece em ambientes multi-serviço: você vê o que está rodando, sem reconciliar dez itens de linha em dólar para entender de onde veio o aumento.

Quando VPS resolve melhor que elasticidade

Para workloads com padrão de uso mais estável, sem necessidade de elasticidade agressiva, migrar parte da carga para um servidor VPS com custo fixo mensal remove de vez a variável mais difícil de prever: o consumo que oscila sem aviso.

Workloads core do produto, aqueles que rodam o tempo todo em volume parecido, raramente precisam da elasticidade completa de uma cloud pública. É o mesmo raciocínio por trás de um certificado SSL, item de custo fixo e previsível, contra o tráfego de rede, que nunca é.

Para aprofundar antes de decidir

Antes de decidir entre nuvem pública, VPS ou modelo híbrido, compare as diferenças reais entre on-premise e cloud computing e o que uma arquitetura IaaS bem dimensionada resolve na prática.

As tendências de infraestrutura de TI para 2026 já colocam consolidação de custo lado a lado com performance no planejamento, para quem constrói produto digital no Brasil.

FAQ – Perguntas frequentes sobre custo de cloud