La máquina parece estar bien. La carga media es razonable, la memoria no está agotada, el disco tiene espacio. La aplicación sigue lenta a las 9 de la mañana cada día laborable y nadie sabe decir por qué. O alguien te ha dado una frase en lugar de una métrica: «necesitas hardware dedicado para esto».
La cuestión de VPS frente a servidor dedicado se decide con un puñado de señales que puedes medir. En mi experiencia, la mayoría de las cargas de trabajo que llegan aquí no disparan ninguna. Ambas compras son legítimas, y un servidor dedicado es la respuesta correcta cuando se cumplen condiciones concretas.
La versión corta
- El salto al hardware dedicado se justifica cuando se dispara una señal concreta, no cuando una máquina simplemente parece lenta.
- Importan tres señales operativas: utilización de CPU sostenida sin margen restante, steal time de CPU o IO wait persistentes, y una carga de trabajo que ha superado la instancia más grande que vende un proveedor.
- Dos de esas tres señales vienen a menudo del proveedor o del plan, no de la virtualización. Compruébalo antes de gastar.
- PCI DSS y la HIPAA Security Rule especifican resultados de aislamiento y control, no un formato de hardware. Ninguno por sí solo exige una máquina física.
- El hardware dedicado solo gana en coste con una utilización sostenida alta. Por debajo de eso, pagas un suelo de hardware fijo que no estás usando.
Qué diferencia a un VPS de un servidor dedicado
Toma un plan que anuncia 4 vCPU. En un servidor dedicado, cuatro núcleos son tuyos los uses o no. En un VPS, cuatro vCPU son una promesa de planificación: el hipervisor presenta cuatro procesadores virtuales a tu kernel y les da tiempo en núcleos físicos según su política y la carga actual del host.
En condiciones normales, ambos se comportan igual. Bajo contención, no.
La diferencia no es virtual frente a físico. Es lo que se te garantiza frente a lo que se te asigna.
El modelo de aislamiento sigue la misma división. Un VPS se aísla lógicamente, mediante el hipervisor: kernel propio, espacio de memoria propio, discos virtuales propios, impuestos por software que corre sobre silicio compartido. VPS frente a bare metal es una diferencia en dónde se traza esa frontera, no en si existe.
Ambos son aislamiento real. Fallan de forma distinta y se auditan de forma distinta, lo que importa en la sección de cumplimiento más abajo.
La sobrecarga del hipervisor rara vez es ya la historia. En un KVM moderno con extensiones de virtualización por hardware y controladores paravirtualizados, no he encontrado que el hipervisor sea el motivo de que una aplicación vaya lenta.
Si un VPS rinde por debajo de lo esperado, la causa habitual es la contención o el dimensionamiento.
La variable interesante vive en la contención, y es una política del proveedor, no una propiedad de la virtualización. La sobresuscripción consiste en vender entre los huéspedes más vCPU, más IOPS o más memoria de la que el host tiene físicamente, apostando a que no todos alcanzan su pico a la vez. Algunos proveedores apenas lo hacen. Otros lo hacen de forma agresiva.
La consecuencia incomoda a quien compra solo por categoría. Un VPS mal sobresuscrito y un VPS bien gestionado están más lejos en comportamiento que un VPS bien gestionado y un servidor dedicado.
El alojamiento compartido queda fuera de esta comparación: sin acceso root y sin garantía de recursos constante, y nuestra guía explica cuándo pasar del alojamiento compartido al VPS si ese paso te toca antes. La colocation queda fuera del alcance. Compras y posees el hardware, lo que es otro modelo de adquisición, con otros contratos y otra historia ante un fallo.
| Criterio | VPS | Servidor dedicado |
|---|---|---|
| Aislamiento de recursos | Lógico, impuesto por el hipervisor | Físico, inquilino único |
| Asignación de CPU | vCPU planificadas sobre núcleos físicos compartidos | Núcleos físicos, exclusivos |
| Contención de IO | Pool de almacenamiento compartido; la latencia varía con la carga del host | Discos locales, sin contención externa |
| Contención de red | Enlace ascendente compartido | NIC y puerto exclusivos |
| Control del hardware | Ninguno; el proveedor elige la plataforma | Total; generación de CPU, disposición de discos, RAID |
Las señales de que te has quedado corto con un VPS
Son comprobaciones contra tu propia telemetría, no reglas generales sobre tu sector. Una condición gobierna las tres: una señal solo cuenta cuando es sostenida.
Una máquina clavada al 95 % de CPU durante una ventana de copia de seguridad nocturna se comporta como debe. Una máquina clavada al 95 % de CPU durante quince días te está diciendo algo.
Utilización de CPU sostenida sin margen
La condición que hay que vigilar es una media móvil de días o semanas que no deja hueco para absorber un pico de tráfico, un proceso desbocado o una dependencia lenta. No una lectura de pico. Llegados ahí, los tiempos de respuesta se degradan de forma no lineal en vez de ceder con suavidad, y el siguiente incidente no tiene adónde ir.
La forma de la carga mueve la línea. Un consumidor de cola constante rozando su techo está más cerca del problema que un frontal web a ráfagas que pica dos veces al día y el resto del tiempo está ocioso. Lee tu propia curva en lugar de un número sacado de la página de un proveedor.
Estar limitado por CPU no es lo mismo que necesitar hardware dedicado. Lo primero se resuelve a menudo dentro de la virtualización: una instancia mayor, o una de mayor frecuencia cuando la carga es de un solo hilo y sensible a la latencia.
Confirma cuál de los dos tienes antes de pedir precio de una máquina física. Una aplicación de un solo hilo no va más rápida con 32 núcleos.
Steal time e IO wait
El steal time de CPU es el porcentaje de tiempo en que tu procesador virtual estaba listo para ejecutar y el hipervisor dio el núcleo físico a otro. Es el número que distingue una carga demasiado grande de un host demasiado lleno.
No trates un porcentaje concreto de steal time como un umbral. Observa la tendencia en tu propia máquina. Cerca de cero con picos ocasionales es normal. Constantemente distinto de cero y subiendo significa que el host está en contención.
Sostenido y alto en una carga sensible a la latencia significa que te están planificando de lado, y la aplicación lo paga.
Consejo: ejecuta vmstat 1 30 y vigila la columna st del bloque CPU; top muestra la misma cifra como %st. Toma la lectura durante tus horas punta reales, no una vez a medianoche. Un host sano tiene este aspecto:
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 412332 84120 1932144 0 0 0 12 842 1503 21 4 75 0 0
2 0 0 411980 84120 1932148 0 0 0 0 901 1622 24 5 71 0 0Uno en contención tiene este aspecto, y el tiempo que falta está en la última columna:
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 0 288104 61228 1104996 0 0 8 140 1502 2210 31 6 45 1 17
5 0 0 287960 61228 1105004 0 0 0 0 1610 2388 29 7 44 2 18Un steal time alto significa que ese host está sobresuscrito. Es una afirmación sobre tu proveedor y tu plan, no sobre la virtualización. La primera respuesta correcta es pasar a un host mejor aprovisionado o a un plan con vCPU dedicadas. Salir de la virtualización viene después, no en su lugar.
Si tu hallazgo es el steal time, el diagnóstico de sobreventa es el hilo del que tirar primero.
He sacado dos cargas de trabajo de un VPS por este motivo. Ninguna estaba limitada por CPU. Ambas estaban en hosts vendidos por encima de su capacidad, y a una de ellas solo le hacía falta otro proveedor.
El techo de escalado
Has tocado techo cuando la instancia más grande que vende el proveedor ya no basta para la carga, o cuando el último salto vertical dio bastante menos mejora que el anterior. El segundo caso pasa desapercibido con facilidad. Si duplicar la instancia compró un 20 % de mejora, la restricción se ha movido a un sitio al que más vCPU no llegan.
Los disparadores de almacenamiento son los que más veces sobreviven a la investigación, y suelen llegar disfrazados de base de datos. La restricción rara vez es el motor. Es la IO aleatoria sostenida sobre un pool que compartes con desconocidos.
Cualquier carga que lea y escriba bloques pequeños de forma continua (una base de datos cargada, una cola con persistencia duradera, un servicio con muchos logs) empuja ese pool con el patrón que peor gestiona.
Vigila %wa y tus propios percentiles de latencia durante la carga punta real. Si la latencia varía de formas que tu propia carga no explica, estás haciendo cola detrás de otros inquilinos, y unos discos que te pertenezcan son la solución fiable.
Dos de estas tres señales suelen resolverse sin salir de la virtualización, y comprobarlo sale más barato que comprar hardware.
Cuando el cumplimiento exige hardware dedicado
Un auditor escribe «el entorno de datos de titulares de tarjeta debe ejecutarse en hardware dedicado» y la frase hace dos cosas distintas según quién la lea. Para un profesional del cumplimiento suele significar un entorno aislado de otras cargas y con un alcance ajustado. Para quien compra alojamiento parece una categoría de producto.
En la brecha entre esas dos lecturas es donde se gasta presupuesto sin ganar ningún control.
Tanto PCI DSS como la HIPAA Security Rule especifican resultados de aislamiento y control en lugar de un formato. Si tu requisito es que un conjunto definido de sistemas esté segmentado, con control de acceso, registrado y evaluable de forma independiente, un entorno virtual bien segmentado lo cumple. Si tu requisito es que ningún código de otro inquilino se ejecute en el mismo silicio, solo lo cumple el hardware físico.
Determina cuál de las dos frases te han dado antes de pedir precio de nada.
Para PCI DSS, el concepto operativo es el alcance. La propia guía del Security Standards Council sobre alcance y segmentación de red fija como posición por defecto que todo está dentro del alcance hasta que se verifique lo contrario. Describe la segmentación como un método que puede reducir el número de componentes de sistema en el alcance. Ese suplemento no nombra ningún formato de hardware en ninguna parte de su texto.
Un entorno virtual mal segmentado todavía puede arrastrar al alcance mucha más de tu pila de lo que habías presupuestado. Ese es el coste de hacerlo mal, no un argumento en contra de hacerlo.
HIPAA es más explícita en su carácter basado en controles. El texto de la disposición de flexibilidad de enfoque de la HIPAA Security Rule, publicado por la Cornell Law School, señala que las entidades cubiertas y sus socios comerciales pueden emplear cualquier medida de seguridad que les permita implantar las normas de forma razonable y apropiada. La elección se juzga frente al tamaño de la organización, la infraestructura técnica, el coste y el riesgo. Es una prueba de idoneidad, no una especificación de equipos.
Para un despliegue alojado, el requisito operativo suele ser contractual. El texto del 45 CFR § 164.308(b)(1) publicado por la Cornell Law School señala que una entidad cubierta solo puede dejar que un socio comercial maneje información sanitaria protegida en formato electrónico tras obtener garantías satisfactorias de que se salvaguardará de forma apropiada. Un proveedor que no firme un acuerdo de socio comercial se descalifica solo, tenga el hardware que tenga.
Algunos casos son solo para dedicado. Un contrato con un cliente que estipula por escrito el aislamiento físico es uno de ellos.
Otro es un control que no puedes implementar sin acceso al hardware: cifrado completo del disco con una clave que guardas en un TPM que controlas, arranque seguro verificado, o una línea base de firmware que atestiguas tú mismo. En esos casos, compra el hardware y deja de evaluar.
Consejo: antes de aceptar «hardware dedicado» como requisito, pregunta a quien lo escribió qué control implementa y a qué sistemas se aplica. Con frecuencia la respuesta es un entorno aislado, acotado al entorno de datos de titulares de tarjeta, y no un producto de servidor dedicado. Los dos tienen precios muy distintos.
Los resultados de cumplimiento dependen de tu evaluador y de tu alcance concreto. Esto te da la pregunta correcta que hacerle, no una resolución que puedas esgrimir ante él.
Dónde se cruzan las curvas de coste
Dedicated hardware looks cheap per core, and at sufficient scale it is. Across providers publishing public bare metal pricing, entry configurations in the 6-core, 32 GB class typically start from around $150 to $200 per month, while 24-core, 256 GB machines with multi-terabyte NVMe commonly start from $450 and up.
Those are typical list-price ranges as of August 2026, not a market average. Price your own shortlist.
Fíjate en la forma y no en los números absolutos. El precio de un VPS es casi lineal respecto a los recursos asignados y prácticamente no tiene suelo, por eso una instancia de 1 GB cuesta unos pocos dólares. El precio del dedicado arranca en lo que cuesta una máquina física entera y luego sube despacio, porque el coste marginal de más núcleos dentro de un chasis que ya alquilas es bajo.
Dos rectas con pendientes distintas y ordenadas en el origen distintas se cruzan en un punto.
La utilización decide de qué lado de ese cruce estás. La recta del dedicado es fija: pagas 24 núcleos uses 24 o 4.
Una máquina dedicada al 20 % de utilización cuesta más por unidad de trabajo entregado que un VPS bien dimensionado, aunque la factura sea menor por núcleo. El denominador es lo que consumiste, no lo que te vendieron.
El punto de cruce no es «por encima de N núcleos». Es «por encima de N núcleos que mantienes ocupados».
Hay tres costes que no aparecen en ninguna de las dos facturas y que pertenecen a la comparación:
- Tiempo de aprovisionamiento. Un VPS está disponible en minutos. El hardware físico se pide, se enracka y se entrega en horas o días. Esa latencia es una restricción de planificación de capacidad, no una molestia puntual.
- Sin reducción de escala. Tras un pico de tráfico puedes reducir un VPS. Un servidor dedicado es un compromiso mensual a tamaño completo hasta que acabe el plazo del contrato.
- Fallo de hardware. Cuando un host falla debajo de ti en un VPS, el proveedor lo migra o lo restaura. Cuando falla un disco o una fuente en tu máquina dedicada, el camino de recuperación es un ticket de soporte y una restauración desde copia de seguridad, con la caída contando en tu propio SLA.
Cuando un VPS sigue siendo la respuesta correcta
No se disparó ninguna señal. La utilización tiene margen, el steal time está plano, el techo de tamaño de instancia queda lejos, ningún contrato exige aislamiento físico y tu uso no se acerca al cruce de costes. Quédate virtualizado.
Eso es una capacidad, no un premio de consolación. Los snapshots hacen reversible una actualización y comprobable una migración arriesgada. Instancias pequeñas separadas te dan separación de entornos a un precio que hace que valga la pena tener staging.
Y el fallo de hardware de las 3 de la madrugada es de otro, algo que para un equipo pequeño vale más que una diferencia en un benchmark.
La brecha se ha estrechado, y eso es un cambio en la tecnología, no un argumento de venta. Los planes con vCPU dedicadas, el NVMe por defecto y unos controladores paravirtualizados ya maduros han eliminado casi toda la distancia práctica de rendimiento para cargas de trabajo típicas.
La longevidad del proveedor va en la lista corta al lado de las especificaciones. Un plan VPS que puedes abandonar en una tarde conlleva menos riesgo de proveedor que un contrato de hardware a doce meses. Eso solo se sostiene si el proveedor sigue ahí y sigue respondiendo tickets en el mes nueve. Comprueba cuánto tiempo lleva operando, cómo publica su historial de incidentes y cómo responde el soporte antes de una caída, no durante.
También existe el alojamiento dedicado gestionado, que cambia control del hardware por menos carga operativa, lo cual está en el mismo eje que la decisión entre gestionado y no gestionado un escalón más abajo.
Quedarse en un VPS es una decisión activa, con su propia ruta de escalado, no la opción por defecto en la que aterrizas por no elegir.
Si tu diagnóstico fue contención y no capacidad, la compra que te toca es un VPS, no un chasis. Lo que quieres con él es la libertad de volver a bajar de tamaño después del evento que te trajo hasta aquí. Ese es el caso para el que construimos: nuestro Linux VPS funciona sobre almacenamiento NVMe con un SLA de disponibilidad del 99,95 % y facturación por horas. Probar una instancia mayor o de mayor frecuencia te cuesta una tarde en lugar de un contrato. Dimensiónala frente a los umbrales de arriba, pásale tu propio pico y vuelve a mirar el steal time.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxPreguntas frecuentes
¿Cuánto más rápido es un servidor dedicado que un VPS?
Depende del recurso por el que estés compitiendo. Con la virtualización moderna, la diferencia de CPU en un host bien aprovisionado es pequeña, porque la sobrecarga del hipervisor es mínima con las extensiones de virtualización por hardware. Las diferencias fiables son la ausencia de contención de IO y de red, que se notan como consistencia de latencia más que como velocidad bruta. Si tu carga nunca compite por disco o red en el pico, espera una diferencia lo bastante pequeña como para no decidir la compra.
¿Basta un VPS para una base de datos en producción?
Para la mayoría de bases de datos en producción, sí. La restricción determinante suele ser la IO aleatoria sostenida sobre almacenamiento compartido, no el motor de base de datos. Una base que lee y escribe bloques pequeños de forma continua alcanzará el límite de un pool compartido mucho antes que el del motor. Los discos dedicados quitan ese límite; una instancia mayor no.
¿Exige PCI DSS un servidor dedicado?
No, no como regla general. PCI DSS especifica requisitos de aislamiento y control acotados al entorno de datos de titulares de tarjeta, no un formato de hardware. La guía de alcance del Security Standards Council trata todo como incluido hasta que se verifique lo contrario y describe la segmentación de red como un método para reducir los sistemas en el alcance. Un entorno virtual bien segmentado puede cumplirlo; uno mal segmentado mete mucha más de tu pila dentro del alcance.
¿Cómo sé si mi VPS tiene un problema de vecino ruidoso?
El síntoma es rendimiento inconsistente en el pico sobre una máquina que por lo demás no está ocupada: tiempos de respuesta que oscilan mientras tu carga, memoria y uso de disco se mantienen planos y sin nada raro. Las horas tranquilas parecen normales, y por eso el problema sobrevive tanto tiempo sin diagnosticar. La causa está en el host físico que compartes, así que la solución es un plan mejor aprovisionado u otro proveedor, no reescribir tu aplicación.
¿Cuándo debo pasar de un VPS a un servidor dedicado?
Upgrade when at least one of these holds: CPU utilization sits at a rolling-average level that leaves no headroom for a traffic event; steal time or IO wait stays high after you have already tried a better-provisioned plan; the workload has outgrown the largest instance your provider sells; a contract or a control genuinely requires physical isolation; or sustained utilization is high enough that a fixed hardware cost beats per-resource pricing.
