Arquitectura de Nube Híbrida con VPS y Cloud Público

Una arquitectura de nube híbrida conecta tu infraestructura VPS con servicios de cloud público (AWS, GCP, Azure) para obtener lo mejor de ambos mundos: el control y el precio predecible de un servidor dedicado, más la elasticidad y los servicios gestionados de los grandes proveedores. Esta guía cubre la interconexión VPN entre VPS y cloud público, la distribución de cargas de trabajo, la sincronización de datos y las estrategias de escalado cost-effective.

Requisitos Previos

  • VPS Linux con IP pública fija
  • Cuenta en al menos un proveedor cloud público (AWS, GCP o Azure)
  • AWS CLI, gcloud o az instalados y configurados
  • WireGuard o acceso para configurar VPN IPsec
  • Conocimientos básicos de redes (subredes, CIDR, routing)

Diseño de la Arquitectura Híbrida

Planificación de subredes

Para que los dos entornos puedan comunicarse, asigna rangos de IP que no se solapen:

VPS y red propia:    10.0.0.0/8    (10.0.1.0/24 para servidores)
AWS VPC:             172.16.0.0/12  (172.16.0.0/16 para la VPC)
GCP VPC:             192.168.0.0/16 (192.168.1.0/24 para la VPC)
WireGuard tunnel:    10.200.0.0/24

Principios de diseño

  1. Separación de planos: El tráfico de producción y el de administración viajan por túneles separados
  2. Principio de menor privilegio: Cada componente solo tiene acceso a lo que necesita
  3. Idempotencia: Los despliegues pueden repetirse sin efectos secundarios
  4. Observabilidad: Todo el tráfico entre entornos queda registrado

Interconexión VPN entre VPS y AWS

Configurar un Virtual Private Gateway en AWS

# Crear un Customer Gateway (representando el VPS)
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip IP_PUBLICA_VPS \
  --bgp-asn 65000

# Crear el Virtual Private Gateway
aws ec2 create-vpn-gateway \
  --type ipsec.1 \
  --amazon-side-asn 64512

# Obtener los IDs generados
VGW_ID=$(aws ec2 describe-vpn-gateways \
  --query 'VpnGateways[0].VpnGatewayId' \
  --output text)
CGW_ID=$(aws ec2 describe-customer-gateways \
  --query 'CustomerGateways[0].CustomerGatewayId' \
  --output text)

# Asociar el VGW a la VPC
aws ec2 attach-vpn-gateway \
  --vpn-gateway-id $VGW_ID \
  --vpc-id vpc-xxxxxxxxxx

# Crear la conexión VPN
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id $CGW_ID \
  --vpn-gateway-id $VGW_ID \
  --options StaticRoutesOnly=true

# Descargar la configuración VPN (para configurar en el VPS)
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[0].CustomerGatewayConfiguration' \
  --output text > vpn-config.xml

Interconexión con WireGuard

WireGuard es la forma más sencilla y eficiente de conectar un VPS con instancias cloud.

Instalación en ambos extremos

# Instalar WireGuard en Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y wireguard

# Instalar en CentOS/Rocky
sudo dnf install -y epel-release
sudo dnf install -y wireguard-tools

Configuración en el VPS (nodo hub)

# Generar el par de claves del VPS
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
sudo chmod 600 /etc/wireguard/privatekey

PRIVATE_KEY=$(sudo cat /etc/wireguard/privatekey)
PUBLIC_KEY=$(sudo cat /etc/wireguard/publickey)

# Crear la configuración de WireGuard en el VPS
sudo cat > /etc/wireguard/wg0.conf << EOF
[Interface]
PrivateKey = $PRIVATE_KEY
Address = 10.200.0.1/24
ListenPort = 51820

# Activar el reenvío de paquetes para comunicación entre peers
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# Instancia AWS (añadir después de crear las claves en la instancia)
[Peer]
PublicKey = CLAVE_PUBLICA_INSTANCIA_AWS
AllowedIPs = 10.200.0.2/32, 172.16.0.0/16
EOF

# Activar el reenvío de IP en el kernel
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Iniciar WireGuard
sudo systemctl enable --now wg-quick@wg0

Configuración en la instancia cloud

# Instalar WireGuard en la instancia de AWS/GCP/Azure
sudo apt-get install -y wireguard

# Generar claves en la instancia cloud
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
sudo chmod 600 /etc/wireguard/privatekey

# Configuración de la instancia cloud
sudo cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey = CLAVE_PRIVADA_DE_ESTA_INSTANCIA
Address = 10.200.0.2/24

# El VPS actúa como gateway hacia la red 10.0.0.0/8
[Peer]
PublicKey = CLAVE_PUBLICA_DEL_VPS
Endpoint = IP_PUBLICA_VPS:51820
AllowedIPs = 10.200.0.0/24, 10.0.0.0/8
PersistentKeepalive = 25
EOF

sudo systemctl enable --now wg-quick@wg0

# Verificar la conexión
sudo wg show
ping 10.200.0.1  # Ping al VPS a través del túnel

Distribución de Cargas de Trabajo

Criterios de decisión: VPS vs Cloud

VPS (siempre encendido, coste fijo):
  ✓ Servidor web/API principal
  ✓ Base de datos de producción
  ✓ Servicios de monitorización
  ✓ Proxy inverso / balanceador de carga

Cloud público (pago por uso):
  ✓ Procesamiento batch y análisis de datos
  ✓ Funciones serverless (Lambda, Cloud Functions)
  ✓ Almacenamiento de backups y archivos estáticos
  ✓ Escalado horizontal en picos de demanda
  ✓ Machine Learning y GPU bajo demanda

Ejemplo: offloading de procesamiento pesado a AWS Lambda

# Función Lambda que procesa archivos subidos al VPS
# El VPS sube el archivo a S3 y dispara la Lambda

# Script en el VPS para enviar trabajo a Lambda
cat > /usr/local/bin/procesar-en-lambda.sh << 'EOF'
#!/bin/bash
# Subir el archivo a S3 y disparar la función Lambda

ARCHIVO=$1
BUCKET="mi-bucket-procesamiento"
FUNCION_LAMBDA="procesar-imagen"

# Subir el archivo a S3
aws s3 cp "$ARCHIVO" "s3://$BUCKET/entrada/$(basename $ARCHIVO)"

# Invocar Lambda con el archivo como parámetro
aws lambda invoke \
  --function-name "$FUNCION_LAMBDA" \
  --payload "{\"bucket\":\"$BUCKET\",\"key\":\"entrada/$(basename $ARCHIVO)\"}" \
  --cli-binary-format raw-in-base64-out \
  /tmp/lambda-resultado.json

# Mostrar el resultado
cat /tmp/lambda-resultado.json
EOF

chmod +x /usr/local/bin/procesar-en-lambda.sh

Sincronización de Datos

Sincronización bidireccional con rsync sobre VPN

# Sincronizar archivos del VPS a la instancia cloud (a través del túnel WireGuard)
rsync -avz --delete \
  /var/www/uploads/ \
  [email protected]:/var/www/uploads/

# Sincronización con logs de cambios
rsync -avz --delete \
  --log-file=/var/log/rsync-hibrido.log \
  /var/www/ \
  [email protected]:/var/www/

Sincronización de base de datos (réplica de solo lectura en cloud)

# Configurar réplica de lectura de PostgreSQL en la instancia cloud
# Los reads pesados van a la réplica, los writes al VPS principal

# En la aplicación, configurar dos conexiones:
# WRITE: 10.0.1.10:5432 (VPS principal)
# READ:  10.200.0.2:5432 (réplica en cloud)

Escalado Automático en Cloud

AWS Auto Scaling basado en métricas del VPS

# Crear una métrica personalizada en CloudWatch desde el VPS
cat > /usr/local/bin/enviar-metrica-aws.sh << 'EOF'
#!/bin/bash
# Enviar la carga de CPU del VPS a CloudWatch para disparar auto-scaling

CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)

aws cloudwatch put-metric-data \
  --metric-name "VPS-CPU-Usage" \
  --namespace "HybridCloud/VPS" \
  --value "$CPU" \
  --unit Percent \
  --region eu-west-1

echo "Métrica enviada: CPU=${CPU}%"
EOF

chmod +x /usr/local/bin/enviar-metrica-aws.sh

# Programar el envío cada minuto
echo "* * * * * /usr/local/bin/enviar-metrica-aws.sh" | crontab -

Migración Progresiva de Cargas

Estrategia de migración por fases

Fase 1: Monitorización sin migración

# Medir el uso de recursos actuales durante 2 semanas
sar -u 1 3600 >> /var/log/cpu-uso.log &
sar -b 1 3600 >> /var/log/io-uso.log &

Fase 2: Migrar servicios sin estado primero

# Los servicios sin estado (workers, API stateless) son los más fáciles de migrar
# Usar Docker para garantizar portabilidad
docker save mi-app:latest | ssh [email protected] docker load

Fase 3: Migrar datos con mínimo downtime

# Pre-sincronizar los datos antes del cambio
rsync -avz /var/data/ [email protected]:/var/data/

# Detener el servicio, sincronización final, redirigir tráfico
systemctl stop mi-aplicacion
rsync -avz /var/data/ [email protected]:/var/data/
# Actualizar el DNS o el balanceador de carga
systemctl start mi-aplicacion-en-cloud

Solución de Problemas

El túnel WireGuard no conecta

# Verificar que el puerto UDP está abierto en el firewall
sudo ufw allow 51820/udp
sudo iptables -L INPUT | grep 51820

# Ver el estado del túnel y los peers conectados
sudo wg show

# Ver logs de WireGuard
sudo journalctl -u wg-quick@wg0 -f

El routing entre redes no funciona

# Verificar el reenvío de IP
cat /proc/sys/net/ipv4/ip_forward
# Debe ser 1

# Ver la tabla de rutas
ip route show

# Añadir ruta manualmente si es necesario
sudo ip route add 172.16.0.0/16 via 10.200.0.2

Alta latencia en la comunicación VPS-Cloud

# Diagnosticar la ruta de red
mtr --report 10.200.0.2

# Verificar la calidad del túnel WireGuard
sudo wg show wg0
# Revisar la columna "latest handshake" y "transfer"

Conclusión

La arquitectura de nube híbrida con VPS y cloud público ofrece el equilibrio ideal entre control, coste y flexibilidad. Con WireGuard como capa de interconexión segura, puedes aprovechar los servicios gestionados de AWS, GCP o Azure para las cargas de trabajo más exigentes mientras mantienes el núcleo de tu aplicación en un VPS con costes predecibles y control total sobre el hardware.