Comparativa técnica de VPS, cloud y servidor dedicado: aislamiento, IOPS, escalado, coste y casos de uso, con benchmarks medidos en nuestro CPD de Madrid.
Un VPS es una máquina virtual con recursos garantizados sobre un único host; un servidor cloud es esa misma máquina virtual sobre un clúster de hipervisores, con escalado en caliente y reinicio automático en otro nodo si falla el hardware; un servidor dedicado es hardware físico exclusivo, sin vecinos y sin capa de virtualización.
Las cuatro opciones resuelven el mismo problema —ejecutar una aplicación con disponibilidad y rendimiento suficientes— pero reparten de forma distinta tres cosas: el aislamiento de los recursos, la capacidad de crecer y el trabajo de administración que queda del lado del cliente. La tabla resume los doce criterios que, en nuestra experiencia atendiendo migraciones, deciden realmente la elección. Ninguno de ellos es el precio en primer lugar: el coste suele ser consecuencia de los otros once.
Conviene leerla en dos pasadas. La primera, buscando los criterios que son innegociables en su caso: si el software se licencia por núcleo físico, la fila de licenciamiento decide sola; si no puede permitirse una parada por fallo de host, decide la fila de alta disponibilidad. La segunda pasada sirve para ajustar dimensionado y presupuesto, y para eso está el selector de carga que aparece más abajo. Los precios de partida son los publicados por Aclass sin IVA.
Una advertencia sobre la lectura comercial de estos criterios: los nombres comerciales no son fiables. Hay productos anunciados como cloud que se ejecutan sobre un host aislado con disco local, y productos anunciados como VPS que corren sobre un clúster con cabina compartida y reinicio automático. Lo que define el modelo es la arquitectura que hay detrás, no la etiqueta del catálogo, y las filas de alta disponibilidad, migración en vivo y ventana de mantenimiento son las que revelan de qué se trata en cada caso.
| Criterio | VPS | Servidor cloud | Servidor dedicado | Hosting compartido |
|---|---|---|---|---|
| Aislamiento de recursos | vCPU, RAM y disco garantizados por hipervisor | Recursos garantizados sobre clúster, sin sobreventa | Aislamiento físico total, hardware exclusivo | Recursos compartidos con límites por cuenta |
| Escalado | Vertical, normalmente con reinicio | CPU y RAM en caliente; disco ampliable sin migrar | Requiere intervención física y ventana de parada | Solo cambio de plan |
| IOPS de disco | NVMe compartido con límite por instancia | NVMe con cola dedicada por instancia | NVMe local, sin vecinos | NVMe compartido y limitado por cuenta |
| Alta disponibilidad ante fallo de host | No: la instancia cae con el host | Sí: reinicio automático en otro nodo del clúster | No, salvo réplica contratada aparte | Depende del plan del proveedor |
| Snapshots | Sí, manuales | Sí, manuales y programados | Solo con software de terceros | No, copia del alojamiento a nivel de plan |
| Migración en vivo entre nodos | No | Sí, sin cortar el servicio | No | No aplica |
| IP fija | Sí, IP española | Sí, IP española, se conserva al escalar | Sí, IP española | IP compartida del servidor |
| Acceso root o administrador | Sí | Sí | Sí, incluido el nivel de hardware | No, solo panel de control |
| Ventana de mantenimiento | Reinicio necesario en tareas de host | Sin parada: la instancia se mueve de nodo | Parada planificada para firmware o piezas | Ventanas del proveedor |
| Licenciamiento | Por vCPU asignada | Por vCPU asignada, ajustable al escalar | Por núcleo físico, más caro en software de pago | Incluido en el plan |
| Nivel técnico requerido | Alto si es no gestionado; bajo en modalidad gestionada | Alto si es no gestionado; bajo en modalidad gestionada | Alto, incluye decisiones de hardware | Bajo |
Un VPS (servidor privado virtual) es una máquina virtual que se ejecuta sobre un servidor físico gestionado por un hipervisor. El hipervisor reparte el hardware entre varias máquinas virtuales y asigna a cada una una porción de procesador, memoria y disco. Desde dentro, el sistema operativo se comporta como si estuviera solo: tiene su propia dirección IP, su propio arranque, su propio cortafuegos y acceso administrativo completo. La diferencia con un servidor físico está en que el hardware subyacente se comparte, aunque los recursos asignados no se compartan.
Es el modelo que resuelve la mayoría de los proyectos que se han quedado pequeños en un plan de alojamiento compartido: una web corporativa con tráfico creciente, una aplicación interna, un entorno de integración continua o un servidor de aplicaciones que necesita una versión concreta de lenguaje o de librería. Tiene sentido cuando la carga es previsible, cuando se necesita control sobre el sistema operativo y cuando no hay un requisito estricto de continuidad ante un fallo de hardware.
La distinción práctica entre un VPS serio y uno barato está en la sobreventa. En una plataforma sin sobreventa, la suma de vCPU y memoria asignada a las máquinas de un host no supera lo que el host puede entregar, de modo que el rendimiento observado por la aplicación se mantiene estable a lo largo del día. En una plataforma sobrevendida, el vecino ruidoso existe: los mismos 4 vCPU rinden distinto a las 3 de la madrugada que a las 11 de la mañana. El indicador que conviene vigilar es el steal time de la CPU; por encima de valores residuales significa que el host no puede atender a todas sus máquinas.
Un VPS no gestionado exige un perfil de administrador de sistemas: hay que instalar y actualizar el sistema operativo, configurar el cortafuegos y los accesos por clave, montar el servidor web y la base de datos, vigilar los registros y responder a los incidentes. Si nadie del equipo puede hacer eso con soltura, el VPS no gestionado acaba siendo un riesgo de seguridad, no un ahorro. La modalidad gestionada traslada ese trabajo al proveedor: parcheado, monitorización de servicios, revisión de capacidad y respuesta ante incidencias por parte de un equipo de nivel 2-3. La frontera práctica suele estar en si su empresa tiene una persona capaz de aplicar un parche crítico un viernes por la tarde; si la respuesta es no, lo razonable es la modalidad gestionada o apoyarse en un servicio de consultoría IT .
Las dos limitaciones que se notan en producción son la disponibilidad y el escalado. Si el host falla, la máquina virtual cae con él y vuelve cuando el host vuelve; no hay reinicio automático en otro nodo. Y ampliar CPU o memoria suele implicar un reinicio corto, que en una web pequeña es irrelevante pero en un ERP corporativo obliga a planificar ventana. A esto se añade el techo del host: no se puede crecer más allá de lo que la máquina física ofrece.
Un servidor cloud es, desde dentro, exactamente lo mismo que un VPS: una máquina virtual con su sistema operativo y sus recursos asignados. La diferencia no está en la máquina, sino en la plataforma que la sostiene. En lugar de un host aislado, hay un clúster de hipervisores con almacenamiento compartido y una capa de orquestación que sabe en qué nodo se está ejecutando cada instancia y puede moverla. Esa capa es la que aporta las tres propiedades que un VPS clásico no tiene: alta disponibilidad, escalado en caliente y mantenimiento sin parada.
Por eso la pregunta habitual —«cloud VPS o VPS normal»— tiene una respuesta corta: si su proveedor ejecuta las máquinas sobre un clúster con almacenamiento compartido, está contratando cloud aunque el producto se llame VPS. Lo que conviene comprobar antes de firmar es si existe reinicio automático en otro nodo, si el disco es local al host o está en cabina compartida, y si el escalado de CPU y memoria requiere reinicio.
En un clúster, la caída de un nodo se detecta en segundos y las máquinas que se ejecutaban en él se reinician en otro nodo con capacidad libre. No es continuidad absoluta —hay un arranque del sistema operativo de por medio— pero convierte una avería de hardware de varias horas en una interrupción de minutos, sin intervención humana ni restauración de copias.
El escalado en caliente permite añadir vCPU y memoria a una máquina en ejecución cuando el sistema operativo lo soporta, y ampliar el disco extendiendo el volumen sin mover datos. En la práctica, esto significa que una tienda puede duplicar recursos la semana del Black Friday y volver a su dimensionado en diciembre, conservando la misma IP y la misma configuración.
La migración en vivo mueve una máquina virtual de un nodo a otro sin apagarla, copiando su memoria mientras sigue trabajando. Su consecuencia práctica es que el mantenimiento del hardware —actualización de firmware, sustitución de memoria, ampliación del clúster— deja de necesitar ventana de parada para el cliente: se vacía el nodo, se interviene y se devuelve al servicio. Es la diferencia entre recibir un aviso de corte cada trimestre y no recibir ninguno.
Un servidor dedicado es una máquina física completa asignada a un solo cliente, sin capa de virtualización compartida con nadie. El cliente decide el sistema operativo y, según el proveedor, también la configuración de discos y de memoria. Es el modelo más antiguo de los cuatro y sigue teniendo escenarios en los que gana con claridad, aunque hoy sean minoría.
Conviene situar el modelo en su contexto actual. Hace una década, el dedicado era la única forma de obtener rendimiento predecible; hoy la virtualización sobre NVMe ha reducido tanto la penalización que la mayoría de las cargas de una pyme no distinguen entre una máquina virtual bien dimensionada y hierro propio. Lo que sí distingue es la operación: un dedicado obliga a pensar en repuestos, en garantías de hardware y en el tiempo que tarda un técnico en sustituir una pieza en el centro de datos. Por eso, cuando lo recomendamos, casi siempre es por un requisito concreto —licencias por núcleo, cumplimiento normativo o una carga que satura de forma continua— y no por una preferencia general de rendimiento.
Cuando una carga consume el 100 % del hardware de forma sostenida —motores de base de datos grandes, procesamiento de vídeo, cálculo intensivo— la virtualización deja de aportar y su coste, aunque pequeño, se paga cada hora. El dedicado elimina cualquier vecindad y hace el rendimiento perfectamente predecible, lo que también simplifica el dimensionado.
Parte del software empresarial se licencia por núcleo físico, no por vCPU. En esos casos, el cálculo del coste cambia por completo y a veces invierte la comparación: un dedicado con pocos núcleos rápidos puede resultar más barato en licencias que una máquina virtual con muchas vCPU. Es el criterio que más veces obliga a descartar el cloud en proyectos que, por lo demás, encajarían perfectamente.
El coste mensual del dedicado suele parecer inferior a igualdad de recursos, pero el coste total incluye lo que no aparece en la factura: la redundancia hay que contratarla aparte, la recuperación ante un fallo de disco es manual, el crecimiento obliga a sustituir la máquina y la capacidad se compra por adelantado aunque solo se use en picos. En cargas variables, esa diferencia se come el ahorro.
Ninguno de los proveedores que ocupan las primeras posiciones para estas búsquedas publica resultados de rendimiento propios: se limitan a adjetivos. Nosotros publicamos únicamente las cifras confirmadas por la operación diaria de la plataforma. Una cifra que no podemos sostener no es un dato, es publicidad, y por eso no aparece en esta tabla.
El criterio que aplicamos para publicar una cifra es simple: debe corresponder al comportamiento real de la plataforma en producción, no a la ficha técnica del fabricante, que describe el disco en condiciones de laboratorio y no el rendimiento que llega a una máquina virtual con carga real. Si necesita una medición sobre su propia aplicación, la hacemos en una máquina de prueba antes de contratar y le entregamos el resultado por escrito.
Los IOPS de lectura y escritura aleatoria de bloque pequeño son el indicador que mejor predice el comportamiento de una base de datos, porque reproducen el patrón real de acceso de un motor transaccional. La plataforma de Aclass utiliza almacenamiento NVMe con más de 500.000 IOPS, y el valor que importa al cliente es el que llega a su máquina virtual con su propia carga: esa medición la hacemos sobre una instancia de prueba antes de contratar.
La latencia hacia usuarios situados en la península se mantiene por debajo de 5 ms desde nuestro CPD de Madrid. En una aplicación web con decenas de peticiones por página, cada milisegundo de ida y vuelta se multiplica, y esa es la razón real por la que un proveedor local rinde mejor que uno con la región en Fráncfort o Irlanda para público español.
El tiempo de aprovisionamiento de una instancia nueva y el tiempo que tarda en aplicarse una ampliación de CPU o memoria son las dos métricas operativas que más se notan en el día a día. Ambas se acuerdan por escrito en el contrato de servicio, con la ventana de intervención aplicable a cada tipo de cambio.
Nuestra referencia es conocida: 36 €/mes sin IVA para la instancia de entrada, con administración del sistema operativo incluida en la modalidad gestionada y soporte de nivel 2-3 en español, sin centro de atención intermedio. La infraestructura es propia y está alojada en un CPD Tier III de Madrid, de modo que el equipo que atiende una incidencia es el mismo que administra el hardware.
| Métrica | Resultado medido |
|---|---|
| IOPS de lectura aleatoria 4K | Más de 500.000 IOPS en el almacenamiento NVMe de la plataforma |
| Latencia media de red desde Madrid | Inferior a 5 ms hacia usuarios situados en la península |
La tarifa publicada de servidores de Aclass se articula en planes de 36, 44, 46, 59,90, 61, 74 y 90 €/mes sin IVA, según la combinación de vCPU, memoria y disco NVMe. El plan de entrada de 36 €/mes cubre una web corporativa o un entorno de preproducción; los tramos intermedios, entre 59 y 78 €/mes, corresponden al dimensionado típico de una tienda online con picos; y las configuraciones de ERP, CRM o base de datos se sitúan entre 95 y 150 €/mes. El hosting en Madrid parte de 55 €/año sin IVA para los proyectos que todavía no necesitan servidor propio.
Lo que no aparece en ninguna tarifa, y sin embargo decide el coste real, son cuatro partidas: las horas de administración del sistema (nulas en la modalidad gestionada, significativas en la no gestionada), las licencias de software, la capacidad que se compra para el pico y se paga todo el año, y el coste de una parada no planificada. Un dedicado veinte euros más barato al mes que un cloud deja de serlo la primera vez que una fuente de alimentación obliga a cuatro horas de parada en horario laboral.
Nuestra recomendación es hacer el cálculo a doce meses e incluir esas cuatro partidas. En la mayoría de las comparaciones que hemos hecho con clientes, el cloud gestionado gana en cargas variables y en empresas sin administrador de sistemas propio, mientras que el dedicado sigue ganando en cargas constantes con licenciamiento por núcleo físico. Los importes citados no incluyen IVA ni ningún otro impuesto aplicable.
El criterio útil no es el tamaño de la empresa, sino el perfil de la carga: cuántos usuarios concurrentes hay, cómo de variable es el tráfico y qué pasa si el servicio se detiene una hora. El selector siguiente aplica exactamente las reglas que usamos en una llamada de dimensionado, con los tramos de precio ya publicados.
Antes de tocar el selector conviene reunir tres datos del entorno actual: el pico real de CPU y memoria de los últimos noventa días, el tamaño de la base de datos y del conjunto de ficheros, y el número máximo de sesiones simultáneas registrado. Con esos tres números el dimensionado deja de ser una conversación de opiniones. Si no dispone de histórico, la alternativa razonable es empezar por la instancia de entrada y escalar en caliente en cuanto la monitorización muestre saturación sostenida, algo que en cloud no cuesta ni una parada ni una migración.
Una web corporativa con contenido gestionado, formularios y algún módulo de catálogo funciona holgadamente con dos núcleos y cuatro gigabytes si el conjunto está bien cacheado. Por debajo de veinte usuarios simultáneos y sin requisito de continuidad, el hosting gestionado es suficiente; a partir de ahí, la instancia de entrada de 36 a 46 €/mes aporta acceso root, snapshots propios y libertad de versiones.
Una tienda añade dos consumos que una web corporativa no tiene: sesiones de usuario y consultas de catálogo con filtros. Cuatro núcleos y ocho gigabytes soportan el tráfico habitual, y el escalado en caliente permite doblar recursos durante la campaña. El rango publicado para este dimensionado es de 59 a 78 €/mes sin IVA.
Aquí manda la memoria, porque el motor de base de datos la usa como caché, y los IOPS de escritura aleatoria. Ocho núcleos, dieciséis gigabytes y 150 GB de NVMe cubren el caso típico de una pyme con entre veinte y cien usuarios internos, en el rango de 95 a 150 €/mes sin IVA. Si el servicio no puede detenerse, la instancia debe estar en clúster, nunca en un VPS aislado. En este escenario conviene revisar también el puesto de trabajo: los escritorios virtuales VDI eliminan la latencia entre el cliente y la base de datos al colocarlos en el mismo CPD.
El configurador interactivo recomienda modelo, dimensionado y rango de precio a partir del tipo de carga (web corporativa, tienda online, ERP o entorno de pruebas), los usuarios simultáneos y la necesidad de alta disponibilidad.
Una migración bien hecha no se nota. El procedimiento que seguimos tiene cinco pasos y ninguno es opcional. Primero, inventario: versiones de sistema operativo, lenguaje y base de datos, servicios activos, tareas programadas, certificados y registros DNS con sus TTL. Segundo, réplica: se levanta la máquina destino con la configuración equivalente y se despliega la aplicación, sin tocar el origen.
Tercero, sincronización de datos: se copia el grueso con antelación y se deja un delta pequeño para el momento del cambio, de modo que la última sincronización dure minutos y no horas. Cuarto, ensayo: se prueba la máquina destino con el dominio real forzado en el fichero de hosts, se revisan permisos, rutas absolutas, envío de correo y trabajos programados. Quinto, conmutación: se baja el TTL del DNS con antelación, se hace la sincronización final y se cambia el registro; el tráfico se desplaza en la ventana del TTL.
Durante las semanas siguientes conviene mantener la máquina de origen apagada pero disponible, y vigilar registros de error, consumo de CPU y tiempos de respuesta. La copia de seguridad no forma parte de este procedimiento: es un servicio aparte con su propia política de retención. Además, mantener el origen accesible permite recuperar cualquier fichero olvidado sin reabrir una copia de seguridad, algo que ocurre con más frecuencia de la esperada en entornos con años de historia.
Dos detalles técnicos evitan la mayoría de los sustos. El primero es el TTL: bajarlo a trescientos segundos con al menos veinticuatro horas de antelación garantiza que la conmutación se propague en minutos y no en un día completo. El segundo son los certificados: conviene emitirlos en la máquina destino antes del cambio, validando por DNS, para que el sitio responda por HTTPS desde el primer segundo. Con ambos resueltos, el corte efectivo se mide en el tiempo que tarda la última sincronización incremental, normalmente menos de cinco minutos. Si quiere ver cómo encaja este servicio con el resto de la plataforma, el hub de infraestructura IT reúne los seis servicios y sus dependencias.
La comparación se resuelve con tres preguntas: ¿puede pararse el servicio una hora?, ¿la carga es constante o tiene picos?, ¿el software se licencia por núcleo físico? Con esas respuestas, el modelo se elige solo. Si sigue dudando, lo más rápido es enseñarnos el consumo real de su servidor actual y dimensionar sobre datos, no sobre suposiciones. Nuestros servidores VPS desde 36 €/mes se contratan sin permanencia, con soporte en español y con la migración realizada por nuestro equipo; y si necesita presencia local con latencia mínima, la página de VPS en Madrid detalla la ubicación y las conexiones del CPD.