Estrategia multi-cloud con VPS: failover, datos y costes

Una estrategia multi-cloud reparte la infraestructura entre varios proveedores para que la caída, el cambio de precios o las condiciones de uno solo no detengan tu servicio. No consiste en desplegar todo en todas partes, sino en decidir qué componente vive en cada proveedor y cómo se recupera si ese proveedor falla. Esta guía explica cómo diseñar esa arquitectura partiendo de un VPS como cómputo principal, con ejemplos concretos de failover, réplica de datos entre proveedores y gestión con Terraform.

Requisitos previos

Esta guía es conceptual, pero los ejemplos asumen:

• Dos servidores con Ubuntu 24.04 LTS en proveedores o ubicaciones distintas, por ejemplo un VPS de CubePath como principal y otro servidor como secundario, con un usuario sudo.
• Un dominio con el DNS gestionado en Cloudflare.
• Una cuenta en un proveedor de almacenamiento de objetos compatible con S3 (Amazon S3, Backblaze B2, Cloudflare R2 u otro).
• Terraform 1.5 o superior si quieres seguir el ejemplo de infraestructura como código.

Multi-cloud, nube híbrida y alta disponibilidad

Conviene separar tres conceptos que suelen mezclarse:

Multi-cloud añade complejidad: más paneles, más facturas, más credenciales y más formas de fallar. Merece la pena cuando el coste de una caída del proveedor supera el coste de operar dos, o cuando necesitas una copia de los datos fuera del alcance de una sola cuenta.

Principios de diseño

Separar el plano de control del de datos

El componente que decide a dónde va el tráfico (DNS, balanceador) no debe estar en el mismo proveedor que protege. Si tu DNS lo sirve el mismo proveedor que aloja tu VPS y ese proveedor cae, no podrás redirigir el tráfico a ningún sitio. Por eso lo habitual es delegar DNS y proxy en un servicio independiente, como Cloudflare.

Los backups, en otro proveedor y otra cuenta

La regla 3-2-1 (tres copias, en dos soportes, una fuera del sitio) se traduce en cloud en guardar al menos una copia en un proveedor distinto al que ejecuta la carga, con credenciales que el servidor de producción no pueda usar para borrar el historial.

Usar tecnologías portables

Cuanto más dependas de servicios propietarios, más cuesta mover una carga. Algunas elecciones que reducen el lock-in:

• Contenedores Docker y Compose o Kubernetes en lugar de plataformas de ejecución propietarias.
• PostgreSQL o MySQL estándar en lugar de bases de datos con API propia.
• Almacenamiento con API S3, que soportan casi todos los proveedores de objetos.
• Infraestructura descrita como código (Terraform, Ansible) para poder recrearla en otro sitio.

Reparto de cargas de trabajo

Arquitectura de referencia

Un diseño sencillo y realista para una aplicación web tiene estos elementos:

1. Cloudflare delante de todo, con DNS, proxy y WAF.
2. Un VPS principal que sirve la aplicación y aloja la base de datos.
3. Un servidor secundario en otro proveedor, con la aplicación desplegada y una réplica de la base de datos, que recibe tráfico solo si el principal falla.
4. Un bucket de almacenamiento de objetos en un tercer proveedor con los backups de ambos.

Antes de montar la réplica, mide la latencia y el ancho de banda entre los dos servidores, porque condicionan si la réplica puede ser síncrona o no. Instala las herramientas en ambos:

sudo apt update
sudo apt install mtr-tiny iperf3

Mide la ruta y la latencia hacia el secundario:

mtr --report --report-cycles 20 your_secondary_ip

Para medir el ancho de banda, arranca iperf3 -s en el secundario (abre temporalmente el puerto 5201/tcp) y lanza la prueba desde el principal:

iperf3 -c your_secondary_ip -t 10

Con latencias por encima de 10 a 20 ms entre proveedores, usa réplica asíncrona: una réplica síncrona añadiría esa latencia a cada escritura.

Failover de tráfico con Cloudflare

Endpoint de salud en cada servidor

Cualquier sistema de failover necesita saber si el servidor responde. Añade una ruta /health en el bloque server de Nginx de cada servidor:

sudo nano /etc/nginx/sites-available/your_domain

location = /health {
    access_log off;
    default_type text/plain;
    return 200 "OK\n";
}

Valida y recarga:

sudo nginx -t && sudo systemctl reload nginx
curl -s http://localhost/health

OK

En producción, haz que /health compruebe también la base de datos desde la aplicación; un Nginx que responde con la aplicación caída no debería contar como sano.

Cloudflare Load Balancing

Cloudflare Load Balancing es un complemento de pago que hace el failover en la red de Cloudflare, sin depender de la caché DNS de los clientes. Se configura en el panel, en la sección Load Balancing del dominio:

1. Crea un monitor de tipo HTTPS contra la ruta /health, esperando el código 200.
2. Crea un pool primario con la IP del VPS principal y otro pool secundario con la del secundario, ambos asociados al monitor.
3. Crea el load balancer para your_domain con los pools en ese orden y el método de reparto Off (failover), de modo que el secundario solo reciba tráfico cuando el primario esté caído.

Como los registros van con proxy, el cambio es inmediato para los visitantes: Cloudflare simplemente envía las peticiones al otro origen.

Failover manual sin Load Balancing

Si no quieres el complemento, puedes cambiar el registro A por API cuando el principal falle. Con el proxy activado el cambio se aplica en la red de Cloudflare en segundos, sin esperar al TTL. Necesitas un token con permiso Zone > DNS > Edit, el ID de la zona y el ID del registro:

curl -s "https://api.cloudflare.com/client/v4/zones/your_zone_id/dns_records?name=your_domain&type=A" \
  -H "Authorization: Bearer your_api_token"

El campo result[0].id es el ID del registro. Para apuntar el dominio al secundario:

curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/your_zone_id/dns_records/your_record_id" \
  -H "Authorization: Bearer your_api_token" \
  -H "Content-Type: application/json" \
  --data '{"content":"your_secondary_ip"}'

La respuesta contiene "success": true y el nuevo content. Automatizar este cambio es posible, pero la comprobación debe hacerse desde un tercer punto (ni el principal ni el secundario) y exigir varios fallos seguidos, o provocarás cambios de ida y vuelta ante un fallo de red puntual.

Réplica de datos entre proveedores

Archivos y backups con rclone

rclone copia y sincroniza datos entre casi cualquier proveedor de almacenamiento. Instálalo desde los repositorios de Ubuntu:

sudo apt install rclone

Crea un remoto por proveedor. Por ejemplo, uno para Amazon S3 y otro para Backblaze B2 (las claves son placeholders):

rclone config create aws s3 provider=AWS env_auth=false access_key_id=your_aws_key_id secret_access_key=your_aws_secret region=eu-west-1
rclone config create b2 b2 account=your_b2_key_id key=your_b2_application_key

Comprueba que ambos remotos responden:

rclone lsd aws:
rclone lsd b2:

Replica el bucket de backups de un proveedor al otro. sync hace que el destino sea idéntico al origen, así que lánzalo primero con --dry-run:

rclone sync aws:your_backup_bucket b2:your_backup_bucket --dry-run
rclone sync aws:your_backup_bucket b2:your_backup_bucket --transfers 8 --log-file /var/log/rclone-replica.log

Verifica después que ambos lados coinciden:

rclone check aws:your_backup_bucket b2:your_backup_bucket --one-way

NOTICE: S3 bucket your_backup_bucket: 0 differences found
NOTICE: S3 bucket your_backup_bucket: 1843 matching files

Importante

si el bucket de destino no tiene versionado o retención propia, un borrado en el origen se replicará al destino con sync. Para una copia de seguridad aislada, usa rclone copy o activa el versionado del bucket de destino.

Base de datos

Para la base de datos, la réplica nativa del motor es la opción correcta: réplica en streaming en PostgreSQL o réplica por binlog con GTID en MySQL y MariaDB. Tres reglas al cruzar proveedores:

• El tráfico de réplica debe ir cifrado, por TLS o por un túnel WireGuard entre los servidores, nunca en claro por Internet.
• Abre el puerto de la base de datos solo a la IP del otro servidor (sudo ufw allow from your_secondary_ip to any port 5432 proto tcp).
• La réplica no sustituye al backup: un DROP TABLE se replica en milisegundos. Mantén volcados diarios en el almacenamiento de objetos.

Gestión con Terraform

Terraform describe recursos de varios proveedores en un mismo proyecto, lo que evita configuraciones hechas a mano que nadie sabe recrear. Este ejemplo crea el bucket de backups en AWS y el registro DNS con proxy en Cloudflare:

mkdir multicloud && cd multicloud
nano main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5.0"
    }
  }
}

variable "cloudflare_api_token" {
  type      = string
  sensitive = true
}

variable "cloudflare_zone_id" {
  type = string
}

variable "primary_ip" {
  type = string
}

provider "aws" {
  region = "eu-west-1"
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

resource "aws_s3_bucket" "backups" {
  bucket = "your-backup-bucket"
}

resource "aws_s3_bucket_versioning" "backups" {
  bucket = aws_s3_bucket.backups.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "cloudflare_dns_record" "root" {
  zone_id = var.cloudflare_zone_id
  name    = "your_domain"
  type    = "A"
  content = var.primary_ip
  proxied = true
  ttl     = 1
}

Las credenciales de AWS se leen del entorno o de ~/.aws, y las variables de Cloudflare puedes pasarlas con TF_VAR_cloudflare_api_token y similares para que no queden en el código. Inicializa y revisa el plan:

terraform init
terraform plan

Plan: 3 to add, 0 to change, 0 to destroy.

Aplica con terraform apply cuando el plan sea el esperado. Si el registro DNS ya existe, impórtalo antes con terraform import para que Terraform no intente crearlo de nuevo.

Costes que conviene vigilar

• Tráfico de salida: las nubes públicas cobran por GB que sale de su red, y es la partida que más sorprende. Replicar datos desde una nube pública hacia fuera o servir descargas directamente desde ella puede costar más que el propio almacenamiento. Los VPS suelen incluir un volumen de tráfico mensual.
• Recursos olvidados: instancias, volúmenes, IPs y snapshots de pruebas que siguen facturando. Terraform ayuda porque terraform destroy elimina lo que creó.
• Duplicación: un secundario en espera cuesta dinero todos los meses. Dimensiónalo para soportar la carga mínima aceptable, no la de producción completa.

Qué estrategia elegir

• Proyecto pequeño o mediano: un VPS principal, DNS y CDN en Cloudflare y backups diarios en el almacenamiento de objetos de otro proveedor. Es multi-cloud en lo que importa (datos y DNS) con muy poca complejidad, y la recuperación consiste en restaurar el backup en un servidor nuevo.
• Servicio que no puede estar caído horas: añade un secundario en otro proveedor con la aplicación desplegada, réplica asíncrona de la base de datos y failover con Cloudflare Load Balancing. Ensaya el failover periódicamente.
• Cargas variables o especializadas: mantén lo constante en VPS y lleva a la nube pública solo los picos, los trabajos por lotes o la GPU, conectando ambos entornos con una VPN.

Conclusión

Una estrategia multi-cloud útil empieza por lo que más duele perder: los datos y el control del tráfico. Con backups replicados en un proveedor distinto, DNS y proxy independientes del origen y la infraestructura descrita en Terraform, puedes recuperarte de la caída de cualquier proveedor. Como siguientes pasos, automatiza los backups hacia almacenamiento de objetos, conecta tus servidores de distintos proveedores con WireGuard para cifrar la réplica y programa un simulacro de failover cada pocos meses.