La elección entre VPS, servidor dedicado y nube depende sobre todo del perfil de la carga que va a soportar. Como regla práctica, un VPS cubre bien cargas pequeñas y estables, un servidor dedicado gana cuando el consumo es alto y constante o cuando hace falta aislamiento real, y la nube pública compensa cuando el trabajo es irregular, crece a saltos o solo existe unas horas al día. Equivocarse sale caro cuando se descubre dos años después, con el sistema ya crecido encima. Este artículo pone criterio a esa decisión carga por carga, con nuestra recomendación al final.
Qué es cada cosa
Un VPS (servidor privado virtual) es una máquina virtual con recursos asignados y acceso de administrador completo, que se ejecuta junto a otras máquinas virtuales sobre un mismo servidor físico. Tienes tu propio sistema operativo y tu configuración, pero compartes el hardware con otros clientes del proveedor.
Un servidor dedicado es una máquina física entera asignada a un único cliente. Nadie más compite por su CPU, su disco ni su red, y el control llega hasta el hipervisor, el firmware y el kernel.
La nube pública es capacidad de cómputo que se alquila por uso a un proveedor como AWS, Azure o Google Cloud. Las instancias se crean y se destruyen por API en minutos y se pagan por tiempo de uso, con servicios gestionados alrededor (bases de datos, balanceadores, almacenamiento de objetos) que evitan montar esas piezas a mano.
Queda una cuarta opción que se cita poco y que en pymes resuelve muchos casos, la nube privada. Es una plataforma de virtualización dedicada a una sola empresa que da elasticidad parecida a la de la nube pública dentro de un perímetro que controlas tú, y cuando el requisito es de soberanía del dato suele ser el punto de encuentro razonable.
En qué se diferencian de verdad
| Criterio | VPS | Servidor dedicado | Nube pública |
|---|---|---|---|
| Recursos | Compartidos, con sobresuscripción habitual | Exclusivos, sin vecinos | Exclusivos por instancia, según el tipo elegido |
| Coste | Cuota baja y fija | Cuota alta y fija | Variable, según consumo |
| Elasticidad | Redimensionar implica reinicio y plan superior | Rígida, cambiar hardware lleva días | Minutos, por API o automática |
| Rendimiento sostenido | Irregular si hay vecinos ruidosos | El más predecible | Predecible dentro del tipo de instancia |
| Dónde encaja | Cargas pequeñas y estables | Carga alta constante, bases de datos pesadas, aislamiento | Picos, proyectos nuevos, entornos efímeros |
Hay un detalle técnico que decide más discusiones que la tabla entera. En un VPS, la vCPU no es un núcleo físico, sino una porción de tiempo de uno, y el proveedor vende más porciones de las que hay. Cuando el servidor físico va cargado, tu máquina espera y ese tiempo de espera aparece en el sistema operativo como steal time. Si tus gráficas muestran steal time apreciable de forma sostenida, añadir RAM no lo arregla y la salida es dejar ese hardware compartido.
Qué conviene a cada carga
Web corporativa, intranet y aplicaciones internas
Consumo modesto, previsible y con horario de oficina. Un VPS bien dimensionado sobra, y pasarlo a nube pública solo añade factura y complejidad. Aquí marca la diferencia que la máquina esté actualizada, con hardening aplicado tomando como referencia los CIS Benchmarks y con copias probadas.
Bases de datos y ERP
Es la carga que más sufre en compartido. Necesita memoria abundante, latencia de disco baja y estable, y CPU que no desaparezca a media consulta. Un servidor dedicado con NVMe local es la respuesta habitual, y suele ser el primer sistema que sale de un VPS cuando la empresa crece.
Cargas con picos marcados
Campañas, temporada alta o cierres contables que multiplican el consumo unos días al mes. Dimensionar hardware fijo para el pico significa pagar todo el año por una capacidad que se usa una semana. La nube pública está hecha para esto, siempre que la aplicación aguante arrancar y parar instancias sin perder estado.
Desarrollo, pruebas e integración continua
Entornos que existen unas horas y se destruyen. En nube pública salen casi gratis si se apagan de verdad al terminar; en un servidor propio se comen recursos que hacían falta en producción. El error clásico es crear la máquina de pruebas y dejarla encendida un año.
Datos regulados o que no deben salir
Historiales, datos de personal o información sujeta a contrato con un cliente. La decisión deja de ser técnica y pasa a ser de soberanía del dato, y ahí la nube privada sobre hardware dedicado evita explicaciones incómodas en una auditoría.
El coste real no es la cuota mensual
La comparación honesta incluye tres partidas que no aparecen en el catálogo. La primera es la operación, es decir parches, monitorización, gestión de copias y alguien que responda cuando algo se rompe un domingo; existe en las tres opciones y en el dedicado es mayor, porque el hardware también falla. La segunda es el sobredimensionamiento, porque nadie se atreve a bajar de plan sin datos. Y la tercera, en nube pública, el tráfico de salida y el almacenamiento acumulado.
En la nube el control de gasto es una disciplina en sí misma, FinOps, y consiste en revisar cada mes qué recursos siguen encendidos, qué instancias están sobredimensionadas y qué datos podrían estar en un almacenamiento más barato. Sin esa revisión, una migración que empezó siendo barata acaba costando más que el servidor que sustituyó. La aritmética completa entre invertir en hardware y pagar por uso la desarrollamos en nube o servidor propio, comparativa con cifras.
Qué usamos nosotros y por qué
Para una pyme con varios sistemas en marcha partimos de una nube privada sobre Proxmox en hardware dedicado. Con eso obtenemos el rendimiento y el aislamiento del dedicado, la comodidad de crear y mover máquinas en minutos, y un coste que no depende del número de servidores que haga falta levantar. Encima van copias con retención y una parte inmutable, monitorización con opción de guardia 24/7 para incidencias críticas, y RTO y RPO acordados por sistema en lugar de una promesa genérica de disponibilidad.
A partir de ahí, matizamos. Dejamos en VPS las piezas pequeñas que conviene tener separadas y cuya caída no para el negocio. Usamos nube pública para lo genuinamente elástico, para réplicas fuera de la sede y para servicios gestionados que no compensa montar a mano. Y reservamos el dedicado sin virtualizar para bases de datos muy exigentes y licencias que se cobran por socket físico. Lo que no hacemos es mover todo a un único modelo porque toque, ya que casi ninguna pyme tiene una sola clase de carga.
Un escenario típico: el ERP que se quedó sin sitio
Una distribuidora industrial de unas sesenta personas con el ERP, su base de datos, la web corporativa y el portal de pedidos repartidos en cuatro VPS contratados en momentos distintos. El día a día funcionaba, pero cada cierre de mes el ERP se arrastraba durante horas y los comerciales no podían consultar existencias. El proveedor respondía que el consumo estaba dentro de lo contratado, y era cierto. La máquina no llegaba a saturarse, se quedaba esperando. El steal time del VPS de la base de datos subía a niveles altos justo esos días.
Se separaron los sistemas por perfil de carga. La base de datos y el ERP pasaron a hardware dedicado con discos NVMe y memoria suficiente para que el conjunto de trabajo cupiera en RAM. La web y el portal se quedaron donde estaban. Y los informes nocturnos, que eran lo que más CPU pedía y solo corrían unas horas, se movieron a instancias de nube que se crean y se destruyen solas.
El cierre de mes dejó de ser un problema y la factura de infraestructura apenas cambió, porque los dos VPS sobredimensionados que se dieron de baja pagaron buena parte del servidor nuevo. El cambio de fondo fue dejar de tratar cuatro cargas distintas como si fueran la misma.
Errores habituales al elegir
- Comparar por precio de catálogo. Dos ofertas con las mismas vCPU y la misma RAM rinden muy distinto según la sobresuscripción y el tipo de disco. Sin una prueba con tu carga real, la comparación no dice nada.
- Confundir vCPU con núcleo físico. Ocho vCPU en compartido no equivalen a ocho núcleos exclusivos, y en bases de datos la diferencia se nota enseguida.
- Dar por hecho que la nube incluye copias. No las incluye. Las instantáneas del proveedor viven junto al original y se borran con las mismas credenciales; hacen falta copias con retención, una parte inmutable y una prueba de restauración periódica.
- Migrar tal cual y esperar ahorro. Llevar las máquinas a la nube sin rediseñar nada conserva el sobredimensionamiento y le añade el coste del tráfico. La nube ahorra cuando algo se apaga; si nada se apaga, encarece.
- No contar la operación. Elegir dedicado sin prever quién aplica los parches, quién vigila la monitorización y quién sustituye un disco convierte una buena decisión técnica en un riesgo.
Por dónde empezar
Antes de mirar catálogos, reúne tres datos por cada sistema. El consumo real sostenido de CPU, memoria y disco durante un mes completo, no la impresión de que «va lento». Cuánto se separan el pico y el valle, porque de esa distancia sale si conviene capacidad fija o elástica. Y qué ocurre en el negocio si ese sistema se para dos horas, que es lo que traduce la decisión a un RTO y un RPO concretos.
Ese análisis es lo que hacemos en el diagnóstico previo de nuestros servidores gestionados, midiendo lo que ya tienes antes de proponer nada. Si el cierre de mes se te está haciendo largo o llevas tiempo sospechando que pagas por capacidad que no usas, cuéntanos qué sistemas tienes y cómo se comportan.
Si ya tienes claro que tu carga pide hardware para ella sola, el siguiente paso es elegirlo bien, y lo desglosamos en nuestra guía express de servidores dedicados.