A escala do problema: o que os dados dizem
O relatório da Flexera sobre o estado do cloud em 2025 documenta que 70% das empresas pagam por recursos cloud que não utilizam. A estimativa de desperdício em IaaS e PaaS caiu para 27% do gasto total, o menor nível já registrado pela pesquisa, mas ainda assim representa mais de um quarto de cada real gasto em cloud sendo desperdiçado em recursos ociosos ou subutilizados.
Para contextualizar em valor absoluto: em uma empresa que gasta R$ 50.000 por mês em cloud, 27% de desperdício representa R$ 13.500 mensais pagos sem nenhum retorno operacional. R$ 162.000 por ano. Em um ambiente maior, de R$ 200.000 mensais, são R$ 54.000 por mês e R$ 648.000 por ano escoando em recursos que ninguém usa.
Qual é o desperdício mensal estimado no seu ambiente? Encontre sua linha.
| Gasto mensal total em cloud |
Desperdício estimado (27%) |
Desperdício anual |
Potencial de recuperação |
| R$ 10.000 / mês |
R$ 2.700 |
R$ 32.400 |
Moderado |
| R$ 30.000 / mês |
R$ 8.100 |
R$ 97.200 |
Significativo |
| R$ 50.000 / mês |
R$ 13.500 |
R$ 162.000 |
Alto |
| R$ 100.000 / mês |
R$ 27.000 |
R$ 324.000 |
Crítico |
| R$ 200.000 / mês |
R$ 54.000 |
R$ 648.000 |
Emergencial |
Estimativa baseada nos dados do Flexera State of the Cloud 2025 (27% de desperdício médio em IaaS/PaaS). A recuperação real varia conforme o ambiente e as práticas de governança atuais.
Os seis tipos de recursos ociosos mais comuns
Antes de saber como identificar recursos ociosos, é preciso saber o que procurar. Os desperdícios em cloud se concentram em categorias bem definidas, cada uma com seu próprio padrão de comportamento e sua própria forma de identificação. Conhecê-las é o que permite fazer uma auditoria eficiente em vez de uma varredura genérica.
💻
Instâncias ligadas sem carga
15 a 25% do desperdício total
O que é: Instâncias EC2, VMs ou containers rodando continuamente com utilização de CPU abaixo de 5% por semanas ou meses. Criadas para projetos que mudaram de escopo ou foram encerrados.
Perfil típico: Instância criada para um projeto piloto que acabou. Ambiente de staging que deveria ter sido desligado após a virada de produção. Servidor de homologação de um sistema que foi descontinuado.
📦
Recursos superdimensionados
12 a 20% do desperdício total
O que é: Instâncias provisionadas para o pico máximo estimado que nunca acontece. Uma instância de 16 vCPUs rodando workload que usa 2 vCPUs no dia a dia paga pelo equivalente a oito instâncias maiores do que o necessário.
Perfil típico: Arquiteto dimensionou para “o dia que o sistema crescer”. O sistema cresceu em usuário, não em processamento. Nunca foi revisado. Cobra o dobro do necessário há dois anos.
🔬
Ambientes de teste sempre ligados
8 a 15% do desperdício total
O que é: Ambientes de desenvolvimento, QA e staging operando 24 horas, 7 dias por semana, quando são usados apenas em horário comercial. Um ambiente de teste que roda 168 horas semanais e é usado 40 está pagando pelas 128 horas restantes sem nenhum valor.
Perfil típico: Time de desenvolvimento criou um ambiente espelhado de produção para testar uma feature nova. A feature foi para produção. O ambiente ficou.
🔗
Recursos órfãos não excluídos
5 a 12% do desperdício total
O que é: IPs elásticos não associados a nenhuma instância, volumes de disco desanexados, snapshots antigos acumulados, load balancers sem tráfego, funções Lambda sem nenhuma invocação. Cada um cobra uma fração do custo total que soma ao longo do tempo.
Perfil típico: A instância foi deletada, mas o volume EBS de 500GB ficou. Ninguém percebeu. Três anos depois, são US$ 50 por mês pagos por um disco que não existe mais na mente de ninguém.
📸
Storage e backups sem política de retenção
10 a 20% do desperdício total
O que é: Dados armazenados em camadas premium (S3 Standard, Azure Hot) quando não são acessados há meses. Snapshots criados diariamente sem política de exclusão, acumulando indefinidamente. Logs sem TTL que crescem a cada hora.
Perfil típico: Política de backup criada há três anos cria um snapshot por dia e nunca deleta. Hoje há mais de mil snapshots de um banco de dados que poderiam ser reduzidos a 30 sem nenhum impacto operacional.
🔑
Licenças de software sem uso
5 a 10% do desperdício total
O que é: Licenças de SaaS ou software instalado em instâncias de cloud com zero ou pouquíssimos acessos nos últimos 90 dias. Ferramentas de análise, monitoria, segurança ou colaboração contratadas e não usadas.
Perfil típico: Empresa contratou 50 licenças de uma ferramenta de análise de dados. Quinze pessoas usam regularmente. Trinta e cinco licenças estão ativas e sendo pagas mensalmente sem nenhum acesso.
Como identificar recursos ociosos: o método por categoria
A identificação de recursos ociosos não é uma busca aleatória: é um processo sistemático por categoria, usando as ferramentas nativas do provedor e critérios objetivos de uso. Para cada categoria de recurso, há um critério de inatividade e uma ferramenta específica de consulta. O processo completo, feito pela primeira vez em um ambiente de tamanho médio, costuma levar de dois a quatro dias e identificar entre 20% e 35% do gasto total em candidatos a eliminação ou otimização.
Guia de identificação: critério, ferramenta e o que procurar por categoria
| Categoria |
Critério de candidato a eliminação |
Ferramenta de identificação |
Ação recomendada |
| Instâncias EC2 / VMs |
CPU média abaixo de 5% nos últimos 14 dias ou zero conexões de rede nos últimos 7 dias |
AWS Trusted Advisor (Low Utilization) / Azure Advisor / GCP Recommender |
Validar com o dono do recurso se ainda é necessário. Parar ou terminar se não houver justificativa. |
| Volumes EBS / Discos |
Volumes no estado “available” (desanexados de qualquer instância) há mais de 7 dias |
AWS CLI: aws ec2 describe-volumes –filters Name=status,Values=available / Azure Portal: Disks sem proprietário |
Criar snapshot de segurança e deletar o volume. Custo do snapshot é 80% menor que o do volume. |
| IPs elásticos / Públicos |
IPs alocados mas não associados a nenhuma instância ou load balancer em execução |
AWS Console: EC2 > Elastic IPs, filtrar por “Not Associated” / Azure: IP Addresses sem recurso |
Liberar o IP. Se for necessário para algum serviço futuro, documentar e liberar mesmo assim: IPs são facilmente alocados quando necessário. |
| Snapshots |
Snapshots com mais de 30 dias que excedem a política de retenção definida ou sem política definida |
AWS CLI: aws ec2 describe-snapshots –owner-ids self / GCP: gcloud compute snapshots list |
Definir política de retenção (ex: 7 ou 30 dias) e excluir snapshots que excedem o período. Automatizar com AWS Data Lifecycle Manager. |
| Load balancers |
Balanceadores com zero requisições nos últimos 7 dias ou com zero instâncias registradas como saudáveis |
AWS CloudWatch: métrica RequestCount com período de 7 dias / Azure Monitor: Load Balancer requests |
Validar se o serviço roteado ainda está ativo. Se não, deletar o load balancer e remover a entrada de DNS correspondente. |
| S3 / Blob Storage |
Objetos em camada Standard não acessados há mais de 30 dias ou buckets com zero acesso nos últimos 90 dias |
AWS S3 Storage Lens / S3 Intelligent-Tiering metrics / Azure Storage Insights |
Criar política de lifecycle para migrar automaticamente para Glacier (S3) ou Cool/Archive (Azure). Reduz custo em 70 a 80% sem deletar os dados. |
Como priorizar o que eliminar primeiro
Depois de identificar a lista de recursos candidatos à eliminação ou otimização, o próximo desafio é priorizar. Tentar resolver tudo de uma vez cria risco operacional desnecessário e paralisa o processo. Uma limpeza feita por prioridade, do mais seguro para o mais complexo, entrega valor rápido e constrói confiança para as próximas etapas.
Matriz de prioridade: impacto financeiro vs. risco de eliminação
Prioridade 1: Faça agora
Alto impacto, baixo risco
Recursos claramente ociosos sem nenhum sinal de uso recente. O risco de eliminar por engano é mínimo porque o padrão de abandono é inequívoco.
● IPs elásticos não associados
● Snapshots com mais de 90 dias sem política
● Load balancers com zero requisições em 30 dias
● Volumes desanexados há mais de 30 dias
|
Prioridade 2: Investigue antes
Alto impacto, requer validação
Recursos custosos com baixo uso aparente, mas que precisam de validação com o dono antes de eliminar. O risco de impacto operacional existe se o uso for legítimo mas esporádico.
● Instâncias com CPU baixo mas com dono desconhecido
● Bancos de dados sem conexões ativas visíveis
● Ambientes de staging sem uso aparente
● Storage em camadas caras sem acesso identificado
|
Prioridade 3: Otimize no ciclo seguinte
Baixo impacto, baixo risco
Itens de menor valor unitário mas que se acumulam com o tempo. Vale tratar neste ciclo mas não deve bloquear as prioridades mais altas.
● Logs antigos em camadas caras
● Pequenos volumes desanexados há menos de 7 dias
● Notificações SNS sem assinantes ativos
|
Prioridade 4: Documente e decida depois
Baixo impacto, alto risco
Recursos com custo pequeno mas cujo comportamento de uso não está claro. Não vale o risco de eliminar por engano um recurso que tem baixo custo mas função crítica invisível.
● Funções Lambda sem invocações recentes mas com regras de trigger complexas
● Resources sem tags e sem dono identificável
|
Como recuperar o investimento: ações por categoria
Identificar e priorizar são os dois primeiros passos. O terceiro e mais importante é agir. Cada categoria de recurso ocioso tem uma ação específica que maximiza a recuperação de valor sem criar risco operacional desnecessário. Aqui estão as ações recomendadas por categoria, com o impacto esperado de cada uma.
|
Migrar storage para camadas econômicas
Aplicar políticas de lifecycle para mover automaticamente dados não acessados há 30 dias para S3 Glacier (AWS), Azure Cool/Archive ou GCP Nearline/Coldline. Os dados ficam disponíveis quando necessário, com custo de acesso adicional, mas o custo de armazenamento cai 70 a 80%.
|
Economia típica
70 a 80%
do custo de storage afetado
|
Seguro
|
|
Rightsizing de instâncias superdimensionadas
Analisar o uso de CPU e memória nos últimos 30 dias e migrar instâncias com utilização abaixo de 30% para o tipo imediatamente menor. Uma instância t3.xlarge (4 vCPUs) com 15% de uso pode ser reduzida para t3.large (2 vCPUs) sem impacto percebível. Ferramentas como AWS Compute Optimizer fazem essa recomendação automaticamente.
|
Economia típica
40 a 60%
do custo das instâncias afetadas
|
Valide antes
|
|
Política de desligamento para ambientes de teste
Implementar desligamento automático de todos os recursos tagueados como dev, test, staging e QA fora do horário comercial (18h às 8h) e nos fins de semana. Usando AWS Instance Scheduler, Azure Automation ou scripts simples de automação, ambientes que rodam 168 horas por semana passam a rodar 40 horas, com economia proporcional de 76%.
|
Economia típica
60 a 76%
do custo de ambientes de teste
|
Seguro
|
|
Instâncias reservadas para workloads estáveis
Para instâncias que rodam continuamente há mais de 6 meses com uso estável, contratar reserved instances de 1 ano reduz o custo em 40% em relação ao on-demand, sem nenhuma mudança técnica no ambiente. A decisão exige análise de estabilidade do workload e comprometimento de 12 meses, mas o retorno começa no primeiro mês.
|
Economia típica
40 a 60%
vs. custo on-demand
|
Valide antes
|
Como automatizar para não deixar o problema voltar
A limpeza pontual de recursos ociosos é um ponto de partida, não uma solução. Em empresas com times de engenharia ativos, novos recursos ociosos surgem todo mês: novos projetos são criados, ambientes são provisionados, projetos são encerrados e os recursos ficam para trás. Sem automação, a auditoria precisa ser repetida manualmente a cada ciclo, e o desperdício volta a acumular entre uma auditoria e outra.
As quatro automações que eliminam a volta do desperdício
| ⚙️ |
Desligamento automático de ambientes por horário
Todo recurso tagueado como dev, test, staging ou QA é desligado automaticamente às 18h e religado às 8h. Finais de semana, permanecem desligados. AWS Instance Scheduler, Azure Automation Runbooks e GCP Cloud Scheduler fazem isso nativamente.
|
| 🏷️ |
Obrigatoriedade de tagueamento no provisionamento
Qualquer recurso criado sem as tags obrigatórias (projeto, responsável, ambiente, data de expiração) é automaticamente negado via AWS SCP, Azure Policy ou GCP Organization Policy. Isso garante que todo recurso novo já nasce com um dono e uma data de revisão.
|
| 🗑️ |
Política de retenção automática para snapshots e logs
Snapshots com mais de 30 dias são automaticamente excluídos (ou movidos para arquivo) via AWS Data Lifecycle Manager ou Azure Backup policies. Logs com mais de 90 dias migram automaticamente para camadas de armazenamento mais baratas via políticas de lifecycle do S3 ou Azure Storage.
|
| 🔔 |
Alertas de anomalia de custo em tempo real
AWS Cost Anomaly Detection, Azure Cost Alerts e GCP Budget Alerts monitoram o padrão de gasto e enviam notificação quando um serviço cresce mais de 20% em relação ao período anterior, sem que um provisionamento justifique esse crescimento. O alerta chega antes do fim do mês.
|
Como o MobCloud identifica recursos ociosos
O MobCloud está sendo desenvolvido pela Mobit para entregar visibilidade de cloud integrada ao MobVision. No contexto de recursos ociosos, o diferencial do MobCloud é que ele não apenas lista os recursos candidatos à eliminação, mas conecta essa visibilidade com os dados de projetos e contratos que a empresa já gerencia no MobVision, permitindo saber instantaneamente se um recurso ocioso ainda tem algum projeto ativo que o justifique.
🚀
MobCloud: identificação de recursos ociosos integrada ao MobVision
|
O que o MobCloud identificará automaticamente
● Instâncias com CPU abaixo de 5% por mais de 14 dias
● Volumes e IPs não associados a nenhum recurso ativo
● Storage em camada premium sem acesso recente
● Snapshots além do período de retenção definido
|
O diferencial da integração com o MobVision
● Cruzamento com contratos ativos: recurso ocioso tem projeto ativo no MobVision?
● Custo de cloud junto com custo de Telecom e TI: visão do custo total de tecnologia
● Relatório de saving potencial em linguagem executiva para o CFO
|
Quer ser avisado quando o MobCloud lançar? Entre em contato com o time Mobit.
✅
Por onde começar agora, antes de qualquer ferramenta nova: Abra o AWS Trusted Advisor, Azure Advisor ou GCP Recommender no painel do seu provedor. Essas ferramentas são gratuitas e já listam instâncias de baixo uso, volumes desanexados e IPs não utilizados. Uma tarde de análise desses relatórios costuma revelar entre 10% e 20% do gasto total em candidatos imediatos à eliminação.
Perguntas frequentes
Como identificar recursos ociosos em cloud?
▼
O processo de identificação de recursos ociosos é feito por categoria, usando ferramentas nativas do provedor e critérios objetivos de uso. Para instâncias de computação, o critério é CPU média abaixo de 5% nos últimos 14 dias, verificado via AWS Trusted Advisor, Azure Advisor ou GCP Recommender. Para volumes de disco, são volumes no estado “desanexado” há mais de 7 dias. Para IPs, são IPs alocados mas não associados a nenhum recurso. Para storage, são dados não acessados há mais de 30 dias. Cada provedor tem ferramentas nativas que geram essas listagens automaticamente, e uma auditoria inicial usando apenas essas ferramentas gratuitas costuma revelar 15% a 25% do gasto total em candidatos à eliminação ou otimização.
Qual o percentual médio de desperdício em cloud?
▼
Segundo o relatório State of the Cloud 2025 da Flexera, a estimativa média de desperdício em IaaS e PaaS caiu para 27%, o menor nível já registrado. Isso significa que em média 27% de cada real gasto em cloud vai para recursos ociosos ou subutilizados. Para empresas sem práticas de FinOps estabelecidas, esse percentual pode ser significativamente maior, chegando a 40% ou mais. O relatório também documentou que 70% das empresas pagam por recursos cloud que não utilizam, independentemente do percentual total do desperdício.
O que é rightsizing em cloud?
▼
Rightsizing em cloud é o processo de ajustar o tamanho dos recursos de computação ao uso real do workload que eles suportam. Uma instância superdimensionada paga por capacidade que não é usada. O rightsizing analisa o uso histórico de CPU, memória e rede e recomenda o tipo de instância adequado para suportar a carga real com margem de segurança, sem o excesso de capacidade que gera custo sem retorno. A economia típica do rightsizing é de 40% a 60% do custo das instâncias afetadas. Ferramentas como AWS Compute Optimizer, Azure Advisor e GCP Recommender fazem essa análise automaticamente e geram recomendações de rightsizing.
Como evitar que recursos ociosos se acumulem novamente?
▼
Quatro automações estruturais evitam que o problema volte: desligamento automático de ambientes de teste fora do horário comercial (redução de 60% a 76% do custo desses ambientes); obrigatoriedade de tagueamento no provisionamento, impedindo que recursos sem dono e sem data de revisão sejam criados; políticas de retenção automática para snapshots e logs, eliminando o acúmulo silencioso; e alertas de anomalia de custo que notificam quando um serviço cresce acima do padrão histórico. Essas quatro práticas, implementadas juntas, reduzem significativamente o volume de novos recursos ociosos criados ao longo do tempo.
Próximo Passo
Você sabe quantos recursos de cloud da sua empresa estão ativos agora sem nenhum uso?
A Mobit apoia empresas no diagnóstico de recursos ociosos em cloud e na implementação das práticas que evitam que o problema volte. Fale com um especialista.
Falar com especialista em otimização de cloud →
Diagnóstico sem compromisso. 280+ clientes na América Latina.
+55 11 3500-4088
Deixe um comentário