VPS vs servidor dedicado vs cloud: cuál elegir y por qué

Un VPS, un servidor dedicado y una plataforma cloud elástica pueden ejecutar exactamente el mismo software: la diferencia está en cómo se reparte el hardware, cómo se paga y cuánto trabajo exige escalar o recuperarse de un fallo. Esta guía explica qué es cada opción, las compara en los puntos que de verdad afectan a una aplicación, muestra cómo medir el rendimiento de tu propio servidor y termina con criterios concretos para decidir.

Qué es cada opción

VPS (servidor privado virtual). Una máquina virtual con una cantidad fija de vCPU, RAM y disco, que comparte el servidor físico con otras máquinas virtuales mediante un hipervisor como KVM. Tienes acceso root y control total del sistema operativo, se crea en minutos y se paga una cuota fija o por horas. Si necesitas más recursos, cambias de plan.

Servidor dedicado (bare metal). Una máquina física completa para ti: todos los núcleos, la memoria, los discos y la tarjeta de red. No hay hipervisor ni vecinos, así que el rendimiento es predecible y puedes usar funciones de hardware que una máquina virtual no expone (virtualización propia, RAID, GPU, acceso directo a NVMe).

Cloud elástico. Una plataforma donde la máquina virtual es solo una pieza: además ofrece grupos de autoescalado, balanceadores, bases de datos gestionadas, almacenamiento de objetos y una API para crear y destruir recursos en segundos. Se paga por uso, normalmente por segundo u hora, más el tráfico y cada servicio adicional.

La frontera entre VPS y cloud es difusa: muchos proveedores de VPS ofrecen facturación por horas, API, redes privadas y balanceadores. En esta guía, "cloud" se refiere al modelo de infraestructura elástica y servicios gestionados, y "VPS" a máquinas virtuales de tamaño fijo que administras tú.

Tabla comparativa

Rendimiento: qué cambia realmente

La virtualización moderna con KVM y extensiones de hardware tiene una penalización pequeña en CPU y memoria para la mayoría de cargas. Donde se nota la diferencia es en dos puntos:

• Vecinos ruidosos. En un VPS o una instancia cloud compartes el host. Si otro cliente satura la CPU o el almacenamiento, tu máquina puede recibir menos tiempo de CPU del que espera. En Linux esto aparece como steal time.
• Disco y red. El almacenamiento de un VPS suele estar limitado en IOPS por plan o compartido, y el cloud cobra aparte por discos más rápidos. Un dedicado con NVMe local da la latencia más baja y constante.

En lugar de fiarte de benchmarks publicados, mide tu propio servidor. Estos comandos funcionan en Ubuntu 24.04.

Comprueba el steal time (columna st) durante un minuto:

vmstat 5 12

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 612344  51220 902144    0    0    12    40  210  380  6  2 92  0  0

Un st de 0 a 2 de forma sostenida es normal. Valores altos y constantes indican que el host está sobrecargado.

Mide la CPU con sysbench:

sudo apt install sysbench
sysbench cpu --threads="$(nproc)" --time=30 run | grep -E 'events per second|total number of events'

Mide el disco con fio, con una prueba de lectura y escritura aleatoria de bloques de 4 KB que se parece a la carga de una base de datos:

sudo apt install fio
fio --name=randrw --filename=/tmp/fio.test --size=2G --rw=randrw --bs=4k \
    --ioengine=libaio --iodepth=32 --numjobs=4 --direct=1 \
    --runtime=60 --time_based --group_reporting
rm /tmp/fio.test

Fíjate en los valores IOPS y en los percentiles de latencia (clat percentiles), no solo en la media. Ejecuta las mismas pruebas en cada opción que estés valorando y a distintas horas del día: la variación entre ejecuciones te dice tanto como el valor medio.

Coste: cómo compararlo bien

El precio de la máquina es solo una parte. Para comparar, calcula el coste mensual de tu carga real en cada modelo:

• VPS y dedicado: cuota fija, más el tráfico si supera lo incluido, IPs adicionales y backups.
• Cloud: horas de instancia, discos (por GB y a veces por IOPS), tráfico de salida, balanceadores, IPs públicas, snapshots y cada servicio gestionado.

Algunas reglas que suelen cumplirse:

• Para una carga constante 24/7, el pago por uso del cloud es el más caro; un VPS o un dedicado dan más recursos por el mismo dinero.
• Si la carga es muy variable (picos de pocas horas, trabajos por lotes, entornos que solo existen durante las pruebas), pagar por uso puede salir más barato que dimensionar para el pico.
• A partir de cierto tamaño (muchos núcleos, cientos de GB de RAM, discos rápidos grandes), un dedicado suele ser más barato que un VPS o una instancia equivalente.
• El tiempo de tu equipo también cuesta: un servicio gestionado caro puede compensar si ahorra horas de administración.

Escalado y disponibilidad

VPS. Escalas verticalmente cambiando de plan, lo que normalmente implica un reinicio. Para escalar horizontalmente necesitas varias máquinas, un balanceador y que tu aplicación no guarde estado en el disco local.

Dedicado. Crecer significa pasar a una máquina mayor o añadir otra, con días de margen si el hardware no está en stock. Un fallo de disco o placa deja el servidor parado hasta la reparación, así que para servicios críticos necesitas al menos dos servidores y réplicas.

Cloud. El autoescalado añade y quita instancias según métricas, y repartirlas en varias zonas protege frente a la caída de un centro de datos. Pero no es automático: la aplicación tiene que estar diseñada para ello (sin estado local, sesiones compartidas, base de datos replicada).

En los tres casos, la alta disponibilidad es una propiedad de tu arquitectura, no del producto. Un único servidor, sea del tipo que sea, es un punto único de fallo.

Seguridad y aislamiento

• En un VPS o en el cloud el aislamiento lo da el hipervisor. Es suficiente para casi cualquier carga, pero algunas normas o clientes exigen hardware exclusivo.
• En un dedicado nadie más ejecuta código en tu máquina, lo que simplifica ciertas auditorías. A cambio, eres responsable de actualizar firmware y BIOS.
• En el cloud la mayoría de incidentes vienen de errores de configuración: permisos de API demasiado amplios, buckets públicos o grupos de seguridad abiertos. La superficie de configuración es mayor.

La responsabilidad de mantener actualizado el sistema operativo, configurar el cortafuegos y proteger SSH es tuya en los tres modelos, salvo en los servicios gestionados.

Cómo elegir

Elige un VPS si:

• Empiezas un proyecto o tu carga cabe en unos pocos núcleos y unos GB de RAM.
• Quieres una factura predecible y control total del sistema.
• Tu tráfico es relativamente estable o crece de forma gradual.

Elige un servidor dedicado si:

• Tu carga usa CPU, RAM o disco de forma intensa y constante (bases de datos grandes, compilación, análisis de datos, servidores de juegos).
• Necesitas rendimiento predecible sin vecinos, hardware concreto (GPU, muchos discos NVMe) o ejecutar tu propio hipervisor.
• Has medido que el steal time o las IOPS de un VPS limitan tu aplicación.

Elige cloud elástico si:

• Tu tráfico tiene picos grandes e impredecibles, o necesitas crear y destruir entornos a menudo.
• Tu equipo prefiere servicios gestionados (bases de datos, colas, almacenamiento de objetos) a administrar servidores.
• Necesitas presencia en muchas regiones y tu aplicación ya está diseñada para escalar horizontalmente.

Muchas infraestructuras combinan varias opciones: servidores dedicados para la base de datos, VPS para la capa web y el cloud para picos o para almacenamiento de objetos. Es una buena forma de pagar rendimiento donde hace falta y flexibilidad donde aporta.

Cómo migrar entre opciones

Si empiezas en un VPS y te quedas corto, la migración a un dedicado o a otra plataforma es más fácil si preparas la aplicación desde el principio:

1. Guarda la configuración del servidor como código (Ansible, cloud-init o scripts versionados) para poder reconstruirlo en otra máquina.
2. Separa los datos de la aplicación: base de datos con copias de seguridad probadas y ficheros de usuario en un volumen o almacenamiento de objetos.
3. Reduce el TTL de tus registros DNS unos días antes para que el cambio de IP se propague rápido.
4. Replica la base de datos hacia el servidor nuevo, sincroniza los ficheros con rsync y cambia el DNS cuando todo esté verificado.

Conclusión

No hay una opción mejor en general: un VPS es el punto de partida razonable para la mayoría de proyectos, un servidor dedicado compensa cuando la carga es grande y constante, y el cloud elástico cuando la demanda varía mucho o quieres delegar la operación en servicios gestionados. Antes de decidir, mide tu carga real con vmstat, sysbench y fio, calcula el coste mensual completo en cada modelo y diseña la arquitectura para que cambiar de opción más adelante no sea un problema. En CubePath puedes empezar con un VPS y pasar a un servidor dedicado cuando tus mediciones lo justifiquen.