Migración AWS → Contabo: guía de cost optimization 2026

Tu factura de AWS de fin de mes te hace rechinar los dientes. Cerca de 190 €/mes por un stack Node.js + Postgres 40 GB + 30 GB de objetos estáticos, del cual una gran parte se va en RDS y NAT Gateway. Sabes que existe algo más barato, pero dudas en abandonar la comodidad de EC2 y la magia de S3. Esta guía detalla la migración de un stack así a un único VPS Contabo a 5,50 €/mes, con un ahorro del orden del 75-85 % en 12 meses según los precios públicos, sin pérdida funcional significativa para este tipo de caso de uso.

Por qué dejar AWS en 2026

Tres razones acumulativas convergen en 2026 y hacen que la conversación de migración sea más madura de lo que nunca ha sido.

La primera razón sigue siendo el coste bruto. AWS escala brutalmente con el tráfico saliente facturado a 0,09 $/GB por encima de 100 GB por mes, los NAT Gateways facturados a 45 $ al mes solo por existir sin contar tráfico, los snapshots de RDS que se acumulan silenciosamente a 0,095 $/GB-mes sin alarma por defecto, y los servicios managed tipo Lambda cuya facturación por invocación se traduce en factura mensual imprevisible. Un proyecto que arranca a 30 $/mes termina con frecuencia a 200-400 $/mes en 18 meses sin ningún cambio de feature visible. En nuestro proyecto interno descrito en esta guía, la factura AWS había alcanzado los 187 €/mes para una stack que habría podido funcionar en un VPS único a 5,50 €/mes - es decir, un orden de magnitud más caro por un servicio prestado idéntico.

La segunda razón es la soberanía jurídica. Incluso en la región eu-central-1 en Frankfurt, AWS sigue siendo una entidad estadounidense sometida al CLOUD Act, lo que quiere decir que un juez federal de EE. UU. puede exigir acceso a datos almacenados en Europa sin que el usuario final o la empresa cliente sea notificado. Para datos de clientes GDPR, es un riesgo jurídico formalizado por las recomendaciones EDPB de 2020 post-Schrems II. Los primeros contenciosos civiles basados en este riesgo empezaron a emerger en 2024-2025 con el caso Mediawan / Microsoft Azure que costó varios millones en gastos de abogados y redirección de infraestructura de urgencia.

La tercera razón es el lock-in técnico. IAM, KMS, VPC, Application Load Balancer, Lambda - cada servicio AWS te ata un poco más a la plataforma. Al cabo de 2 años, «solo mudarse» tarda 3 semanas mínimo de esfuerzo acumulado. Cuanto más esperas para irte, más cara se vuelve la migración a proyectar y por tanto a hacer, lo que crea un bucle de procrastinación donde sigues pagando una renta a AWS sin tomar nunca la decisión. El umbral psicológico de migración se sitúa generalmente hacia el sexto o duodécimo mes de uso activo, después del cual el coste organizacional de inercia se vuelve prohibitivo.

Más allá de estos tres factores estructurantes, tres desencadenantes operativos hacen bascular a una organización hacia la migración concreta: un cambio de DSI o CTO que aporta una mirada nueva sobre la factura cloud; una auditoría GDPR o de conformidad que señala el uso de AWS US como no conforme a la política interna de soberanía; o un incidente técnico AWS mayor (caída us-east-1 propagada a nivel mundial como en diciembre 2024) que recuerda que la dependencia a un proveedor único tiene un coste de oportunidad real.

Contabo no es magia: es un proveedor alemán de VPS de gama baja que te entrega una máquina Ubuntu y te deja hacer el resto. Pero para el 80 % de las cargas SaaS de pymes y autónomos, es más que suficiente - y entre 5 y 10× más barato.

Casos donde la migración merece la pena (y donde no)

Sé honesto contigo mismo. La migración AWS → Contabo tiene sentido si:

• Tienes uno o dos servicios que hospedar (API + DB + objetos), no una arquitectura de 30 microservicios.
• Tu tráfico es predecible (sin picos 100× sobre la baseline). Contabo no tiene auto-scaling.
• Aceptas convertirte en admin: apt, systemctl, ufw, backups manuales.
• Tus datos no toleran el CLOUD Act, o tu factura AWS supera los 100 €/mes.

Al contrario, quédate en AWS si:

• Usas intensivamente Lambda, Cognito, SageMaker, SQS gestionado. Coste de migración > coste de AWS.
• Tienes un SLA contractual de cliente que exige 99,99 % (Contabo es 99,9 %, ~8 h de downtime/año).
• Manejas decenas de TB de salida y tu tráfico saliente sostenido es lo bastante alto como para alcanzar el límite fair-use de Contabo (tráfico "ilimitado" pero sujeto a una política de fair-use).

Nuestro caso en VPNSmith: un único backend Node.js + Postgres + objetos estáticos. Todos los "sí" marcados. Decisión tomada en una hora.

Auditar el coste actual de AWS (método Cost Explorer)

Antes de migrar, mide. Sin baseline, no hay ROI.

1. Ve a AWS Cost Explorer → Reports → Cost & Usage Reports.
2. Filtra los últimos 3 meses, granularidad mensual, agrupado por Service.
3. Exporta a CSV. Abre en una hoja de cálculo. Obtienes típicamente:

Anualizado: 1.884 €. Atención al detalle: en este perfil, NAT Gateway + Data Transfer = 59 €/mes, es decir el 38 % de la factura solo por mover bytes. Es el punto ciego clásico.

Provisionar el VPS Contabo objetivo

Para este stack, escogemos un Cloud VPS 10 de Contabo: 4 vCPU, 8 GB RAM, 75 GB NVMe, tráfico ilimitado (política fair-use). Tarifa 5,50 €/mes en compromiso 12 meses. Si tu base más tus objetos superan ~60 GB, sube a un Cloud VPS 20 o 30 para el NVMe adicional.

Aprovisionamiento:

# Una vez recibido el VPS (email Contabo con IP + root password)
ssh root@TU_IP

# Hardening mínimo
adduser ericg
usermod -aG sudo ericg
mkdir -p /home/ericg/.ssh
nano /home/ericg/.ssh/authorized_keys   # pega tu clave 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

El detalle completo del hardening (Lynis, snapshots Contabo, journald) está en la guía WireGuard self-host. Aquí aplicamos las mismas bases.

Migración Postgres RDS → Postgres self-hosted (pg_dump paso a paso)

Es la pieza más crítica. Procedimiento probado:

Paso 1 - Instalar Postgres 15 en Contabo

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

# Crear el usuario app y la DB
sudo -u postgres psql <<EOF
CREATE USER appuser WITH PASSWORD 'PEGA_UNA_PWD_FUERTE';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
EOF

Activa SSL y autoriza las conexiones remotas solo desde tu app (o solo en local si Postgres corre en la misma máquina que la API - recomendado):

sudo nano /etc/postgresql/15/main/postgresql.conf
# ssl = on
# listen_addresses = 'localhost'  (o '*' si la app vive en otro VPS)

sudo nano /etc/postgresql/15/main/pg_hba.conf
# Añade: hostssl appdb appuser TU_IP_APP/32 scram-sha-256

sudo systemctl restart postgresql

Paso 2 - Dump desde RDS

Desde tu puesto, con acceso a RDS:

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

# Formato custom (-Fc) = comprimido + paralelizable al restore

Para una base de 40 GB, cuenta 10-20 min según la clase RDS y el ancho de banda.

Paso 3 - Transferencia y restore

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

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;"

Verifica la integridad comparando los count(*) de las tablas grandes entre RDS y Contabo. Diferencia = 0.

Paso 4 - Backup automático post-migración

Reemplazas los automated backups de RDS por un cron simple:

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
# Push hacia MinIO o un S3 externo para off-site
rclone copy /var/backups/postgres/appdb-$DATE.dump remote:backups/postgres/

Cron diario a las 3 a. m.: 0 3 * * * /usr/local/bin/pg-backup.sh.

Migración S3 → MinIO (rclone, compatibilidad aws-cli)

MinIO es un servidor de almacenamiento de objetos 100 % compatible con la API S3, open source, en Go. Instalación directa:

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=PEGA_UNA_PWD_FUERTE_DE_32_CHARS

Servicio systemd: usa el .service oficial (docs MinIO) y systemctl enable --now minio.

Migración de los objetos desde S3 con rclone:

sudo apt install -y rclone

rclone config
# n) New remote → name: aws / s3 / AWS / pega access_key + secret_key
# n) New remote → name: minio / s3 / Other / endpoint http://localhost:9000 / pega admin + pwd

# Bucket-to-bucket
rclone copy aws:mi-bucket-prod minio:mi-bucket-prod --transfers=8 --progress

Para 30 GB: cuenta 30-60 min según el ancho de banda saliente de AWS (que te costará unos pocos euros de transfer-out final, es el coste de salida).

En el código de la aplicación, ningún cambio: tu SDK aws-sdk-js sigue funcionando, solo apuntas al endpoint MinIO:

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

Cambio de DNS sin downtime

El método limpio, planificado en 10 días:

• D-10: desplegar el stack completo en Contabo, smoke-test interno via override de /etc/hosts.
• D-7: reducir el TTL de los registros A en Route 53 de 3600 → 60 segundos. Dejar propagar 48 h.
• D-3: freeze de features, último pg_dump incremental, último rclone sync de objetos.
• D-1: cambio en hora valle (típicamente 3 a. m. UTC para público UE). Modificar el registro A: vieja IP AWS → nueva IP Contabo. Propagación máx. 60 s.
• D+0 → D+2: monitoring agresivo (latencia, errores 5xx, métricas de DB). Mantener AWS encendido "por si acaso".
• D+7: cleanup AWS (terminate EC2, delete RDS tras snapshot final exportado, delete bucket S3 tras backup off-site).

Cero downtime perceptible para el usuario si Postgres está sync (un freeze de 5 min en solo-lectura basta para mover el delta final).

¿Quieres un VPS Contabo para arrancar la migración? Cloud VPS 10 Contabo, compromiso 12 meses - 5,50 €/mes

Estimación de ROI (tabla de coste antes/después en 12 meses)

Una comparación antes/después representativa, basada en los precios públicos de cada proveedor:

Ahorro: 1.597,20 €/año, es decir alrededor del 85 % en este perfil representativo. La cifra exacta depende de tu stack, pero para una carga comparable de pequeña a media, un ahorro en la franja del 75-85 % es típico. El payback es rápido: sin coste significativo de migración (alrededor de un día de trabajo).

Lo que se pierde frente a AWS (managed services)

Sin marketing, seamos claros con las pérdidas:

• RDS Multi-AZ auto-failover: en AWS, si la primary cae, la secondary toma el relevo en 60-120 s. Self-hosted en Contabo, hace falta un segundo VPS + streaming replication + Patroni. Es factible, pero añade tiempo de ops.
• S3 11 nines de durabilidad: Amazon garantiza 99,999999999 % de durabilidad por objeto (replicación interna en 3 AZ). MinIO en 1 disco = la durabilidad de tu disco NVMe. Solución: backups regulares hacia Wasabi o Backblaze B2 (1-3 €/mes por este dataset off-site).
• IAM granular: reemplazado por usuarios Linux + sudoers + policies MinIO. Menos fino, más fácil de gestionar.
• CloudWatch unificado: reemplazar por Prometheus + Grafana, o Netdata (15 min de setup), o un SaaS externo (Better Stack, Sentry).
• Soporte enterprise 24/7: Contabo ofrece soporte por email, no el nivel enterprise 24/7 que vende AWS. Para producción crítica, prevé un runbook + un segundo admin de guardia.

Cuenta 3 a 5 horas de ops al mes en régimen de crucero: updates de Ubuntu, comprobación de backups, alertas de monitoring. Es el verdadero coste oculto - nada insuperable, pero real.

Para ir más lejos

• Self-host VPN en Contabo: guía WireGuard completa 2026
• Cloud hosting GDPR: alternativas a AWS en Europa 2026
• Contabo vs Hetzner vs OVH: VPS Europa para VPN self-host 2026
• Fuentes oficiales: Docs MinIO, PostgreSQL streaming replication, Guía AWS Cost Explorer, Recomendaciones EDPB Schrems II

Artículo publicado el 2026-06-02. ROI estimado según los precios públicos de AWS y Contabo. Divulgación de afiliación: si contratas un VPS Contabo desde los enlaces de este artículo, recibimos una comisión sin coste adicional para ti. Nuestras recomendaciones se basan en las specs y precios publicados.