VPS vs cloud vs dedicado: cómo elegir con criterios reales
Actualizado el 28 de octubre de 2026 · Guía para empresas en México
Elegir entre VPS, cloud y servidor dedicado no consiste en ordenar tres productos de menor a mayor calidad. Un VPS describe una máquina virtual; cloud describe un modelo de provisión y servicios; dedicado describe el uso exclusivo de un servidor físico. Por eso una máquina virtual cloud también puede cumplir el papel de un VPS, y una infraestructura cloud puede ofrecer hardware dedicado.
La definición de cloud computing del NIST lo presenta como un modelo de acceso y provisión de recursos, no como una garantía universal de continuidad.
La decisión útil es otra: qué necesita tu aplicación, cómo crecerá y cómo seguirá operando cuando algo falle. Esta guía permite separar esas preguntas, comparar propuestas equivalentes y documentar una elección. No sustituye una prueba de tu aplicación ni garantiza un plazo de migración.
Tres dimensiones distintas, no tres niveles de calidad
Antes de pedir una cotización, separa aislamiento físico, forma de ampliar capacidad y recuperación ante fallos. Una etiqueta comercial no demuestra las tres.
- Aislamiento: ¿quién comparte el equipo físico?
- En un VPS habitual compartes el host con otras máquinas virtuales. La asignación de CPU, memoria, almacenamiento y sus límites depende de la oferta. En un dedicado se reserva el equipo físico, pero eso no elimina los límites de red, discos ni aplicación.
- Elasticidad: ¿cómo cambia la capacidad?
- Ampliar una VM puede requerir detenerla o reiniciarla. Añadir más servidores exige que la aplicación distribuya trabajo y datos correctamente. “Cloud” no significa que cualquiera de esas operaciones sea automática, instantánea o ilimitada.
- Continuidad: ¿qué sucede si se pierde un componente?
- Un servidor único puede ser un punto único de fallo, sea virtual o físico. Diseña recuperación, responsables y pruebas por separado de la compra de capacidad.
En una pantalla estrecha puedes desplazar las tablas horizontalmente. Con teclado, enfoca la región de la tabla para recorrer su contenido.
| Criterio | VPS de plan definido | Infraestructura cloud | Servidor físico dedicado |
|---|---|---|---|
| Encaje inicial | Una aplicación compatible que cabe en una VM y necesita control del sistema. | Necesitas combinar cómputo, red, datos y automatización según una arquitectura definida. | Necesitas un perfil físico concreto o aislamiento de host que justifique operarlo. |
| Cómo comparar recursos | CPU compartida o reservada, RAM, IOPS, red y límites del plan. | Familia de instancia, discos, servicios y cuotas de cada componente. | CPU, memoria, discos, redundancia y procedimiento de sustitución física. |
| Crecimiento | Cambio de plan o migración; pide ventana y límites. | Cambio de tamaño o más instancias, sujeto a diseño, capacidad y cuotas. | Ampliación de hardware o más equipos; pide disponibilidad y plazo. |
| Operación | Autogestionada o contratada; especifica tareas. | Puede reducir ciertas tareas con servicios gestionados, no toda responsabilidad. | Incluye sistema y aplicación; separa soporte físico del soporte del software. |
| Continuidad | Una VM no demuestra recuperación probada. | Una VM en una zona no equivale a una aplicación multizona. | Un equipo exclusivo no equivale a un segundo equipo disponible. |
| Costo a revisar | Plan, licencias, respaldos, administración y ampliaciones. | Cómputo, datos, red, servicios, observabilidad y operación. | Renta o compra, licencias, administración, respaldos y contingencia. |
La comparación técnica de AWS entre VPS y dedicado explica la diferencia de asignación física. Úsala para entender el modelo, no como prueba del rendimiento o del SLA de otra oferta.
Ruta de decisión: descarta primero lo incompatible
- Comprueba las restricciones del software. Documenta sistema operativo, versión de base de datos, arquitectura de CPU, licencias y soporte del fabricante. Si exige hardware exclusivo o una configuración que el proveedor no ofrece, descarta esa opción aunque sea más barata.
- Describe la carga, no solo las visitas. Registra concurrencia, trabajo por operación, tamaño de datos, tareas programadas y horas pico. Un portal con consultas costosas puede exigir más que otro con más visitantes y contenido estático.
- Define cuánto puedes parar y perder. RTO es el objetivo de tiempo para recuperar el servicio; RPO, la pérdida de datos máxima tolerable expresada en tiempo. Son objetivos que hay que probar, no propiedades automáticas de un plan.
- Elige el cambio de capacidad que realmente necesitas. Si crecer de forma planificada basta, evalúa una VM y su ruta de ampliación. Si necesitas repartir tráfico entre nodos, verifica sesiones, archivos, base de datos y dependencias antes de pagar por más instancias.
- Confirma quién operará. Si nadie puede atender parches, alertas, recuperación y cambios, incorpora administración al presupuesto o evalúa un servicio de aplicación gestionado. Comprar root no crea una capacidad operativa.
Tres casos que llevan a decisiones diferentes
- ERP interno con carga relativamente estable: empieza por compatibilidad del fabricante, concurrencia real, disco y recuperación. Una VM puede ser suficiente; no se justifica dedicado por el solo hecho de ser una empresa. Acepta la opción únicamente tras el piloto y con una ruta documentada de crecimiento.
- Tienda con campañas: diferencia un pico de CPU de un bloqueo en base de datos o pasarela. Añadir nodos web no corrige por sí solo esas dependencias. Cloud puede facilitar componentes escalables, pero la aplicación y el equipo deben poder utilizarlos.
- Proceso con necesidad física específica: compara dedicado o una oferta de host exclusivo, revisa licenciamiento y mide la carga. El aislamiento puede ser relevante sin que sea la alternativa más económica ni la más disponible.
Son criterios de diseño, no benchmarks ni recomendaciones de tamaño. Si todavía no conoces la carga, la siguiente inversión útil es una prueba representativa, no contratar capacidad a ciegas.
Cloud no convierte una sola máquina en alta disponibilidad
La documentación de fiabilidad de Azure Virtual Machines distingue la protección de una VM de la resiliencia de toda la aplicación. Distribuir instancias entre zonas requiere tratar también los datos, el balanceo y la conmutación. No basta con contratar dos máquinas.
Además, replicar no sustituye un respaldo: una eliminación o corrupción puede propagarse. La guía de recuperación de AWS compara estrategias de distinta complejidad y pide probar la recuperación. Define qué fallo cubrirás: equipo, zona, cuenta comprometida o pérdida de datos. No todas las arquitecturas cubren todos esos escenarios.
Compara el costo total: un ejemplo que puedes recalcular
Ejemplo ilustrativo, no cotización ni precio de mercado. Supón dos propuestas para la misma aplicación y una valoración interna de trabajo de 300 MXN por hora. Todas las cantidades siguientes son supuestos antes de impuestos; no describen tarifas de un proveedor.
| Concepto | Propuesta A | Propuesta B |
|---|---|---|
| Infraestructura | 900 | 1,600 |
| Licencias | 250 | 250 |
| Respaldo independiente | 200 | 300 |
| Red y otros servicios | 150 | 250 |
| Operación valorada a 300/h | 4 h × 300 = 1,200 | 2 h × 300 = 600 |
| Total mensual comparable | 2,700 | 3,000 |
Fórmula: infraestructura + licencias + respaldos + red y otros servicios + horas de operación × valor de la hora. Una migración inicial de 3,600 MXN, repartida para esta comparación entre 12 meses, añade 300 MXN mensuales a cada propuesta si cuesta lo mismo en ambas: los totales comparables serían 3,000 y 3,300 MXN. No cambia el flujo real del pago inicial.
Compara tus costos con tus propios datos
Abre la herramienta para introducir tus importes, desglosar el costo total de VPS, cloud y dedicado durante el periodo elegido y exportar el resultado como CSV local. Los cálculos se realizan en tu navegador: la herramienta no envía los datos introducidos a un servidor.
Los valores iniciales son hipotéticos, no una cotización. La selección de moneda cambia la etiqueta, no convierte divisas; usa importes en una misma moneda y revisa qué conceptos incluye cada propuesta.
En este supuesto B cuesta 300 MXN más al mes, pero deja de ser más cara si A requiere más de una hora adicional de operación mensual: con 5 horas A empata en 3,000 MXN, sin prorratear migración. Esto no demuestra que B ahorre horas: pide evidencias del alcance y usa tus registros. Repite el cálculo con consumo pico, restauraciones, licencias adicionales, egreso de datos, impuestos, moneda y renovación de cada oferta. No sumes trabajo ya incluido dos veces.
Las alertas de gasto ayudan a detectar desviaciones; no asumas que detendrán automáticamente todos los cargos. Define quién las revisará y qué acción puede tomar sin interrumpir una operación crítica.
Prueba la opción antes de comprometer la migración
- Prepara una copia aislada autorizada. Protege o anonimiza datos, impide correos y cobros reales, y conserva intacta la producción. Usa versiones y tamaño de datos comparables.
- Ejecuta tareas que importan al negocio. Por ejemplo, consultar existencias, guardar una orden y obtener un reporte. Define antes el tiempo aceptable y la concurrencia; registra resultados y errores, no solo un promedio de CPU.
- Observa el cuello de botella. CPU, memoria, almacenamiento, red o servicio externo pueden limitar de manera distinta. Si falla la prueba, identifica la causa antes de subir de plan.
- Restaura en un entorno separado. Comprueba registros, archivos, configuración, acceso y funciones. Cronometra hasta que el servicio sea utilizable, no hasta que termine de copiarse el respaldo.
- Ensaya cambio y retorno. Define congelación de escrituras cuando proceda, sincronización final, validación, responsables y condiciones de reversión. Bajar TTL por sí solo no evita pérdida de datos ni garantiza cero interrupción.
Solo acepta una propuesta si satisface tus criterios de funcionamiento, recuperación y operación. El modelo de responsabilidad compartida de AWS ilustra por qué contratar infraestructura no transfiere automáticamente la gestión de la aplicación. Para un servicio administrado, exige por escrito qué tareas asume cada parte.
Ficha reutilizable para documentar la decisión
Copia esta ficha en tu documento de evaluación; no se envía ni se guarda desde esta página. Sirve para autogestión o para comparar cualquier proveedor.
Aplicación y proceso crítico: ____
Versiones y licencias compatibles: ____
Carga probada y fecha: ____
Tiempo aceptable por operación y errores permitidos: ____
RTO / RPO aprobados por negocio: ____
Aislamiento físico necesario y motivo: ____
Ruta de ampliación y ventana: ____
Responsable de parches / alertas / restauración: ____
Costo mensual normal / pico / inicial: ____
Resultado de restauración y evidencia: ____
Condición que impide contratar: ____
Opción elegida, motivo y fecha de reevaluación: ____
Cómo puede ayudar la IA, y dónde no debe decidir
Una herramienta de IA puede ordenar requisitos, señalar campos vacíos en dos propuestas o ayudarte a formular preguntas sobre cargos y responsabilidades. Usa datos sin secretos ni información de clientes. No le delegues compatibilidad, cálculo final, interpretación contractual ni dimensionamiento: puede inventar límites, precios o capacidades. Verifica cada conclusión contra documentación vigente, contrato y mediciones propias.
Si necesitas apoyo, pide un alcance verificable
Un proveedor administrado aporta valor cuando se compromete con tareas concretas: revisión de compatibilidad, piloto, monitoreo con responsables, prueba de restauración y acompañamiento del cambio. La etiqueta “administrado” o “24/7” no demuestra que incluya todo eso; diferencia recepción de un ticket, primera respuesta y resolución.
Si quieres revisar tu caso con Cobalt Blue Web, comparte la ficha de requisitos por contacto, sin contraseñas ni respaldos de producción. Pide propuesta y exclusiones por escrito. También puedes usar la ficha con tu equipo o con otro proveedor: la decisión debe sostenerse en evidencias, no en la marca.
Preguntas frecuentes
¿Cloud siempre es más caro que un VPS?
No hay una regla universal. Compara una arquitectura equivalente, consumo, operación y recuperación durante el mismo periodo. Una tarifa base menor puede excluir componentes que la otra incluye.
¿Un dedicado elimina la necesidad de respaldos?
No. El uso exclusivo del equipo no protege por sí solo frente a borrado, corrupción, fallos o incidentes de la cuenta. Define copias recuperables y prueba su restauración.
¿Puedo pasar de VPS a cloud sin cambiar mi aplicación?
A veces puedes trasladarla a otra VM compatible. Aprovechar varios nodos o servicios gestionados puede exigir cambios de arquitectura. Valida licencias, datos, red y procedimiento de retorno antes del cambio.