Migração EC2 → Proxmox: plano cloud → on-prem com custo ~94% menor projetado

TL;DR

• Workloads internas previsíveis em AWS EC2 migradas para cluster Proxmox gerenciado on-prem.
• Custo mensal por VM cai de R$ 175-205 (EC2 t3.small) para cerca de R$ 10 em alocação Proxmox — diferencial projetado de ~94%.
• Trade-off custo × elasticidade registrado em ADR; cutover por workload com janela anunciada, sem surpresa pro cliente.

Contexto

A consultoria mantinha workloads internas hospedadas em AWS EC2 — serviços long-running com perfil de uso estável: CPU média baixa, pico previsível, zero necessidade real de auto-scaling agressivo. A fatura mensal refletia o preço da possibilidade de elasticidade, não do uso que efetivamente acontecia.

Em paralelo, o time já operava um cluster Proxmox VE em provedor europeu de Proxmox gerenciado, com capacidade ociosa suficiente para absorver essas cargas. A pergunta não era “dá pra rodar isso em Proxmox” — dava. Era “vale o risco de uma migração stateful pra colher a economia?”.

Risco real existia: volumes persistentes (bancos pequenos, configs de aplicação, certificados), dependências de DNS apontando pra IPs EC2, e um time pequeno sem janela de “manutenção programada” recorrente com o cliente interno.

Ação

A entrega foi um plano de migração faseado, não um lift-and-shift de fim de semana. Quatro frentes:

Inventário de workloads

Antes de decidir migrar qualquer coisa, catalogar tudo que estava em EC2: tipo de instância, storage anexado, serviços rodando, dependências externas (quem chama, quem é chamado), janela de uso real e criticidade.

O critério de corte para esta fase da migração: apenas workloads de perfil previsível (sem burst real, sem dependência crítica cruzando zona de AWS) entraram no escopo. Serviços que de fato exerciam elasticidade ou dependiam de serviços gerenciados AWS (RDS, SQS, IAM) ficaram fora — o ganho de custo não justificava o re-desenho de arquitetura.

Spec Proxmox por VM

Para cada workload aprovada, uma especificação Proxmox equivalente:

• vCPU e RAM dimensionadas pelo uso real observado em EC2 (não pelo tamanho nominal da instância — quase sempre superdimensionado).
• Storage em disco local Proxmox com snapshot habilitado.
• Rede segmentada por VLAN, acesso SSH por bastion, sem expor IP público direto.
• Hostname genérico, documentação de “o que essa VM faz e quem depende dela” num README no próprio host.

# check-workload.sh — trecho ilustrativo, anonimizado
# Coletar uso real em EC2 antes de dimensionar a VM Proxmox equivalente
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value="$INSTANCE_ID" \
  --start-time "$(date -u -d '30 days ago' +%FT%TZ)" \
  --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --statistics Average,Maximum \
  --query 'Datapoints | sort_by(@, &Timestamp)'

Ensaio em VM limpa + cutover

Nenhuma migração foi pro DNS oficial sem ensaio. Cada workload passou por:

1. Provisionamento da VM Proxmox com spec definida.
2. Restore do estado (rsync de volumes, import de banco) em VM limpa, com serviço subindo em hostname de staging.
3. Checklist pós-restore rodado antes do cutover: serviço responde, logs sem erro persistente, dependentes conseguem alcançar, backup do próprio Proxmox configurado.
4. Cutover controlado por DNS: TTL reduzido com antecedência, janela anunciada ao consumidor interno, rollback documentado (voltar DNS pra EC2 enquanto a instância antiga não fosse terminada).

O EC2 original só era desligado, e só depois terminado, após um período de observação pós-cutover em que os consumidores validavam funcionamento real — não “só ping”.

Trade-offs e o que NÃO fiz

• On-prem em vez de EC2 (ADR custo × elasticidade): a escolha explícita foi trocar elasticidade por custo. Proxmox alocação mensal por VM fica próxima de R$ 10/mês; EC2 t3.small + EBS equivalente orçou entre R$ 175 e R$ 205/mês. Para workload com uso real previsível, pagar ~17× a mais por elasticidade não exercida não se sustenta. O trade-off foi escrito, não implícito: se o padrão de uso mudar (pico real, necessidade de escalar pra N instâncias), volta pra cloud é a resposta — a decisão não é religião, é cálculo revisável.
• Não migrei workloads que de fato usavam elasticidade nem as que dependiam de serviços gerenciados AWS (banco gerenciado, filas, IAM cruzado). O ganho não justificava redesenhar arquitetura.
• Não automatizei com Terraform/Ansible: para um lote pequeno e não recorrente, IaC traria custo de manutenção maior que o ganho. Se a migração virar padrão repetível (mais workloads entrando no pipeline), aí sim faria sentido investir em IaC — hoje não faz.
• Não prometi “zero downtime”: cada workload teve janela de cutover planejada e anunciada. Fingir migração invisível em time pequeno é como inventar SLA — só quebra confiança quando falha.
• Não fiz benchmark comparativo de performance em profundidade: o perfil era IO-leve e CPU-baixo, e o Proxmox estava claramente superdimensionado pras cargas. Gastar dias em microbenchmark teria sido teatro.

Resultado

O resultado em números duros é honestamente parcial: o número total de workloads migradas, a economia consolidada mensal e o downtime efetivo por cutover não estão publicáveis aqui — parte por anonimização, parte porque a baseline financeira da unidade de negócio não é minha pra divulgar.

O que é publicável, e é o que importa pra um portfólio:

• A metodologia — inventário → spec → ensaio → cutover com rollback — sobreviveu ao primeiro workload migrado e se repetiu nos seguintes sem virar improviso.
• O diferencial de custo por VM é rastreável via preço público EC2 vs orçamento Proxmox documentado em ADR interna — ficou na faixa de ~94% em qualquer workload cuja utilização real coubesse num t3.small.
• O trade-off foi escrito, não herdado. Um sucessor que abra o ADR amanhã entende exatamente o que foi comprado (custo baixo) e o que foi abdicado (elasticidade elástica), com o gatilho pra reverter deixado explícito.

Onde o case não vai fingir: não há aqui gráfico de “economia acumulada no trimestre” nem “X VMs migradas em Y dias sem downtime”. A honestidade da descrição é parte do valor — uma migração stateful em time pequeno, com janela planejada e rollback desenhado, já é um resultado que muita área maior não entrega.