A nuvem pública resolve problemas reais: pico imprevisível, experimento que pode morrer no mês seguinte, serviço gerenciado que a equipe não teria como operar. A migração vira mau negócio quando ninguém mede a carga antes de decidir. O padrão dos casos que chegam até nós se repete: a fatura em dólar cresceu, ninguém consegue explicar cada linha dela, e a carga que está lá é exatamente a que menos se beneficia do modelo.
Três cenários concentram quase todos esses casos.
1. Carga estável, 24 horas por dia
O modelo de preço da nuvem embute elasticidade: você paga mais por hora justamente pela liberdade de desligar. Um sistema que roda o dia inteiro, todos os dias, com uso previsível, como o ERP, o banco do sistema de gestão ou o servidor de virtualização de um ISP, nunca usa essa liberdade, mas paga por ela todo mês.
A comparação honesta se faz em custo mensal total, no papel:
instância 8 vCPU / 32 GB, região São Paulo, 24/7:
sob demanda ≈ US$ 350–450/mês (computação apenas)
+ disco, IP, backup e egress conta final variável
servidor dedicado equivalente (8 núcleos / 64 GB / NVMe):
R$ fixo mensal, tráfego previsível, capacidade conhecida
Para carga estável, o dedicado costuma fechar em uma fração do custo, cobrado em reais e sem exposição cambial. Reserva de instância por 1 ou 3 anos estreita a diferença, mas aí a elasticidade, único argumento que restava, também já foi embora.
2. Tráfego de saída alto
O egress, cada gigabyte que sai da nuvem para a internet, é cobrado à parte, na faixa de US$ 0,09/GB nos grandes provedores. É a linha da fatura que mais surpreende, porque não existe no mundo do servidor próprio com porta contratada.
A conta para um serviço que transfere 20 TB por mês (um repositório de atualizações, um sistema com muitos downloads, um acervo de mídia):
20 TB/mês × US$ 0,09/GB ≈ US$ 1.840/mês só de saída de dados
≈ R$ 120 mil/ano ao câmbio de hoje
Uma porta de 1 Gbps em servidor dedicado ou colocation transfere isso com folga por custo fixo mensal muito menor. O egress também é o mecanismo que prende: sair da nuvem com 200 TB armazenados custa uma conta de cinco dígitos em dólar só para copiar os próprios dados. Por isso a conta de entrada precisa incluir o preço da porta de saída.
3. Usuários concentrados na sua região
De Campo Grande, a região de nuvem mais próxima fica em São Paulo: 15 a 25 ms de ida e volta, quando a rota está boa. Um servidor local responde abaixo de 5 ms. Para um site institucional a diferença é irrelevante. Para o sistema que o caixa da loja consulta a cada venda, para telefonia IP e para o portal que a prefeitura usa o dia inteiro, são milissegundos multiplicados por cada clique de cada funcionário, além de uma dependência nova de rota de longa distância no caminho crítico.
O que ainda assim pertence à nuvem
O critério é a conta, e a resposta certa é frequentemente híbrida. O ambiente de testes que vive desligado, a campanha com pico de 30 dias e o serviço gerenciado (fila, banco replicado multi-região) cuja operação própria custaria um salário de especialista continuam bons candidatos à nuvem. A carga estável, o tráfego pesado e o dado com exigência de localização rendem mais em servidor próprio ou dedicado.
Duas perguntas decidem a maioria dos casos. Qual é o custo mensal total de cada cenário, com egress e câmbio na conta? E qual é o custo de voltar atrás, medido antes de entrar? Quem responde às duas antes de assinar raramente se arrepende do caminho escolhido, seja ele qual for.
Se a sua fatura de nuvem cresce e ninguém sabe explicar por quê, uma medição de duas a quatro semanas responde: contato@castelapi.com.br.