Migração de AWS para Contabo: guia de otimização de custos 2026

A sua fatura da AWS no final do mês faz ranger os dentes. €187/mês por uma stack Node.js + Postgres 40 GB + 30 GB de objetos estáticos, dos quais 60% vão para RDS e NAT Gateway. Sabe que há algo mais barato, mas hesita em abandonar o conforto do EC2 e a magia do S3. Este guia descreve um cenário representativo de migração da AWS para a Contabo: da AWS para um único VPS da Contabo a €5,50/mês, cerca de 80-85% de poupança ao longo de 12 meses consoante a stack, sem perda significativa de funcionalidades para uma carga comparável de pequena a média dimensão.

Por que sair da AWS em 2026

Três razões cumulativas convergem em 2026 e tornam a conversa sobre migração mais madura do que nunca.

A primeira razão ainda é o custo bruto. A AWS escala brutalmente com o tráfego de saída cobrado a $0,09/GB acima de 100 GB por mês, NAT Gateways cobrados a $45/mês apenas para existir antes de contar o tráfego, snapshots RDS que se acumulam silenciosamente a $0,095/GB-mês sem alarme padrão, e serviços geridos como Lambda cuja cobrança por invocação se traduz em faturas mensais imprevisíveis. Um projeto que começa a $30/mês rotineiramente acaba em $200-400/mês em 18 meses sem mudança visível de funcionalidades. No perfil representativo descrito neste guia, a fatura da AWS atinge cerca de €187/mês por uma stack que poderia funcionar num único VPS de €5,50/mês - uma ordem de grandeza mais caro para um serviço entregue idêntico.

A segunda razão é a soberania legal. Mesmo em eu-central-1 (Frankfurt), a AWS continua a ser uma entidade dos EUA vinculada pelo CLOUD Act, o que significa que um juiz federal dos EUA pode obrigar o acesso a dados armazenados na Europa sem que o utilizador final ou a empresa cliente sejam notificados. Para dados de clientes RGPD, isso é um risco legal formalizado pelas recomendações do EDPB de 2020 pós-Schrems II. As primeiras disputas civis baseadas neste risco começaram a surgir em 2024-2025 com o caso Mediawan / Microsoft Azure, que custou vários milhões em honorários legais e redirecionamento de infraestrutura de emergência.

A terceira razão é o bloqueio técnico. IAM, KMS, VPC, Application Load Balancer, Lambda - cada serviço da AWS amarra-o um pouco mais à plataforma. Após dois anos, "apenas mover" leva no mínimo 3 semanas de esforço cumulativo. Quanto mais tempo esperar para sair, mais cara se torna a migração para projetar e, portanto, para fazer, o que cria um ciclo de procrastinação onde continua a pagar à AWS sem nunca tomar a decisão. O limiar psicológico de migração é geralmente em torno do mês 6 ou 12 de uso ativo, após o qual o custo de inércia organizacional se torna proibitivo.

Além destes três fatores estruturantes, três gatilhos operacionais impulsionam uma organização para uma migração concreta: uma mudança de CIO ou CTO que traz uma nova perspetiva sobre a fatura da cloud; uma auditoria de RGPD ou conformidade que aponta o uso da AWS dos EUA como não conforme com a política interna de soberania; ou um grande incidente técnico da AWS (falha em us-east-1 propagada mundialmente como em dezembro de 2024) que lembra que a dependência de um único fornecedor tem um custo de oportunidade real.

A Contabo não é mágica: é um fornecedor alemão de VPS de baixo custo que lhe entrega uma caixa Ubuntu e deixa-o fazer o resto. Mas para 80% das cargas de trabalho de PMEs e SaaS solo, é mais do que suficiente - e 5 a 10× mais barato.

Quando a migração compensa (e quando não compensa)

Seja honesto consigo mesmo. AWS → Contabo faz sentido se:

• Tem um ou dois serviços para hospedar (API + BD + objetos), não uma arquitetura de microsserviços com 30 contêineres.
• O seu tráfego é previsível (sem picos de 100×). A Contabo não tem auto-escalonamento.
• Aceita tornar-se o administrador: apt, systemctl, ufw, backups manuais.
• Os seus dados não toleram o CLOUD Act, ou a sua fatura da AWS ultrapassa €100/mês.

Por outro lado, permaneça na AWS se:

• Usa intensivamente Lambda, Cognito, SageMaker, SQS gerido. Custo de migração > custo AWS.
• Tem um SLA de cliente que exige 99,99% (Contabo é 99,9%, ou seja, ~8h de inatividade/ano).
• Lida com dezenas de TB de saída e o seu tráfego de saída sustentado é alto o suficiente para atingir o limite fair-use da Contabo (tráfego "ilimitado" mas sujeito a uma política de fair-use).

Um caso típico para esta migração: um único backend Node.js + Postgres + objetos estáticos, com todas as caixas acima marcadas.

Auditar o custo atual da AWS (método Cost Explorer)

Antes de migrar, meça. Sem uma linha de base, não há ROI.

1. Vá para AWS Cost Explorer → Relatórios → Relatórios de Custo e Uso.
2. Filtre os últimos 3 meses, granularidade mensal, agrupado por Serviço.
3. Exporte como CSV. Abra numa folha de cálculo. Normalmente obtém:

Anualizado: €1.884. Note o detalhe: neste perfil, NAT Gateway + Transferência de Dados = €59/mês, ou 38% da fatura apenas para empurrar bytes para dentro e para fora. Esse é o ponto cego clássico.

Configurar o VPS alvo da Contabo

Para esta stack, escolhemos um Cloud VPS 10 da Contabo: 4 vCPU, 8 GB RAM, 75 GB NVMe, tráfego ilimitado (política fair-use). €5,50/mês com um compromisso de 12 meses. Se a sua base de dados mais os objetos ultrapassarem ~60 GB, suba para um Cloud VPS 20 ou 30 para o NVMe adicional.

Provisionamento:

# Assim que o VPS for entregue (email da Contabo com IP + senha root)
ssh root@YOUR_IP

# Endurecimento mínimo
adduser ericg
usermod -aG sudo ericg
mkdir -p /home/ericg/.ssh
nano /home/ericg/.ssh/authorized_keys   # cole a sua chave SSH
chmod 700 /home/ericg/.ssh && chmod 600 /home/ericg/.ssh/authorized_keys
chown -R ericg:ericg /home/ericg/.ssh

sed -i 's/^PermitRootLogin .*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

apt update && apt upgrade -y
apt install -y ufw fail2ban
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable
systemctl enable --now fail2ban

Detalhes completos de endurecimento (Lynis, snapshots Contabo, journald) estão no guia de auto-hospedagem WireGuard. As mesmas bases aplicam-se aqui.

Migração Postgres RDS → Postgres auto-hospedado (pg_dump passo a passo)

Esta é a peça mais crítica. Procedimento testado em batalha:

Passo 1 - Instalar Postgres 15 na Contabo

sudo apt install -y postgresql-15 postgresql-contrib-15
sudo systemctl enable --now postgresql

# Criar utilizador e BD da aplicação
sudo -u postgres psql <<EOF
CREATE USER appuser WITH PASSWORD 'PASTE_A_STRONG_PASSWORD';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
EOF

Ativar SSL e permitir conexões remotas apenas da sua aplicação (ou apenas local se o Postgres estiver na mesma máquina que a API - recomendado):

sudo nano /etc/postgresql/15/main/postgresql.conf
# ssl = on
# listen_addresses = 'localhost'  (ou '*' se a aplicação estiver noutra VPS)

sudo nano /etc/postgresql/15/main/pg_hba.conf
# Adicionar: hostssl appdb appuser YOUR_APP_IP/32 scram-sha-256

sudo systemctl restart postgresql

Passo 2 - Dump do RDS

Do seu posto de trabalho, com acesso ao RDS:

pg_dump \
  -h your-rds.eu-central-1.rds.amazonaws.com \
  -U masteruser \
  -d appdb \
  -Fc \
  -f appdb.dump

# Formato personalizado (-Fc) = comprimido + paralelizável na restauração

Para uma base de dados de 40 GB, espere 10-20 min dependendo da classe RDS e largura de banda.

Passo 3 - Transferir e restaurar

scp appdb.dump ericg@YOUR_CONTABO_IP:/tmp/
ssh ericg@YOUR_CONTABO_IP

sudo -u postgres pg_restore \
  -d appdb \
  -j 4 \
  --no-owner \
  --role=appuser \
  /tmp/appdb.dump

# Verificar
sudo -u postgres psql -d appdb -c "SELECT count(*) FROM users;"

Verifique a integridade comparando count(*) de tabelas grandes entre RDS e Contabo. Diferença = 0.

Passo 4 - Backups automatizados pós-migração

Substitua os backups automatizados do RDS por um simples cron:

sudo nano /usr/local/bin/pg-backup.sh

#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
sudo -u postgres pg_dump -Fc appdb > /var/backups/postgres/appdb-$DATE.dump
find /var/backups/postgres -name "appdb-*.dump" -mtime +14 -delete
# Enviar para MinIO ou S3 externo para off-site
rclone copy /var/backups/postgres/appdb-$DATE.dump remote:backups/postgres/

Cron diário às 3 AM: 0 3 * * * /usr/local/bin/pg-backup.sh.

Migração S3 → MinIO (rclone, compatibilidade aws-cli)

MinIO é um armazenamento de objetos open-source, baseado em Go, 100% compatível com a API S3. Instalação direta:

wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
sudo mv minio /usr/local/bin/

sudo mkdir -p /data/minio
sudo useradd -r minio-user -s /sbin/nologin
sudo chown minio-user:minio-user /data/minio

sudo nano /etc/default/minio

MINIO_VOLUMES="/data/minio"
MINIO_OPTS="--console-address :9001 --address :9000"
MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=PASTE_A_STRONG_32_CHAR_PASSWORD

unidade systemd: obtenha o .service oficial (documentação MinIO) e systemctl enable --now minio.

Migre objetos do S3 usando rclone:

sudo apt install -y rclone

rclone config
# n) Novo remoto → nome: aws / s3 / AWS / cole access_key + secret_key
# n) Novo remoto → nome: minio / s3 / Outro / endpoint http://localhost:9000 / cole admin + senha

# Bucket-para-bucket
rclone copy aws:my-prod-bucket minio:my-prod-bucket --transfers=8 --progress

Para 30 GB: orçamente 30-60 min dependendo da largura de banda de saída da AWS (o que lhe custará alguns euros na transferência final - esse é o pedágio de saída).

Do lado da aplicação, nenhuma alteração de código: o seu aws-sdk-js continua a funcionar, apenas aponta para o endpoint MinIO:

const s3 = new S3Client({
  endpoint: 'https://storage.yourdomain.com',
  region: 'us-east-1',           // valor arbitrário necessário
  credentials: { accessKeyId, secretAccessKey },
  forcePathStyle: true,          // importante para MinIO
});

Mudança de DNS sem tempo de inatividade

O método limpo, planeado ao longo de 10 dias:

• D-10: implemente a stack completa na Contabo, execute testes internos via substituição de /etc/hosts.
• D-7: reduza o TTL dos registros A no Route 53 de 3600 → 60 segundos. Deixe propagar 48h.
• D-3: congelamento de funcionalidades, último pg_dump incremental, última rclone sync de objetos.
• D-1: mudança em horário de pico baixo (tipicamente 3 AM UTC para um público da UE). Altere o registro A: IP antigo da AWS → novo IP da Contabo. Propagação máx 60s.
• D+0 → D+2: monitorização agressiva (latência, erros 5xx, métricas de BD). Mantenha a AWS em funcionamento "apenas por precaução".
• D+7: limpe a AWS (termine EC2, elimine RDS após snapshot final exportado, elimine bucket S3 após backup off-site).

Zero tempo de inatividade perceptível para o utilizador se o Postgres estiver sincronizado (uma pausa de 5 minutos em modo apenas leitura é suficiente para enviar o delta final).

Quer um VPS da Contabo para iniciar a sua migração? Contabo Cloud VPS 10, termo de 12 meses - €5,50/mês

Estimativa de ROI (tabela de custos antes/depois ao longo de 12 meses)

Uma comparação representativa antes/depois baseada nos preços publicados de cada fornecedor:

Poupança: €1.597,20/ano, ou cerca de 85% neste perfil representativo. A figura exata depende da sua stack, mas para uma carga de trabalho pequena a média comparável, poupanças na faixa de 75-85% são típicas. O retorno é rápido: sem custo significativo de migração (cerca de um dia de trabalho).

O que perde em relação à AWS (serviços geridos)

Sem marketing, vamos ser claros sobre as perdas:

• RDS Multi-AZ auto-failover: na AWS, se o primário falhar, o secundário assume em 60-120s. Auto-hospedado na Contabo, precisaria de um segundo VPS + replicação em streaming + Patroni. Viável, mas adiciona tempo de operações.
• 11 noves de durabilidade do S3: a Amazon garante 99,999999999% de durabilidade por objeto (replicação interna em 3-AZ). MinIO num único disco = a durabilidade do seu disco NVMe. Solução: backups regulares para Wasabi ou Backblaze B2 (€1-3/mês para este dataset off-site).
• IAM granular: substituído por utilizadores Linux + sudoers + políticas MinIO. Menos granular, mais simples de gerir.
• CloudWatch unificado: substitua por Prometheus + Grafana, ou Netdata (configuração de 15 min), ou um SaaS externo (Better Stack, Sentry).
• Suporte 24/7 empresarial: a Contabo oferece suporte por email, não o nível empresarial 24/7 que a AWS vende. Para operações críticas, planeie um runbook + um segundo administrador de plantão.

Orçamente 3 a 5 horas de operações por mês em estado estável: atualizações do Ubuntu, verificações de backup, alertas de monitorização. Esse é o verdadeiro custo oculto - não insuperável, mas real.

Leia a seguir

• Auto-hospedar VPN na Contabo: guia completo WireGuard 2026
• Alojamento em nuvem RGPD: alternativas à AWS na Europa 2026
• Contabo vs Hetzner vs OVH: VPS na Europa para VPN auto-hospedada 2026
• Fontes oficiais: documentação MinIO, replicação em streaming do PostgreSQL, guia AWS Cost Explorer, recomendações EDPB Schrems II

Artigo publicado em 2026-06-02. Estimativa de ROI baseada nos preços publicados da AWS e Contabo. Divulgação de afiliados: se adquirir um VPS da Contabo através dos links neste artigo, ganhamos uma comissão sem custo adicional para si. As nossas recomendações são baseadas nas especificações e preços publicados.