A conta de cloud raramente diminui por conta própria. Recursos ficam ligados sem uso, dimensionamentos ficam superestimados “por segurança”, serviços adotados para um teste continuam cobrando, e ninguém tem tempo de auditar. É comum uma primeira rodada de otimização cortar de 20% a 40% do custo sem tocar em disponibilidade ou performance.

Este artigo separa as ações em ganhos rápidos (dias), ganhos estruturais (semanas) e disciplina contínua, para que a conta não volte a inchar depois.

Antes de cortar: entender a conta

O primeiro passo é ter visibilidade. A maioria dos provedores oferece um detalhamento por serviço, por recurso e por etiqueta. Se os recursos não estão etiquetados por ambiente, projeto e responsável, esse é o passo zero — sem isso, você corta às cegas.

Com o detalhamento em mãos, identifique os cinco ou seis itens que respondem pela maior parte do custo. Otimizar o que é irrelevante consome tempo e não move o ponteiro.

Ganhos rápidos

  • Desligar ambientes de teste fora do horário comercial — homologação e desenvolvimento não precisam rodar de madrugada nem no fim de semana. Automatizar liga/desliga corta a metade ou mais desse custo.
  • Remover recursos órfãos — discos não anexados a nenhuma máquina, IPs reservados sem uso, snapshots antigos, balanceadores sem destino, imagens de máquina que ninguém usa.
  • Ajustar o tamanho de máquinas superdimensionadas — comparar o uso real de CPU e memória com o que foi provisionado. Muitas máquinas rodam a 10% e pagam por 100%.
  • Limpar logs e backups antigos — retenção infinita custa; defina prazos por tipo de dado.
  • Consolidar recursos subutilizados — três máquinas pequenas ociosas podem virar uma.

Ganhos estruturais

  • Planos de uso comprometido — para a carga que é estável e vai continuar existindo, um compromisso de 1 ou 3 anos dá descontos grandes sobre o preço sob demanda.
  • Autoescala de verdade — subir capacidade nos picos e reduzir nos vales, em vez de manter o pico o tempo todo.
  • Camadas de armazenamento — mover dados acessados raramente para storage frio, muito mais barato.
  • Cache — um cache bem posicionado reduz a carga no banco e permite máquinas menores.
  • CDN para conteúdo estático — servir imagens, scripts e arquivos da borda, aliviando os servidores de origem e a transferência de dados.
  • Revisar serviços gerenciados premium — às vezes a versão básica de um serviço atende, a um terço do custo.

Transferência de dados: o custo escondido

Uma linha que surpreende em quase toda conta de cloud é a transferência de dados: sair da cloud para a internet, trafegar entre regiões, entre zonas de disponibilidade. Arquiteturas que espalham componentes sem cuidado geram tráfego cruzado caro. Manter os componentes que conversam muito na mesma região e zona, e usar CDN para o que vai para o usuário, reduz essa linha.

O que não cortar

Otimização não pode virar risco. Alguns itens não devem ser tocados em nome da economia:

  • Redundância que sustenta a disponibilidade — ter só uma instância para economizar é trocar custo por risco.
  • Backups e a capacidade de restaurá-los.
  • Monitoramento e alertas.
  • Margem de capacidade para o crescimento previsto e para picos conhecidos.
  • Segurança — logs de auditoria, criptografia, isolamento de rede.

Instâncias spot e preemptíveis

Os provedores oferecem capacidade com desconto grande — às vezes 60% a 90% — em troca de poder retomá-la com pouco aviso. É a chamada instância spot ou preemptível. Para cargas tolerantes a interrupção — processamento em lote, renderização, testes, filas que podem esperar —, é uma economia enorme. Para a aplicação principal que serve usuários, não serve, a menos que a arquitetura saiba lidar com uma máquina sumindo no meio do trabalho.

Uma estratégia comum é usar spot para a maior parte da capacidade de processamento e manter uma base pequena de capacidade garantida para o mínimo essencial.

Right-sizing: a economia mais óbvia e mais ignorada

Right-sizing é ajustar o tamanho de cada recurso ao uso real. É a economia mais direta e a mais adiada, porque exige olhar métricas de cada máquina e ter coragem de reduzir. O padrão que se encontra em quase toda conta: máquinas provisionadas para um pico que nunca veio, ou dimensionadas na base do “vamos pegar a maior para não ter problema”.

Os provedores têm ferramentas de recomendação de right-sizing que comparam o provisionado com o usado e sugerem ajustes. Revisar essas recomendações mensalmente, e aplicar as seguras, mantém o desperdício sob controle.

Disciplina contínua

Sem acompanhamento, a conta volta a inchar em poucos meses. O que mantém sob controle:

  • Revisão mensal do custo por serviço e por ambiente, com alguém responsável.
  • Alertas de orçamento que avisam quando um serviço ultrapassa o esperado.
  • Etiquetagem obrigatória de todo recurso novo.
  • Política de desligamento automático para ambientes não produtivos.
  • Revisão trimestral de planos de compromisso conforme a carga evolui.

Custo e arquitetura andam juntos

Boa parte do custo de cloud é definida na arquitetura, não na configuração. Um sistema que consulta o banco a cada requisição, sem cache, precisa de um banco maior. Um processo que roda de forma síncrona quando poderia ser em fila precisa de mais máquinas em pé. Quando a conta é alta de forma estrutural, a economia real vem de ajustes de arquitetura, não de desligar recursos.

Custo por ambiente: produção não é o único que pesa

Em muitas empresas, a soma dos ambientes de desenvolvimento, homologação, demonstração e testes chega perto ou até supera o custo de produção. Cada desenvolvedor com seu ambiente pessoal, ambientes de feature que ninguém destruiu, cópias de produção para testes que ficaram ligadas. A etiquetagem por ambiente revela isso, e políticas simples — destruição automática de ambientes efêmeros, desligamento noturno, compartilhamento de ambientes de teste — cortam bastante sem afetar ninguém.

FinOps: cultura, não só ferramenta

O termo FinOps descreve a prática de gestão financeira de cloud como responsabilidade compartilhada entre times técnicos e financeiro. Na essência, é simples: quem provisiona recursos enxerga o custo do que provisiona, existe uma revisão regular, e a otimização é um trabalho contínuo com dono, não um mutirão anual. Ferramentas ajudam, mas o que muda o resultado é a visibilidade do custo chegar a quem toma as decisões técnicas.

Quando a economia não vale o esforço

Otimização de cloud tem retorno decrescente. As primeiras ações — órfãos, dimensionamento, desligar teste — dão ganho grande com pouco esforço. Depois de um ponto, cada porcento a menos exige mudanças de arquitetura que custam tempo de desenvolvimento. Vale calcular: se o esforço de reduzir mais 5% da conta custa mais do que esses 5% em um ano, é melhor investir esse tempo no produto.

Comece medindo, não cortando

Um erro comum é começar uma otimização pela lista de “coisas que dá para cortar” antes de entender de onde vem o custo. Isso leva a economizar centavos em serviços pequenos enquanto o item que responde por metade da conta continua intocado. A ordem certa é: primeiro o detalhamento por serviço e por recurso, depois a identificação dos cinco ou seis maiores, e só então as ações — concentradas onde o dinheiro está.

Vale também estabelecer uma linha de base antes de mexer, para conseguir medir o efeito de cada mudança. “A conta caiu” não é suficiente; o útil é saber que ação gerou qual economia, para saber o que repetir.

Como a Jumps trata

A Jumps inclui o acompanhamento de custo de cloud na sustentação: relatório mensal por serviço, alertas de orçamento e revisões periódicas de dimensionamento e de arquitetura. Em infraestrutura e cloud, otimização de custo entra como trabalho recorrente, não como projeto único.

Se a sua conta de cloud cresceu sem explicação clara, fale com a Jumps para uma análise.