Por que sua conta de nuvem está cara — e quando trocar de stack não resolve

A conversa sobre custo de nuvem quase sempre começa errada, no preço do fornecedor. Só que a fatura raramente está alta porque o vCPU da AWS custa mais que o do concorrente. Ela está alta porque o desenho do sistema paga por recurso que ninguém usa — e trocar de fornecedor leva o desperdício junto.

Este artigo separa as duas coisas: onde o dinheiro vaza de fato, e em que ponto migrar para stack open-source auto-hospedada passa a compensar. A resposta para a segunda pergunta não é "sempre". Em boa parte das PMEs, é "nunca" — e a conta que mostra isso está mais abaixo.

1. De onde vem a fatura, na ordem real

Em auditorias de custo, quatro causas explicam a maior parte do excedente, quase sempre nesta ordem de impacto:

1. Recurso ocioso. Ambiente de homologação ligado 24×7 para ser usado 6h por dia útil. Você paga 168 horas por semana e consome 30.
2. Superdimensionamento. A instância foi escolhida no pico de lançamento e nunca mais revista. É comum achar banco em máquina com 8 vCPU operando a 7% de média.
3. Transferência de dados (egress). A linha que ninguém projeta. Backup entre regiões, mídia servida direto do bucket sem CDN, réplica conversando por rede pública.
4. PaaS por conveniência, não por decisão. Fila gerenciada, cache gerenciado, busca gerenciada — cada um resolvendo algo que um único PostgreSQL já resolveria naquele volume.

2. O erro que infla toda promessa de economia

A comparação que circula em post de LinkedIn é sempre esta: "banco gerenciado custa R$ 6.000/mês, uma VM com PostgreSQL custa R$ 900 — economia de 85%".

O número está errado porque falta o termo mais caro: a hora de engenharia. Auto-hospedar transfere para o seu time o patch de segurança, o monitoramento, o ajuste de parâmetros, o teste de restore — e o plantão quando o disco enche às 3h da manhã. Isso tem custo recorrente, e tem custo único de migração.

O modelo abaixo é o que usamos antes de recomendar qualquer troca. Ele responde a uma pergunta só: em que mês a operação auto-hospedada fica mais barata que o PaaS, considerando o trabalho humano?

from dataclasses import dataclass


@dataclass
class Cenario:
    """Custos de um mesmo serviço nas duas formas de operar."""
    paas_mensal: float        # fatura do serviço gerenciado
    infra_mensal: float       # VM/storage/backup do equivalente auto-hospedado
    horas_operacao_mes: float # patch, monitoramento, restore testado
    horas_migracao: float     # esforço único de saída
    valor_hora: float         # custo real da hora de engenharia


def custo_paas(c: Cenario, meses: int) -> float:
    return c.paas_mensal * meses


def custo_autogerido(c: Cenario, meses: int) -> float:
    unico = c.horas_migracao * c.valor_hora
    recorrente = (c.infra_mensal + c.horas_operacao_mes * c.valor_hora) * meses
    return unico + recorrente


def break_even(c: Cenario, horizonte: int = 60) -> int | None:
    """Primeiro mês em que auto-hospedar fica mais barato. None = nunca paga."""
    for m in range(1, horizonte + 1):
        if custo_autogerido(c, m) < custo_paas(c, m):
            return m
    return None

Rodando com dois perfis reais de cliente — uma PME e uma operação de porte médio, ambas a R$ 120 a hora de engenharia:

PME   break-even: NUNCA
       12m  PaaS R$     5.400 | auto R$    12.720 | +136%
       36m  PaaS R$    16.200 | auto R$    28.560 | +76%

MEDIA break-even: 3
       12m  PaaS R$    74.400 | auto R$    31.920 | -57%
       36m  PaaS R$   223.200 | auto R$    76.560 | -66%

Os dois cenários usam exatamente o mesmo modelo. O que muda é a escala — e o resultado inverte de sinal. Na PME, sair do gerenciado mais que dobra o custo de 12 meses, porque 4 horas mensais de operação a R$ 120 já custam mais que a fatura inteira do PaaS. Na operação média, o mesmo movimento se paga em 3 meses e devolve 66% em 3 anos.

3. A ordem correta das alavancas

Atacar na ordem errada custa caro e rende pouco. A sequência que aplicamos:

1. Medir antes de tocar. Sem alocação de custo por recurso e por ambiente, qualquer corte é chute. Primeiro etiquetar, depois decidir.
2. Desligar o ocioso. Agendamento de homologação, remoção de volume órfão, snapshot antigo, IP reservado sem uso. Retorno alto, risco quase zero.
3. Redimensionar. Ajustar instância ao uso real observado por 30 dias, não ao pico histórico. Ainda sem trocar tecnologia.
4. Só então reavaliar o stack. E apenas onde o break-even fecha, serviço a serviço — nunca como migração de tudo de uma vez.

Os passos 2 e 3 costumam entregar a maior parte da economia possível sem alterar uma linha de código. É por isso que começamos por eles.

4. O que geralmente não vale auto-hospedar

Mesmo em escala, alguns serviços raramente compensam sair do gerenciado, porque a operação é desproporcional ao valor:

• Autenticação e gestão de identidade. Errar aqui é incidente de segurança, não linha de custo.
• Entrega de e-mail transacional. Reputação de IP não se compra com VM.
• Banco primário sem alguém de plantão. Auto-hospedar exige que exista quem atenda. Se não existe, o custo aparece como indisponibilidade, e ela é mais cara que a fatura.
• CDN. A economia de egress vem justamente de usá-la.

Onde a troca costuma fechar em escala: banco relacional, armazenamento de objetos (MinIO no lugar de S3), fila (RabbitMQ), cache (Redis) e observabilidade (Grafana). São componentes maduros, com operação previsível — o que torna a estimativa de horas confiável em vez de otimista.

5. O resumo

Esse critério é o mesmo que descrevemos em como escolhemos ferramentas: nada novo entra sem comparação documentada de custo total.