Redução de desperdício em nuvem: onde o dinheiro some sem ninguém perceber

Na prática, boa parte do que as empresas pagam de nuvem não é consumo. É sobra. Este guia mostra os sete pontos onde o desperdício se acumula, como medir cada um e por onde começar a faxina.

Para começar, abra a última fatura da sua nuvem e procure por três coisas.

Uma máquina virtual criada para um teste que terminou em março. Depois, um disco que sobreviveu à exclusão da máquina à qual pertencia. Por fim, um ambiente de homologação ligado 24 horas por dia para ser usado três horas por semana.

Se você encontrou os três, encontrou desperdício. Aliás, se não encontrou, provavelmente é porque a fatura não mostra isso. Ela mostra a soma.

E é justamente aí que está o problema. A conta de nuvem é apresentada como um número único e mensal, mas é composta por centenas de decisões pequenas tomadas por pessoas diferentes ao longo de anos. Nenhuma delas foi errada isoladamente. No entanto, juntas elas viram uma linha de custo que ninguém consegue explicar.

Na pesquisa State of the Cloud, os próprios respondentes estimam que cerca de 27% do gasto em nuvem das suas organizações é desperdício (Flexera, State of the Cloud Report, 2024). Ou seja, não é uma medição externa: é a percepção de quem administra o ambiente. E quando o time que paga a conta admite que um quarto dela não gera valor, o problema já não é técnico. É de gestão.

O que é desperdício em nuvem (e por que não é a mesma coisa que conta cara)

Desperdício em nuvem é todo recurso provisionado e cobrado que não entrega valor para o negócio, porque está ocioso, superdimensionado, órfão ou duplicado. Uma conta cara pode ser perfeitamente saudável se a empresa cresceu; uma conta pequena pode estar cheia de desperdício.

Essa distinção importa porque muda o que você mede. Se o objetivo é “gastar menos”, o caminho fácil é desligar coisas e torcer para nada quebrar. Se o objetivo é “eliminar desperdício”, o caminho é identificar o que está sendo pago sem uso correspondente, e isso é auditável.

Três categorias resumem quase tudo:

• Ocioso. O recurso existe, funciona e ninguém usa. Ambiente de teste ligado no fim de semana, réplica de leitura sem tráfego.
• Superdimensionado. O recurso é usado, mas está grande demais para a carga real. Uma instância com 16 vCPUs rodando em 6% de uso médio.
• Órfão. O recurso perdeu o dono. Discos, snapshots, IPs reservados e balanceadores que sobreviveram ao que servia.

Por outro lado, se a sua fatura subiu porque a empresa dobrou de tamanho, isso não é desperdício. É escala. O tema mais amplo está em custos na nuvem: o guia completo. Aqui, o recorte é só a sobra.

Os 7 lugares onde o desperdício em nuvem se acumula

Quase todo desperdício em nuvem se concentra em sete pontos: horários ociosos, superdimensionamento, armazenamento órfão, ambientes esquecidos, transferência de dados, camadas de serviço acima do necessário e retenção de backup sem política. Eles aparecem em ambientes de qualquer tamanho.

1. Recursos ligados fora do horário de uso

Ambientes de desenvolvimento, homologação, QA e treinamento costumam ser usados em horário comercial, de segunda a sexta. Isso são cerca de 45 horas por semana de um total de 168. Ainda assim, o restante é cobrado igual.

De fato, esse é o item de maior retorno por menor esforço em praticamente todo ambiente. Não exige refatorar nada: exige um agendamento de ligar e desligar.

2. Superdimensionamento (o famoso rightsizing)

Máquinas são dimensionadas com margem, o que é correto. O erro é nunca revisar a margem depois. O time provisiona para o pico projetado, o pico não vem, e a instância fica grande para sempre.

Para corrigir com segurança, você precisa de pelo menos 30 dias de métricas de CPU, memória, disco e rede. Sem histórico, redimensionar é chute.

3. Discos, snapshots e imagens órfãos

Volumes de armazenamento não são apagados automaticamente quando a máquina some. Snapshots se acumulam porque foram criados “só por segurança” antes de uma manutenção que aconteceu há dois anos.

É o desperdício mais silencioso, porque cada item é barato. O problema, porém, é a quantidade.

4. Ambientes de projeto que ninguém encerrou

Prova de conceito, piloto de fornecedor, ambiente de migração que virou permanente. Todo projeto cria infraestrutura; poucos projetos, porém, têm uma etapa formal de desmontagem.

5. Transferência de dados (egress e tráfego entre zonas)

Sair da nuvem custa. Trafegar entre zonas de disponibilidade costuma custar. Por isso, arquiteturas que conversam muito entre regiões geram uma linha de fatura que não aparece em nenhum diagrama.

6. Camadas de serviço acima da necessidade real

Armazenamento de acesso frequente guardando arquivos que ninguém abre há dois anos. Banco de dados em configuração de alta disponibilidade para um ambiente de teste. Suporte premium contratado para uma carga que não é crítica.

7. Backup e logs sem política de retenção

Retenção infinita é uma decisão, quase sempre uma decisão que ninguém tomou conscientemente. Guardar sete anos de log de aplicação em armazenamento quente é caro e, na maioria dos casos, não é exigido por norma nenhuma.

Tabela: onde procurar, como medir e qual o esforço

Tipo de desperdício	Como identificar	Esforço de correção	Risco de mexer
Ambiente ligado fora do horário	Uso de CPU/rede por faixa horária e dia da semana	Baixo (agendamento)	Baixo
Superdimensionamento	CPU e memória médias e de pico em 30 dias	Médio (exige janela)	Médio
Discos e snapshots órfãos	Volumes sem anexação; snapshots sem origem viva	Baixo	Baixo, com quarentena antes
Ambientes de projeto encerrado	Recursos sem dono ou tag de projeto ativo	Baixo	Médio (confirmar com o dono)
Transferência de dados	Linha de egress e tráfego entre zonas na fatura	Alto (envolve arquitetura)	Médio
Camada de serviço acima do uso	Padrão de acesso por objeto/arquivo	Médio	Baixo a médio
Retenção sem política	Volume total × idade dos dados	Médio (exige decisão jurídica)	Alto se cortar sem análise

Um ponto honesto: as três primeiras linhas costumam responder pela maior parte da economia rápida. Em compensação, as últimas exigem conversa com áreas fora da TI e não devem ser tratadas como faxina técnica.

Por que o desperdício em nuvem cresce sozinho

Desperdício em nuvem não é falta de competência técnica: é consequência previsível de um modelo em que provisionar é fácil, imediato e descentralizado, enquanto desprovisionar depende de alguém lembrar. Quatro causas organizacionais explicam quase todos os casos.

• Provisionar leva 40 segundos, aprovar uma compra levava 40 dias. No modelo antigo, comprar um servidor passava por orçamento, cotação e diretoria. Cada aquisição era discutida. Na nuvem, a fricção sumiu, e com ela sumiu também a conversa.
• Ninguém é dono do recurso. Quando o custo é rateado como “TI”, nenhuma área tem incentivo para reduzir o próprio consumo. É por isso que a alocação de custos cloud costuma ser pré-requisito para qualquer programa sério de redução: sem saber quem gasta o quê, você corta no escuro.
• O medo de derrubar produção paralisa a decisão. Desligar algo que ninguém sabe para que serve é arriscado. Como o risco de errar é visível e a economia é invisível, a decisão racional individual é não mexer.
• O ciclo de vida não tem fim. Existe processo para criar ambiente. Raramente, porém, existe processo para encerrá-lo.

Reduzir desperdício de forma sustentável é, portanto, mais um problema de processo do que de ferramenta. A FinOps Foundation identificou a redução de desperdício como a prioridade número um dos times responsáveis por gestão financeira de nuvem (FinOps Foundation, State of FinOps, 2024). Isso indica que a dificuldade não é reconhecer o problema. É institucionalizar a resposta.

Como medir o desperdício antes de cortar

Antes de desligar qualquer coisa, você precisa de três medidas: uso real por recurso em 30 dias, taxa de cobertura de identificação (tags) e custo por unidade de negócio. Sem elas, corte vira aposta.

• Uso real. Colete CPU, memória, IOPS de disco e rede por recurso, com granularidade de hora. Média engana: um servidor com 8% de CPU médio pode ter picos de 95% às 3h da manhã por causa de um processamento em lote.
• Cobertura de tags. Meça qual percentual do custo está associado a uma tag válida de dono, ambiente e projeto. Se a cobertura estiver abaixo de 80%, resolva isso antes de qualquer outra coisa: você não consegue perguntar “isso ainda é necessário?” para um recurso sem dono.
• Custo unitário. Custo por cliente, por pedido, por transação ou por usuário ativo. É, acima de tudo, a única métrica que separa crescimento de desperdício. Se a fatura sobe 20% e o custo por pedido cai, a nuvem está funcionando.

Só depois disso vem a ação. E a ação tem uma ordem segura:

1. Marque o recurso como candidato e avise o dono.
2. Coloque em quarentena: desligue, mas não apague, por 7 a 14 dias.
3. Só então elimine, com snapshot de resgate quando fizer sentido.
4. Documente a economia. Sem número registrado, o programa morre no terceiro mês.

Os cortes que parecem economia e não são

Nem toda redução de fatura é redução de custo: alguns cortes apenas transferem o gasto para outro lugar, geralmente para horas do time ou para risco de indisponibilidade. Vale nomear os quatro mais comuns.

• Cortar redundância de produção. Desligar a réplica ou a segunda zona de disponibilidade reduz a fatura hoje e cria um custo eventual muito maior. No levantamento anual sobre interrupções do Uptime Institute, mais da metade dos respondentes relatou que a sua interrupção significativa mais recente custou acima de US$ 100 mil (Uptime Institute, Annual Outage Analysis, 2024).
• Cortar backup ou retenção sem análise jurídica. Retenção não é só custo: em alguns setores é obrigação. Portanto, reduza com base em política definida com jurídico e compliance, não com base no tamanho do bucket.
• Reduzir instância até o limite. Rightsizing agressivo demais transfere o problema para latência e para chamados de suporte. A regra prática é deixar folga para o pico observado, não para a média.
• Migrar tudo para a camada mais barata de armazenamento. Camadas frias cobram pela recuperação. Ou seja, se o dado é lido com alguma frequência, o custo de leitura pode superar a economia de armazenamento.

A nuvem não resolve arquitetura ruim. Ela só cobra por ela mais rápido. Esse é um ponto que tratamos em detalhe no artigo redução de custos cloud.

Checklist da primeira faxina: 12 pontos

Use esta lista como um sprint de duas semanas. Cada item é verificável.

• Listar todos os volumes de armazenamento sem máquina associada.
• Listar snapshots com mais de 90 dias sem origem viva.
• Listar IPs públicos reservados e não atribuídos.
• Listar balanceadores de carga sem destino ativo.
• Identificar instâncias com CPU média abaixo de 10% em 30 dias.
• Identificar instâncias com memória alocada acima de 3 vezes o pico observado.
• Mapear ambientes de não produção e definir janela de ligar/desligar.
• Medir a cobertura de tags de dono, ambiente e centro de custo.
• Verificar a linha de transferência de dados na fatura e identificar a origem.
• Revisar a camada de armazenamento por padrão de acesso real.
• Revisar política de retenção de backup e log com jurídico.
• Registrar a economia estimada e a economia realizada de cada item.

No fim das contas, se os doze itens forem cumpridos, você terá não só uma fatura menor, mas algo mais valioso: um inventário confiável.

Como a Prodb ajuda na redução de desperdício em nuvem

A Prodb Tecnologia trabalha com infraestrutura em nuvem no Brasil há 15 anos e atende mais de 550 clientes. Boa parte deles chega com a mesma frase: “a conta subiu e ninguém sabe explicar”.

O que fazemos nesses casos não começa com uma proposta comercial. Começa com um mapeamento do ambiente: o que existe, quem usa, quanto consome de verdade e o que pode sair sem impacto. Só depois desse levantamento é que faz sentido discutir arquitetura.

Três características do nosso modelo mudam a conversa sobre desperdício:

• Arquitetura dimensionada por ambiente, não por template. O plano é montado a partir da carga real medida, não de um pacote pré-definido que sobra em uns pontos e falta em outros.
• Suporte técnico dedicado. Quem atende conhece o seu ambiente. Isso encurta a distância entre identificar um recurso ocioso e ter segurança para desligá-lo.
• Infraestrutura no Brasil, faturamento em real. Sem variação cambial na previsão orçamentária e com latência menor para usuários no país. Nossos servidores cloud operam sobre infraestrutura com certificações internacionais de nuvem.

Não prometemos um percentual de economia. Prometemos que você vai saber, item por item, o que está pagando e por quê. A partir daí, a decisão de cortar é sua, e informada.

Perguntas frequentes

O que é redução de desperdício em nuvem?

É o trabalho de identificar e eliminar recursos de nuvem que são cobrados sem entregar valor ao negócio, por estarem ociosos, superdimensionados, órfãos ou duplicados. Diferente de um corte genérico de gastos, parte de medição de uso real e é auditável item por item.

Quanto do gasto com nuvem costuma ser desperdício?

Na pesquisa State of the Cloud da Flexera (2024), os próprios responsáveis pelos ambientes estimam que cerca de 27% do gasto em nuvem das suas organizações é desperdício. O número real de cada empresa só aparece com medição de uso por pelo menos 30 dias.

Onde o desperdício em nuvem costuma se acumular?

Em sete pontos principais: recursos ligados fora do horário de uso, superdimensionamento, discos e snapshots órfãos, ambientes de projeto que ninguém encerrou, transferência de dados, camadas de serviço acima da necessidade e backup ou logs sem política de retenção.

Conta de nuvem cara é sinal de desperdício?

Não necessariamente. Uma conta alta pode ser saudável se a empresa cresceu, e uma conta pequena pode estar cheia de sobra. A métrica que separa crescimento de desperdício é o custo por unidade de negócio, como custo por cliente, pedido ou transação.

Como eliminar recursos ociosos sem derrubar nada em produção?

Siga uma ordem segura: marque o recurso como candidato e avise o dono, coloque em quarentena desligando sem apagar por 7 a 14 dias, só então elimine, com snapshot de resgate quando fizer sentido, e registre a economia obtida.

Quais cortes parecem economia mas não são?

Cortar redundância de produção, reduzir backup ou retenção sem análise jurídica, diminuir instâncias até o limite e mover tudo para a camada de armazenamento mais barata. Esses cortes reduzem a fatura, mas transferem o custo para risco de indisponibilidade, horas de equipe ou taxas de recuperação.