Migrei para a nuvem e o custo ficou maior do que antes: o que aconteceu e como corrigir

A migração para a nuvem foi aprovada com a promessa de agilidade, escalabilidade e redução de custos. Semanas depois, a fatura veio 30% acima do projetado. O sistema funciona, mas custa mais do que custava no servidor físico. A diretoria questiona, o time de TI não tem resposta clara e o financeiro começa a duvidar se a migração foi uma boa ideia. Esse é o cenário mais comum de migração mal planejada no Brasil — e tem nome: lift-and-shift sem otimização. O problema não é a nuvem. É que o servidor físico on-premises geralmente está superdimensionado para o pico de uso, e replicar esse superdimensionamento na nuvem significa pagar pelo excesso a cada hora, dia após dia, em vez de pagar uma vez pelo hardware. Este guia explica por que isso acontece, quais os sinais de alerta, como diagnosticar o superdimensionamento e o caminho para corrigir — sem precisar refazer a migração do zero.

Definição objetiva

Lift-and-shift (também chamado de Rehosting) é a estratégia de migração para nuvem que replica a infraestrutura on-premises para o ambiente cloud sem alterações de arquitetura: cada servidor físico vira uma instância de VM com as mesmas especificações de CPU, memória e armazenamento. É a abordagem mais rápida de migrar, mas frequentemente a mais cara de operar, porque transfere para a nuvem o superdimensionamento do ambiente físico — onde provisionar grande “por precaução” não gerava custo marginal relevante — para um ambiente onde cada GB de RAM e cada vCPU são cobrados por hora. Superdimensionamento pós-migração ocorre quando instâncias provisionadas com base no pico de uso histórico do datacenter operam consistentemente com menos de 20% a 30% da CPU e memória alocadas. Estudos da AWS mostram que até 40% das instâncias EC2 estão superdimensionadas em ambientes que migraram via lift-and-shift. A correção não exige refazer a migração: rightsizing, replatforming seletivo e adoção de modelos de compra com desconto são suficientes para reduzir a fatura em 20% a 50% nos primeiros 90 dias após diagnóstico.

40%
das instâncias EC2 estão superdimensionadas em ambientes que migraram via lift-and-shift, segundo estudos da AWS. Em ambientes Azure e GCP, o percentual é similar. O superdimensionamento é o custo invisível da migração rápida
AWS / Daniel Abraão 2026

47%
de redução no caso documentado de empresa de serviços financeiros: de R$ 180 mil para R$ 95 mil por mês após assessment completo com rightsizing, Savings Plans e migração de workloads batch para Spot. Com melhoria de performance.
Daniel Abraão 2026

R$ 22k→R$ 6k
de custo mensal de infraestrutura após startup SaaS migrar API monolítica para arquitetura serverless com Lambda e DynamoDB. Redução de 73% com latência 40% menor. Mesmo serviço, arquitetura adequada ao cloud
Daniel Abraão 2026

Neste artigo

Por que o custo de cloud ficou maior do que o esperado
Os sinais de que sua migração gerou superdimensionamento
Os 6 Rs da migração: qual estratégia sua empresa deveria ter usado
Como diagnosticar o superdimensionamento por provedor
Como corrigir: o plano de otimização pós-migração
Quando considerar repatriar: cloud nem sempre é a resposta certa
Perguntas frequentes

Por que o custo de cloud ficou maior do que o esperado

A migração para nuvem tem uma promessa legítima de redução de custo — mas essa promessa só se realiza quando a infraestrutura é otimizada para o modelo de consumo da nuvem, não apenas transferida para ela. Existem três razões estruturais pelas quais o custo frequentemente cresce após a migração.

Razão 1: superdimensionamento herdado do datacenter

A causa mais comum

No datacenter físico, o custo de um servidor é fixo após a compra: a empresa paga o mesmo se usar 5% ou 95% da capacidade. Por isso, provisionar “por precaução” não tem custo marginal relevante — o servidor já foi comprado de qualquer forma. Na nuvem, a lógica é completamente oposta: cada vCPU e cada GB de RAM são cobrados por hora, independentemente de quanto está sendo efetivamente usado.

O lift-and-shift copia o superdimensionamento do ambiente físico para o ambiente cloud. O servidor que tinha 32 GB de RAM e usava 6 GB vira uma instância de 32 GB que usa 6 GB — e paga pelas 26 GB ociosas a cada hora. Multiplicado por dezenas de instâncias, o resultado é uma fatura que pode ser 2 a 3 vezes o que seria necessário para a carga real.

Exemplo real

Instância m5.4xlarge (16 vCPU, 64 GB) usando consistentemente 2 vCPU e 8 GB = R$ 3.200/mês

Após rightsizing

m5.large (2 vCPU, 8 GB) = R$ 400/mês. Mesma performance, 87% mais barato.

Razão 2: custos ocultos que não estavam no planejamento inicial

Descubierto na primeira fatura

O TCO inicial de cloud costuma incluir apenas computação, armazenamento e rede. A primeira fatura real revela o que ficou de fora do planejamento: egress fees (saída de dados da nuvem para a internet ou para outras regiões), suporte premium do provedor, licenças de software que migram com o sistema mas precisam ser relicenciadas para o modelo cloud, IOF de 6,38% sobre pagamentos internacionais com cartão e a variação cambial sobre faturas em dólar.

Custo oculto	No planejamento	Na fatura real
Egress fees	Ignoradas	5% a 15% da fatura
IOF (cartão, Brasil)	Ignorado	+6,38% em tudo
Suporte do provedor	Mínimo	3% a 10% da fatura
Licenças de software	On-premises calculado	Relicenciamento cloud

O efeito acumulado

O cálculo inicial de TCO costuma incluir apenas computação, armazenamento e rede. No segundo trimestre pós-migração, o custo real aparece com esses itens adicionais, o que pode representa 20% a 30% acima do projetado

Razão 3: arquitetura on-premises não aproveitando a elasticidade da nuvem

Custo estrutural de longo prazo

Arquiteturas monolíticas on-premises precisam de servidores dimensionados para o pico de carga, porque não têm elasticidade: o servidor está ligado ou desligado, não existe meio-termo. Na nuvem, a elasticidade deveria permitir escalar para o pico e reduzir no vale — pagando apenas pelo que usar em cada momento.

Mas o lift-and-shift mantém a arquitetura monolítica no ambiente cloud: a instância precisa estar sempre ligada no tamanho do pico, porque o código não foi escrito para escalar horizontalmente. Resultado: a empresa paga por toda a elasticidade potencial da nuvem sem usufruir de nenhuma dela. O custo de operação é similar ao do datacenter — sem os benefícios que justificam a migração.

O contra-exemplo

API serverless com Lambda e DynamoDB: paga apenas pelas execuções reais, não pelas horas de instância. Custo cai de R$ 22k para R$ 6k/mês com latência melhor

Os sinais de que sua migração gerou superdimensionamento

Esses sintomas aparecem nos primeiros 30 a 90 dias após a migração e são os indicadores de que a infraestrutura precisa de otimização antes de se tornar o novo normal.

Fatura 20% a 30% acima do projetado nos primeiros 90 dias

O benchmark clássico de superdimensionamento pós-lift-and-shift. A fatura está dentro da faixa “esperada de erros de planejamento” mas persiste mês após mês sem tendência de redução — sinal de que o problema é estrutural, não pontual.

CPU e memória das instâncias abaixo de 20% na maior parte do tempo

Instâncias com utilização média abaixo de 20% por 7 dias ou mais são candidatas imediatas a rightsizing, segundo a própria AWS. Dados disponíveis gratuitamente no AWS Trusted Advisor, Azure Advisor e GCP Recommender.

Custo de cloud similar ou superior ao datacenter anterior — sem os benefícios

A migração foi vendida como redução de custo. Se o custo operacional de cloud está na mesma faixa do datacenter (ou maior) e a empresa ainda não tem elasticidade real, deploy mais rápido nem modernidade técnica, a migração não entregou o prometido e o ambiente precisa de otimização.

Volatilidade da fatura acima de 25% mês a mês sem variação correspondente no negócio

Variação de fatura acima de 25% sem evento de negócio que justifique (crescimento de usuários, campanha sazonal) indica ausência de governança e presença de recursos provisionados ad hoc sem processo de aprovação.

Toda a infraestrutura paga ao preço on-demand sem nenhum compromisso de prazo

Se após 6 meses de migração toda a infraestrutura ainda está no modelo on-demand (sem Reserved Instances, sem Savings Plans), a empresa está pagando até 60% a mais do que precisaria pelas instâncias estáveis que nunca vão desligar.

Os 6 Rs da migração: qual estratégia sua empresa deveria ter usado

A AWS popularizou o framework dos 6 Rs para classificar a estratégia de migração de cada workload. A escolha errada do R é o que determina se a migração vai gerar custo ou economia.

ESTRATÉGIA
Rehost

Lift-and-shift: mover como está, sem alterações

Mais rápido | Mais caro de operar

Copia a VM on-premises para uma instância cloud com as mesmas especificações. Zero de modernização arquitetural, zero de aproveitamento de elasticidade. Indicado para sistemas legados sem acesso ao código-fonte (ERP comprado, sistemas sem fornecedor ativo) onde refatoração é impossível ou economicamente inviável.

Indicado para: ERP legado (TOTVS, SAP B1 antigo), sistemas sem código-fonte acessível, migrações de emergência

ESTRATÉGIA
Replatform

Lift, tinker and shift: mover com ajustes de plataforma

Esforço moderado | Ganho imediato

Move a aplicação quase intacta mas substitui componentes de infraestrutura por serviços gerenciados: banco self-managed vira RDS/Azure SQL/Cloud SQL, servidor de e-mail vira SaaS. Sem reescrever código, com ganho real de custo de operação porque a gestão do banco, backups e patching ficam com o provedor.

Indicado para: aplicações com banco self-managed, e-commerce com BD relacional, sistemas com camadas de infraestrutura separáveis

ESTRATÉGIA
Refactor

Re-arquitetura: redesenhar para cloud-native

Maior esforço | Maior retorno

Reescreve partes significativas da aplicação para aproveitar elasticidade real: containers, serverless, microserviços, auto-scaling. É o caminho que permite pagar apenas pelo uso real em vez de pela capacidade reservada. Exige acesso ao código e time de engenharia disponível, mas entrega o maior retorno financeiro a longo prazo.

Indicado para: APIs com tráfego variável, e-commerce com sazonalidade, sistemas com picos definidos, aplicações em desenvolvimento ativo

ESTRATÉGIA
Repurchase

Trocar por SaaS: substituir o sistema por solução na nuvem

Zero infra gerenciada

Em vez de migrar o sistema on-premises, substituir por uma solução SaaS equivalente. CRM self-hosted vira Salesforce. Servidor de e-mail vira Google Workspace. ERP legado vira solução cloud-native. Elimina toda a infraestrutura associada e transfere a gestão para o fornecedor do SaaS.

Indicado para: CRM, e-mail, ERP para empresas menores, ferramentas de colaboração, helpdesk

ESTRATÉGIA
Retire

Descomissionar: desligar o que não é mais necessário

Economia imediata e total

Em média, 10% a 20% do portfólio de aplicações on-premises pode ser descomissionado antes ou durante a migração — sistemas que ninguém usa mas que continuam rodando porque “sempre estiveram lá”. Cada sistema que vai para Retire é um custo que desaparece 100%, sem migração e sem operação futura.

Indicado para: sistemas sem usuários ativos, relatórios substituídos por outras ferramentas, ambientes de teste permanentes

ESTRATÉGIA
Retain

Manter on-premises: nem tudo precisa ir para a nuvem

Decisão consciente, não omissão

Alguns workloads têm melhor TCO on-premises: sistemas com requisitos regulatórios de residência de dados, workloads com uso constante de 80% a 100% onde Reserved Instances não superam o custo de hardware dedicado, e sistemas com latência crítica para hardware local.

Indicado para: dados com requisito legal de soberania, workloads de alta intensidade constante, sistemas com latência crítica

Como diagnosticar o superdimensionamento por provedor

Todos os grandes provedores oferecem ferramentas nativas que identificam automaticamente instâncias superdimensionadas com base em dados históricos reais de CPU e memória. São gratuitas e o diagnóstico leva menos de 1 hora para ter o primeiro relatório.

Provedor	Ferramenta de diagnóstico	O que entrega	Como acessar
AWS	Trusted Advisor + Compute Optimizer	Lista de instâncias com CPU média abaixo de 20% por 7+ dias; recomendações de instância de destino com estimativa de economia; análise de memória (Compute Optimizer com agente instalado)	Console AWS > Trusted Advisor > Cost Optimization; ou AWS Compute Optimizer no console
Azure	Azure Advisor (Cost recommendations)	Recomendações de redimensionamento de VMs com estimativa de economia mensal; identificação de discos não utilizados; análise de reservas subutilizadas	Portal Azure > Advisor > Cost. Gratuito, atualizado diariamente com dados de 7 dias
GCP	Recommender + Active Assist	Recomendações proativas de rightsizing com impacto financeiro estimado; sugestões de Committed Use Discounts; alertas de VMs sem carga por 30+ dias	Console GCP > Recommender. API disponível para automação de recomendações via scripts

Como corrigir: o plano de otimização pós-migração

A otimização pós-migração não exige refazer a migração do zero. Existe uma sequência de ações com esforço crescente e retorno crescente que pode ser executada em paralelo com a operação normal, sem downtime planejado.

Comparativo: onde a empresa estava, onde está e onde pode chegar

Cenário	Custo mensal	O que determina o custo	Prazo para atingir
On-premises (antes)	Referência	Depreciação de hardware, energia, espaço físico, licenças de datacenter. Custo fixo independente de uso.	Situação atual (pré-migração)
Lift-and-shift (agora)	+20% a +50%	Instâncias superdimensionadas on-demand + custos ocultos (egress, IOF, suporte). Sem elasticidade, sem desconto de prazo.	Situação atual pós-migração
Após otimização (meta)	-20% a -50%	Instâncias rightsizadas + Reserved/Spot para cargas adequadas + sem recursos órfãos + lifecycle policies. Com elasticidade real.	90 dias após início da otimização

Percentuais em relação ao custo on-premises original. “Após otimização” inclui rightsizing, Reserved Instances para instâncias estáveis e eliminação de recursos órfãos, mas não refatoração para cloud-native (que gera economias adicionais).

Semanas 1 a 2: diagnóstico e limpeza imediata

Redução imediata de 10% a 15%

Rodar o diagnóstico das ferramentas nativas (Trusted Advisor, Azure Advisor, GCP Recommender). Identificar e desligar instâncias com zero uso por 14+ dias. Implementar schedule de shutdown para ambientes de dev fora do horário comercial. Cancelar IPs elásticos e discos não associados a instâncias.

Semanas 3 a 6: rightsizing das instâncias superdimensionadas

Redução adicional de 20% a 40%

Com base nos relatórios das ferramentas nativas, identificar instâncias com CPU abaixo de 20% por 7+ dias. Testar a instância menor em staging por 48h. Migrar em produção com monitoramento ativo por 7 dias. Não fazer todas de uma vez: lotes de 5 a 10 instâncias, validando performance antes de avançar.

Mês 2 a 3: Reserved Instances para infraestrutura estável

Redução adicional de 30% a 60% nas instâncias migradas

Com 60 dias de dados históricos após o rightsizing, identificar instâncias que rodam mais de 60% do tempo de forma contínua. Migrar para Reserved Instances de 1 ano (desconto de 30% a 40%) ou Savings Plans. Não reservar instâncias que ainda estão em fase de rightsizing — esperar a estabilização do uso antes de comprometer o prazo.

Mês 3 em diante: replatforming seletivo por workload

Esforço maior | Retorno de 40% a 70%

Para workloads onde o rightsizing não é suficiente (APIs com tráfego variável, sistemas de processamento batch, bancos de dados self-managed), avaliar replatforming para serviços gerenciados. A regra de decisão: se o custo de replatforming (esforço de engenharia) se paga em menos de 12 meses de economia operacional, o replatforming compensa.

Quando considerar repatriar: cloud nem sempre é a resposta certa

A repatriação (mover workloads de volta para on-premises ou para servidor dedicado) ganhou força como estratégia legítima em 2026. Não é sinal de falha: é uma decisão de TCO.

Situação	Repatriar?	Análise
Workload com uso constante de 80%+ e sem picos	Avaliar	Workloads sem picos não se beneficiam da elasticidade cloud. Se a Reserved Instance de 3 anos ainda custa mais que servidor dedicado equivalente, repatriar pode ser a decisão certa de TCO.
Dado com requisito legal de soberania local	Sim (parcial)	Dados com requisito de soberania (setor financeiro regulado, saúde, governo) podem precisar permanecer em infraestrutura local ou em cloud com região brasileira configurada. Verificar compliance antes de mover.
Latência crítica impossível de atingir em cloud pública	Sim	Sistemas de trading de alta frequência, controle industrial em tempo real ou sistemas com requisito de latência abaixo de 1ms geralmente precisam de hardware dedicado próximo ao ponto de processamento.
Custo cloud 3x maior que on-premises equivalente mesmo após otimização	Avaliar	Se após rightsizing e Reserved Instances o custo cloud ainda supera significativamente o on-premises para o mesmo workload, calcular o custo de repatriação vs. a economia anual. Se o payback for inferior a 18 meses, repatriar pode ser a decisão financeiramente correta.

Próximo Passo

Sua empresa migrou para a nuvem e a fatura ficou acima do esperado?

A Mobit realiza o assessment completo do ambiente cloud pós-migração: identifica instâncias superdimensionadas, recursos órfãos, oportunidades de Reserved Instances e workloads candidatos a replatforming. Em 90 dias, a fatura pode reduzir entre 20% e 50%. Diagnóstico gratuito e sem compromisso.

Quero reduzir o custo da minha migração →

Diagnóstico gratuito. A Mobit só recebe quando a economia aparecer na fatura.

Perguntas frequentes sobre migração cloud e superdimensionamento

Por que o custo de cloud ficou maior do que no datacenter após a migração? ▼

O custo de cloud costuma ficar maior após migração lift-and-shift por três razões principais. A primeira é o superdimensionamento herdado: servidores on-premises são provisionados para o pico de uso mas têm custo fixo, enquanto na nuvem cada GB de RAM e vCPU parada é cobrado por hora. A segunda são os custos ocultos não incluídos no TCO inicial: egress fees (saída de dados da nuvem), IOF de 6,38% sobre pagamentos internacionais com cartão, suporte premium do provedor e relicenciamento de software. A terceira é a arquitetura monolítica que não aproveita a elasticidade cloud: a instância precisa ficar ligada no tamanho do pico mesmo quando o tráfego é baixo. A combinação dessas três razões pode deixar o custo de cloud 20% a 50% acima do on-premises anterior. A correção existe e não exige refazer a migração: rightsizing, Reserved Instances e eliminação de recursos órfãos reduzem a fatura em 20% a 50% nos primeiros 90 dias.

O que é lift-and-shift e por que é problemático? ▼

Lift-and-shift (ou Rehosting) é a estratégia de migração que replica a infraestrutura on-premises para o ambiente cloud sem alterações de arquitetura: cada servidor físico vira uma instância de VM com as mesmas especificações. É a abordagem mais rápida para sair do datacenter, mas frequentemente a mais cara de operar no longo prazo. O problema estrutural é que o hardware on-premises geralmente está superdimensionado — 30% a 50% de CPU e memória ficam ociosas na maior parte do tempo, porque o servidor foi dimensionado para o pico e tem custo fixo. Na nuvem, esse mesmo superdimensionamento gera custo variável por hora: a empresa paga por toda a capacidade ociosa a cada hora que passa. Estudos da AWS mostram que até 40% das instâncias EC2 estão superdimensionadas em ambientes que migraram via lift-and-shift. Isso não significa que o lift-and-shift é sempre errado: para sistemas legados sem acesso ao código-fonte, é frequentemente a única opção. O problema é quando é usado para toda a infraestrutura sem avaliação workload a workload.

Como reduzir o custo de cloud depois da migração sem refazer tudo? ▼

Reduzir o custo de cloud pós-migração não exige refazer a migração do zero. O plano de otimização tem quatro etapas com esforço crescente. Primeiro, nas semanas 1 e 2: diagnóstico via ferramentas nativas (AWS Trusted Advisor, Azure Advisor, GCP Recommender), eliminação de recursos órfãos e schedule de shutdown para ambientes de dev — resultado de 10% a 15% de redução. Segundo, nas semanas 3 a 6: rightsizing das instâncias com CPU abaixo de 20% por 7+ dias, testado em staging antes de produção — resultado adicional de 20% a 40%. Terceiro, no mês 2 a 3: migração de instâncias estáveis para Reserved Instances ou Savings Plans de 1 ano com desconto de 30% a 40% — resultado adicional de 30% a 60% sobre essas instâncias. Quarto, a partir do mês 3: replatforming seletivo de workloads onde faz sentido (banco self-managed para PaaS, APIs para serverless). O resultado consolidado em 90 dias para ambientes sem histórico de otimização é de 20% a 50% de redução na fatura total.

O que são os 6 Rs da migração cloud? ▼

Os 6 Rs da migração cloud (framework popularizado pela AWS) são as seis estratégias possíveis para cada workload em um projeto de migração. Rehost (lift-and-shift): mover a VM como está, sem alterações. Mais rápido, mas não otimiza para cloud. Replatform: mover com ajustes de plataforma, substituindo componentes por serviços gerenciados (banco self-managed para RDS, por exemplo), sem reescrever código. Refactor: redesenhar a aplicação para cloud-native com containers, serverless ou microserviços. Maior esforço, maior retorno. Repurchase: substituir o sistema por uma solução SaaS equivalente (CRM on-premises para Salesforce, servidor de e-mail para Google Workspace). Retire: descomissionar sistemas que não têm usuários ativos — em média, 10% a 20% do portfólio pode ser aposentado. Retain: manter on-premises por questões regulatórias, técnicas ou de TCO. A escolha errada do R para cada workload é a causa mais comum de fatura de cloud acima do esperado após a migração.