--- title: "Estrategia multi-cloud con VPS: failover, datos y costes" description: "Diseña una arquitectura multi-cloud con VPS: reparto de cargas, failover con Cloudflare, réplica de backups con rclone y Terraform para varios proveedores." category: "Integración Cloud" language: es source: https://cubepath.com/es/docs/integración-cloud/estrategia-multi-cloud-para-servidores-vps updated: 2026-09-25 --- # 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: | Concepto | Qué significa | Ejemplo | |----------|---------------|---------| | Alta disponibilidad | Redundancia dentro de un mismo proveedor | Dos VPS del mismo proveedor en distinta ubicación detrás de un balanceador | | Multi-cloud | Servicios repartidos entre varios proveedores independientes | Web en un VPS, backups en otro proveedor, DNS en un tercero | | Nube híbrida | Infraestructura propia o VPS conectada en red privada con una nube pública | Un VPS unido por VPN a una VPC de AWS | 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 | Componente | Dónde encaja mejor | Motivo | |-----------|-------------------|--------| | Web y API con carga constante | VPS | Precio mensual fijo y tráfico incluido | | Base de datos principal | VPS junto a la aplicación | Baja latencia entre aplicación y datos | | DNS, CDN y WAF | Proveedor independiente (Cloudflare) | Sobrevive a la caída del origen y permite el failover | | Backups y archivos | Almacenamiento de objetos de otro proveedor | Coste bajo por GB y aislamiento del origen | | Picos puntuales, GPU, procesamiento por lotes | Nube pública con pago por uso | Se paga solo mientras se usa | ## 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: ```bash sudo apt update sudo apt install mtr-tiny iperf3 ``` Mide la ruta y la latencia hacia el secundario: ```bash 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: ```bash 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: ```bash sudo nano /etc/nginx/sites-available/your_domain ``` ```nginx location = /health { access_log off; default_type text/plain; return 200 "OK\n"; } ``` Valida y recarga: ```bash sudo nginx -t && sudo systemctl reload nginx curl -s http://localhost/health ``` ```output 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: ```bash 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: ```bash 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: ```bash sudo apt install rclone ``` Crea un remoto por proveedor. Por ejemplo, uno para Amazon S3 y otro para Backblaze B2 (las claves son placeholders): ```bash 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: ```bash 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`: ```bash 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: ```bash rclone check aws:your_backup_bucket b2:your_backup_bucket --one-way ``` ```output 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: ```bash mkdir multicloud && cd multicloud nano main.tf ``` ```hcl 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: ```bash terraform init terraform plan ``` ```output 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.