Escalar tu VPS: Vertical vs Horizontal Explicado

Tu VPS funcionaba perfecto. Pero el tráfico ha crecido, la CPU está siempre al 90%, la RAM no da más. Necesitas más recursos.

Tienes dos opciones: escalar verticalmente (servidor más grande) o horizontalmente (más servidores). Cada una tiene sus ventajas y casos de uso.

Esta guía te ayuda a decidir y ejecutar el escalado correctamente.

Señales de que necesitas escalar

Métricas que gritan “escálame”

Métrica	Umbral crítico	Acción
CPU	>80% sostenido	Escalar
RAM	>85% (sin caché)	Escalar
Disco I/O	iowait >30%	Escalar o NVMe
Conexiones	Near max	Escalar horizontal
Tiempo respuesta	>2s consistente	Optimizar o escalar

Antes de escalar: ¿has optimizado?

Escalar cuesta dinero. Antes de añadir recursos, verifica:

1. ¿OPcache activo? Mejora PHP 50%+ gratis
2. ¿Buffer pool MySQL ajustado? Usa 50-70% de RAM
3. ¿Caché configurada? Redis, page cache
4. ¿CDN activo? Cloudflare reduce carga 60-80%
5. ¿Código optimizado? Queries lentas, plugins pesados

Un VPS bien optimizado puede manejar 3-5x más tráfico que uno sin optimizar.

Escalado vertical vs horizontal

Escalado vertical (scale up)

Qué es: Hacer tu servidor más grande. Más CPU, más RAM, más disco.

VPS 2 cores / 4GB → VPS 4 cores / 8GB → VPS 8 cores / 16GB

Ventajas:

• Simple: no cambias arquitectura
• Sin complejidad de red
• Una sola máquina que administrar
• Funciona con cualquier aplicación

Desventajas:

• Tiene límite físico
• Puede requerir downtime
• Un solo punto de fallo
• Coste crece exponencialmente

Escalado horizontal (scale out)

Qué es: Añadir más servidores y distribuir la carga.

1 VPS → 2 VPS + Load Balancer → 4 VPS + Load Balancer

Ventajas:

• Sin límite teórico
• Alta disponibilidad
• Coste más lineal
• Redundancia natural

Desventajas:

• Complejidad de arquitectura
• Requiere load balancer
• Sesiones y caché distribuidos
• No todas las apps lo soportan

Cuándo usar cada uno

Escala verticalmente si:

• Aplicación simple: WordPress, tienda pequeña
• Tráfico predecible: Sin picos extremos
• Equipo pequeño: Sin DevOps dedicado
• Presupuesto ajustado: No puedes pagar infraestructura compleja
• Primeras veces: Es tu primer escalado

Escala horizontalmente si:

• Alta disponibilidad crítica: No puedes permitirte caídas
• Tráfico muy variable: Picos impredecibles
• Límites físicos alcanzados: Ya tienes el VPS más grande
• Aplicación preparada: Stateless, sesiones externas
• Equipo técnico: Puedes gestionar la complejidad

La realidad para la mayoría

El 90% de sitios web pueden funcionar perfectamente con escalado vertical hasta un VPS de 16-32GB. Solo necesitas horizontal si:

• Tienes millones de visitas mensuales
• Requieres SLA de 99.99%+
• Tu aplicación ya está preparada para ello

Cómo escalar verticalmente

Paso 1: Planificar

1. Identifica el cuello de botella: ¿CPU, RAM, disco?
2. Elige el plan superior: El doble de recursos suele ser buena opción
3. Programa el cambio: Horario de bajo tráfico
4. Haz backup: Siempre antes de cambios

Paso 2: Ejecutar (depende del proveedor)

Proveedores con escalado en caliente:

Algunos proveedores permiten añadir recursos sin reiniciar:

Panel de control → Upgrade plan → Aplicar

Downtime: 0 o pocos minutos.

Proveedores con reinicio requerido:

La mayoría requiere reinicio para cambios de CPU/RAM:

1. Haz backup completo
2. Inicia upgrade desde el panel
3. Espera migración (5-30 minutos)
4. Verifica que todo funciona

Los VPS de Avantys permiten upgrade de recursos desde el panel.

Paso 3: Ajustar configuración

Después de escalar, ajusta configuraciones para usar los nuevos recursos:

MySQL (más RAM disponible):

innodb_buffer_pool_size = 4G  # Era 1G, ahora más

PHP-FPM (más RAM, más procesos):

pm.max_children = 100  # Era 50

Nginx (más workers si más cores):

worker_processes auto;  # Detecta cores automáticamente

Cómo escalar horizontalmente

Arquitectura básica

                    ┌─────────────┐
                    │   Usuario   │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │Load Balancer│
                    └──────┬──────┘
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼─────┐┌─────▼─────┐┌─────▼─────┐
        │   VPS 1   ││   VPS 2   ││   VPS 3   │
        └─────┬─────┘└─────┬─────┘└─────┬─────┘
              │            │            │
              └────────────┼────────────┘
                           │
                    ┌──────▼──────┐
                    │  BD / Redis │
                    │ (compartido)│
                    └─────────────┘

Componentes necesarios

1. Load Balancer

Distribuye tráfico entre servidores:

• Nginx como LB
• HAProxy
• Load balancer del proveedor cloud

2. Servidores de aplicación

Múltiples VPS idénticos ejecutando tu app.

3. Base de datos centralizada

Un servidor dedicado para MySQL/PostgreSQL, accesible por todos los nodos.

4. Caché compartida

Redis o Memcached centralizado para sesiones y object cache.

5. Almacenamiento compartido (si necesario)

Para archivos subidos por usuarios:

• NFS
• S3 / Object storage
• GlusterFS

Configurar Nginx como Load Balancer

upstream backend {
    least_conn;  # Envía al servidor con menos conexiones
    
    server 10.0.0.1:80 weight=1;
    server 10.0.0.2:80 weight=1;
    server 10.0.0.3:80 weight=1;
    
    keepalive 32;
}

server {
    listen 80;
    server_name tudominio.com;
    
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Connection "";
    }
}

Sesiones distribuidas

Con múltiples servidores, las sesiones no pueden estar en disco local.

Opción 1: Sticky sessions

El load balancer envía siempre al mismo usuario al mismo servidor:

upstream backend {
    ip_hash;  # Sticky por IP
    server 10.0.0.1:80;
    server 10.0.0.2:80;
}

Simple pero no óptimo si un servidor cae.

Opción 2: Sesiones en Redis (recomendado)

PHP:

session.save_handler = redis
session.save_path = "tcp://redis-server:6379"

Todas las sesiones en Redis central, cualquier servidor puede atenderlas.

Archivos subidos por usuarios

Si usuarios suben archivos, necesitas almacenamiento compartido:

Opción simple: S3 o compatible

Configura tu app para guardar uploads en S3:

• Amazon S3
• Backblaze B2
• DigitalOcean Spaces

Opción self-hosted: NFS

# En servidor de almacenamiento
sudo apt install nfs-kernel-server
sudo mkdir /shared-uploads
echo "/shared-uploads 10.0.0.0/24(rw,sync,no_subtree_check)" >> /etc/exports
sudo exportfs -a

# En cada nodo de aplicación
sudo apt install nfs-common
sudo mount servidor-nfs:/shared-uploads /var/www/uploads

Escalado automático (auto-scaling)

En cloud, puedes configurar escalado automático:

CPU > 80% durante 5 min → Añadir servidor
CPU < 30% durante 10 min → Eliminar servidor

Requiere:

• Proveedor cloud compatible (AWS, GCP, Azure)
• Imágenes de servidor preconfiguradas
• Aplicación totalmente stateless

Para la mayoría de VPS tradicionales, el escalado manual es suficiente.

Base de datos: el cuello de botella común

Escalar la aplicación es fácil. Escalar la base de datos es difícil.

Opción 1: Servidor de BD más grande

Escalado vertical para la BD. Funciona hasta cierto punto.

Opción 2: Read replicas

Un master para escrituras, múltiples replicas para lecturas:

           Escrituras
               │
        ┌──────▼──────┐
        │   Master    │
        └──────┬──────┘
               │ Replicación
    ┌──────────┼──────────┐
    │          │          │
┌───▼───┐  ┌───▼───┐  ┌───▼───┐
│Replica│  │Replica│  │Replica│
└───────┘  └───────┘  └───────┘
    ▲          ▲          ▲
    └──────────┴──────────┘
           Lecturas

Funciona bien si tienes muchas más lecturas que escrituras (típico en webs).

Opción 3: BD gestionada

Delega la complejidad al proveedor:

• Amazon RDS
• Google Cloud SQL
• PlanetScale (MySQL)

Más caro pero sin gestión.

Costes de escalado

Vertical: crece exponencialmente

Plan	CPU	RAM	Precio típico
Básico	2	4GB	€10/mes
Medio	4	8GB	€25/mes
Grande	8	16GB	€60/mes
XL	16	32GB	€150/mes

El doble de recursos no cuesta el doble.

Horizontal: crece linealmente (más o menos)

Setup	Servidores	Precio típico
1 VPS	1 app	€25/mes
2 VPS + LB	2 app + LB	€60/mes
4 VPS + LB	4 app + LB	€110/mes

Más predecible, pero hay costes fijos (LB, BD dedicada).

El punto de cruce

Para muchos casos, vertical es más barato hasta VPS de ~€100-150/mes. Después, horizontal puede ser más eficiente.

Errores comunes al escalar

Error 1: Escalar sin optimizar primero

Estás pagando por ineficiencia. Un VPS de €100 mal configurado rinde menos que uno de €25 bien optimizado.

Error 2: No hacer backup antes

Si algo sale mal durante el escalado, necesitas poder volver atrás.

Error 3: No ajustar configuración después

Si pasas de 4GB a 8GB de RAM pero no ajustas MySQL, no usas los recursos nuevos.

Error 4: Horizontal sin preparar la app

Si tu app guarda sesiones en disco o uploads locales, horizontal romperá cosas.

Error 5: No monitorizar después

Escalar no es “set and forget”. Monitoriza para ver si fue suficiente.

Cuándo considerar dedicado o cloud

Servidor dedicado

Si necesitas más de 32GB RAM / 16 cores consistentemente, un servidor dedicado puede ser más económico que un VPS grande.

Cloud (AWS, GCP, Azure)

Si necesitas:

• Auto-scaling real
• Presencia multi-región
• Servicios gestionados (BD, colas, etc.)
• SLA enterprise

El cloud es más caro pero ofrece más flexibilidad y servicios.

Preguntas frecuentes

¿Cuánto downtime causa escalar verticalmente?

Depende del proveedor. Algunos permiten en caliente (0 downtime). Otros requieren reinicio (5-30 minutos).

¿Puedo volver atrás después de escalar?

Generalmente sí (downgrade). Pero verifica que tus datos caben en el plan menor.

¿El escalado horizontal es difícil?

Más complejo que vertical, pero no imposible. Requiere cambios en arquitectura y cómo gestionas sesiones/archivos.

¿WordPress puede escalar horizontalmente?

Sí, con configuración: sesiones en Redis, uploads en S3, y plugins compatibles (evita los que escriben en disco).

Nuestra recomendación

Para la mayoría: Escalado vertical es suficiente. Un VPS de 8-16GB bien optimizado maneja muchísimo tráfico.

El camino típico:

1. VPS pequeño (2-4GB) + optimización
2. VPS medio (8-16GB) cuando necesites
3. Horizontal solo si realmente lo requieres

¿No quieres complicarte? La administración gestionada incluye asesoramiento de escalado y ejecución del upgrade.

---

Conclusión

Escalar no es complejo si sigues el camino correcto: optimiza primero, escala verticalmente mientras sea práctico, y considera horizontal solo cuando realmente lo necesites.

Para el 90% de sitios web, un VPS bien dimensionado y optimizado es todo lo que necesitan. No sobreingenieres antes de tiempo.

Cuando sea el momento de escalar, los VPS de Avantys permiten upgrade fácil desde el panel de control.

---

Guías relacionadas

• Optimizar el rendimiento de tu VPS
• Monitorizar tu VPS con Netdata
• Caché en VPS: Redis, Memcached y OPcache
• CDN para tu VPS con Cloudflare

---

¿Quieres la guía completa con todos los casos de uso?

→ Volver a la guía maestra: Mejor VPS en España 2026