Servidores VPS y cloud gestionados en España: VMware ESXi, NVMe +500.000 IOPS, latencia <5 ms, IP española y soporte nivel 2-3. Desde 36 €/mes sin IVA.
La tarifa de servidores VPS y cloud de Aclass se compone de siete configuraciones publicadas que van de 36 a 90 €/mes sin IVA. Todas comparten la misma plataforma: un clúster VMware ESXi con almacenamiento NVMe en nuestro CPD Tier III de Madrid, IP española y acceso administrativo completo al sistema operativo. Lo que cambia entre un plan y otro es el reparto de tres recursos —vCPU, memoria y disco— porque son los que determinan el comportamiento real de una aplicación bajo carga.
Conviene leer la tabla en dos pasadas. La primera, para localizar la fila que su carga consume antes: una aplicación con muchos procesos concurrentes se queda sin vCPU, un motor de base de datos se queda sin memoria y un gestor documental o una tienda con catálogo grande se queda sin disco. La segunda pasada sirve para comprobar el margen de crecimiento a doce meses, porque ampliar dentro de la misma plataforma no obliga a migrar datos ni a cambiar la dirección IP.
Los precios se publican siempre sin IVA ni ningún otro impuesto aplicable, y no llevan permanencia. Cuando una especificación concreta de un plan no está documentada aparece marcada como dato pendiente en lugar de rellenarse con una cifra aproximada: preferimos una tabla incompleta y verificable a una tabla completa e inventada. Si necesita el detalle exacto de tráfico incluido o de snapshots de un plan concreto, se lo confirmamos por escrito antes de contratar.
Para decidir entre estos siete planes y otras familias de servidor puede apoyarse en nuestra comparativa de cloud, VPS y servidor dedicado , donde el análisis se hace criterio a criterio. En esta página el foco es distinto: qué se contrata, con qué especificación y a qué precio.
Algunas empresas llegan buscando un servidor dedicado en España y acaban contratando un plan de esta tarifa, porque la carga real no justifica hardware exclusivo. El servidor dedicado tiene sentido cuando el software se licencia por núcleo físico, cuando la carga consume el hardware de forma sostenida durante todo el día o cuando una exigencia normativa impone aislamiento físico del equipo. Fuera de esos tres supuestos, una máquina virtual sobre clúster ofrece el mismo rendimiento efectivo con mejor recuperación ante fallos y sin pagar capacidad ociosa. Si su caso encaja en el dedicado, lo dimensionamos igualmente: escríbanos y le pasamos presupuesto con la especificación exacta.
| Característica | 36 €/mes | 44 €/mes | 46 €/mes | 59,90 €/mes | 61 €/mes | 74 €/mes | 90 €/mes |
|---|---|---|---|---|---|---|---|
| Precio mensual sin IVA | 36 €/mes | 44 €/mes | 46 €/mes | 59,90 €/mes | 61 €/mes | 74 €/mes | 90 €/mes |
| vCPU | 2 vCPU Intel | 4 vCPU Intel | 2 vCPU Intel | 4 vCPU Intel | 2 vCPU Intel | 4 vCPU Intel | [DATO PENDIENTE]: vCPU del plan de 90 €/mes |
| RAM | 4 GB | 4 GB | 8 GB | 4 GB | 8 GB | 4 GB | [DATO PENDIENTE]: RAM del plan de 90 €/mes |
| Disco NVMe | 50 GB NVMe | 50 GB NVMe | 50 GB NVMe | 100 GB NVMe | 100 GB NVMe | 150 GB NVMe | [DATO PENDIENTE]: disco del plan de 90 €/mes |
| Tráfico | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE]: tráfico del plan de 90 €/mes |
| IP española | IP española incluida | IP española incluida | IP española incluida | IP española incluida | IP española incluida | IP española incluida | IP española incluida |
| Snapshots | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] | [DATO PENDIENTE] |
| Nivel de gestión | Gestionado o no gestionado | Gestionado o no gestionado | Gestionado o no gestionado | Gestionado o no gestionado | Gestionado o no gestionado | Gestionado o no gestionado | Gestionado o no gestionado |
Configuraciones superiores a los planes publicados se presupuestan a medida en la horquilla de 95-150 €/mes sin IVA. Todos los precios se publican sin IVA ni ningún otro impuesto aplicable.
Detrás de cada plan hay cuatro decisiones de plataforma que explican el rendimiento observado: cómo se asigna la CPU, cómo se reserva la memoria, qué almacenamiento hay debajo y cómo sale el tráfico a internet. Las cuatro se describen a continuación con el nivel de detalle que necesita un responsable técnico para comparar con otra oferta sin tener que llamar a un comercial.
Una vCPU es un hilo de ejecución del procesador físico asignado a la máquina virtual. La diferencia entre plataformas serias y plataformas baratas está en la sobresuscripción: cuántas vCPU se venden por cada núcleo real. En nuestra plataforma la asignación se planifica para que el rendimiento observado sea estable a lo largo del día, y el indicador que lo delata es el steal time: si crece, el host no puede atender a todas sus máquinas. Es la métrica que conviene pedir a cualquier proveedor antes de firmar.
La memoria asignada es reservada, no compartida por demanda: la máquina dispone en todo momento de los gigabytes contratados, sin depender de que el resto de instancias del host los liberen. Cuando la aplicación crece, la memoria se amplía en caliente sobre la instancia en ejecución siempre que el sistema operativo soporte la operación, de modo que no hay reinstalación, ni cambio de IP, ni ventana de parada planificada para pasar de un plan de 4 GB a uno de 8 GB.
El almacenamiento es NVMe con más de 500.000 IOPS en la cabina, y es la diferencia más perceptible frente a plataformas con disco SATA o SSD de consumo. En bases de datos y en CMS con muchas consultas por página, el cuello de botella casi nunca es la CPU: es la latencia de acceso al disco. El valor que llega a cada máquina depende de su profundidad de cola y de su configuración, por eso publicamos más abajo la tabla de benchmarks con el método de medida en lugar de una cifra suelta sin contexto.
Cada servidor se entrega con IP española incluida, un dato relevante para geolocalización, para reputación de correo saliente y para servicios que restringen acceso por país. La conectividad del CPD es multifibra con varios operadores, lo que evita que la caída de un carrier deje el servicio incomunicado. El tráfico incluido por plan aparece marcado como dato pendiente en la tabla y se confirma por escrito en la propuesta, junto con la política aplicable si se supera.
La plataforma no es una caja alquilada en un proveedor mayorista y revendida con otro nombre: es un clúster VMware ESXi operado por nuestro equipo en un centro de datos Tier III de Madrid. Esa diferencia se nota en tres cosas concretas: quién responde cuando algo falla, en cuánto tiempo se aplica un cambio y dónde residen físicamente los datos, algo determinante para el cumplimiento del RGPD y para cualquier pliego que exija tratamiento en territorio español.
Las máquinas se ejecutan sobre varios hipervisores que comparten almacenamiento. Si un nodo falla, las instancias que albergaba arrancan automáticamente en otro nodo del clúster sin intervención manual y sin pérdida de datos comprometidos en disco. Ese comportamiento es lo que separa una plataforma cloud de un VPS clásico alojado en un host aislado, donde el fallo del equipo implica servicio caído hasta que alguien sustituye la pieza. La misma capacidad permite mover instancias entre nodos para mantenimiento de hardware sin ventana de parada, algo que un servidor aislado nunca puede ofrecer por diseño.
Alojar en Madrid tiene un efecto medible sobre el tiempo de respuesta percibido: la latencia hasta usuarios españoles se mantiene por debajo de 5 ms, frente a las decenas de milisegundos que añade un centro de datos centroeuropeo o americano. En una web con varias decenas de peticiones por página, esa diferencia se multiplica y se traduce en segundos de carga. También afecta a aplicaciones internas, a escritorios remotos y a cualquier flujo interactivo donde el usuario espera respuesta inmediata tras cada acción.
El centro de datos cuenta con alimentación eléctrica redundada con SAI y grupo electrógeno, climatización en configuración N+1 y acometidas de fibra de varios operadores. El control de acceso físico es permanente y la sala está monitorizada de forma continua. Estas medidas no son un adorno de catálogo: son las que sostienen el compromiso de disponibilidad, porque la mayoría de las caídas prolongadas en servicios alojados no proceden del software, sino de fallos eléctricos, térmicos o de conectividad sin plan de respaldo.
Todos los planes se pueden contratar en modalidad gestionada o no gestionada. La elección no depende del presupuesto sino de una pregunta muy concreta: si aparece una vulnerabilidad crítica un viernes por la tarde, ¿hay alguien en su organización capaz de aplicar el parche esa misma tarde? Si la respuesta es no, la modalidad no gestionada deja de ser un ahorro y pasa a ser un riesgo de seguridad con factura diferida.
La modalidad gestionada cubre la instalación y actualización del sistema operativo, el parcheado de seguridad, el endurecimiento inicial del servidor, la configuración del cortafuegos y de los accesos por clave, la monitorización de servicios y de capacidad, y la respuesta ante incidencias. Nuestro equipo interviene sobre la máquina cuando hace falta, sin que el cliente tenga que reproducir el problema ni escalar un ticket a un segundo proveedor.
La modalidad no gestionada exige perfil de administrador de sistemas con soltura en línea de comandos: despliegue del servidor web y de la base de datos, gestión de certificados, revisión de registros, copias verificadas y respuesta fuera de horario. Es la opción correcta cuando existe ese perfil interno y quiere control total del entorno. Si el equipo lo tiene a medias, una fórmula intermedia razonable es la gestión del sistema base por nuestra parte y la aplicación por parte del cliente, apoyada en consultoría IT para las decisiones de arquitectura.
El soporte lo presta directamente personal técnico de nivel 2-3 en español, sin capa previa de agentes que solo abren tickets. Es el punto donde más se diferencia un operador local de un proveedor paneuropeo: el interlocutor conoce la plataforma, tiene acceso al hipervisor y puede actuar, en lugar de trasladar el caso a otro turno en otro país. Para incidencias críticas la atención es continua, todos los días del año.
El compromiso de disponibilidad de la plataforma es de un uptime del 99,9% medido sobre la instancia, excluyendo las paradas solicitadas por el propio cliente y las causadas por su software. Sobre un mes natural, ese 99,9% equivale a un margen de unos 43 minutos de indisponibilidad acumulada, y es la cifra que utilizamos como referencia interna para decidir cuándo una incidencia se escala a guardia.
La arquitectura en clúster es la que hace creíble ese número: el mantenimiento de hardware se realiza migrando las instancias entre nodos, de modo que las tareas programadas de la plataforma no exigen parar la máquina del cliente. Las actualizaciones que sí requieren reinicio del sistema operativo se acuerdan con cada cliente y se ejecutan en la franja que menos le afecte, no en una ventana global impuesta por el proveedor.
Sobre las condiciones económicas del compromiso: la penalización contractual por incumplimiento del SLA y la ventana de mantenimiento comprometida están [DATO PENDIENTE] y se recogerán aquí en cuanto estén formalizadas en las condiciones de servicio. Preferimos dejarlo explícito antes que publicar un porcentaje de bonificación que después no aparezca en el contrato: un SLA sin penalización escrita es una declaración de intenciones, no un compromiso, y conviene comprobarlo también en las ofertas de la competencia.
Dimensionar bien consiste en identificar qué recurso agota antes la aplicación y dejar un margen razonable de crecimiento, no en contratar el plan más grande por si acaso. El patrón que observamos en las migraciones que atendemos es constante: las webs corporativas y los WordPress se quedan sin memoria por la caché y por los procesos PHP, las tiendas online sufren en los picos de campaña y los ERP y bases de datos necesitan IOPS sostenidos y memoria holgada para el motor.
Los tres perfiles publicados sirven de punto de partida contrastado. Una web corporativa o WordPress funciona con 2 vCPU, 4 GB de RAM y 50 GB NVMe, en la horquilla de 36 a 46 €/mes. Una tienda online con picos pide 4 vCPU, 8 GB de RAM y 100 GB NVMe, entre 59 y 78 €/mes. Un ERP, un CRM o una base de datos de producción se dimensionan con 8 vCPU, 16 GB de RAM y 150 GB NVMe, en el rango de 95 a 150 €/mes. Todos los importes son sin IVA.
El configurador que sigue aplica esa lógica sin inventar precios: mueva los deslizadores y le devuelve el plan real de la tarifa que cubre la configuración elegida. Si la combinación supera el mayor plan publicado, no compone un importe artificial: muestra el rango de cargas grandes y el acceso a presupuesto, porque a partir de ese tamaño la propuesta se calcula sobre el perfil de uso concreto.
Si su caso no encaja en ninguno de los tres perfiles —por ejemplo, un entorno con muchos usuarios concurrentes de escritorio remoto o una plataforma con almacenamiento intensivo— conviene revisarlo con datos de consumo reales. En esos escenarios suele haber servicios complementarios que descargan el servidor, como los escritorios virtuales VDI o el cloud NAS, y separar cargas sale más barato que ampliar una única máquina.
El configurador interactivo traduce vCPU, memoria y disco en el plan publicado más ajustado, con su precio mensual sin IVA. Nunca propone una configuración que no exista en la tarifa: si la carga supera el plan mayor, remite a un presupuesto a medida.
La migración se planifica para que el corte perceptible sea de minutos, no de horas. El método es siempre el mismo: inventario del servidor de origen, réplica inicial de datos con el servicio en marcha, sincronización incremental hasta dejar la diferencia en segundos y conmutación final en la franja acordada, con el DNS preparado de antemano y el tiempo de vida de los registros reducido días antes para que el cambio se propague rápido.
Antes de tocar producción, la aplicación se valida en el servidor de destino con el dominio provisional: se comprueban versiones de lenguaje, extensiones, tareas programadas, envíos de correo, certificados y permisos de ficheros. Ese ensayo es lo que evita las sorpresas típicas del día de la mudanza, casi siempre relacionadas con una versión de PHP distinta, con una tarea de cron olvidada o con rutas absolutas escritas en la configuración de la aplicación.
El plan de vuelta atrás forma parte del procedimiento: el servidor de origen se mantiene operativo y sin cambios hasta que el destino queda validado en producción, de modo que revertir consiste en devolver el DNS. Nuestro equipo se encarga de todo el proceso, y cuando la infraestructura de origen es compleja lo abordamos como proyecto de consultoría IT, con inventario previo y calendario por fases. Si además de servidores hay accesos remotos que reconfigurar, revisamos la VPN empresarial gestionada en la misma ventana.
El inventario previo es corto pero innegociable. Necesitamos la versión exacta del sistema operativo de origen y la del intérprete que ejecuta la aplicación, el listado de extensiones y librerías instaladas, el motor y la versión de la base de datos, el volumen real de datos en disco y el ritmo diario de crecimiento, las tareas programadas con su frecuencia, los certificados en uso con su fecha de caducidad y el proveedor donde está delegado el dominio. Con esos ocho datos se puede dimensionar el plan de destino y calcular la duración de la réplica inicial con un margen razonable, en lugar de descubrir a mitad de la ventana que el volcado de la base de datos tarda el triple de lo previsto.
También pedimos una lista de los servicios que dependen del servidor desde fuera: pasarelas de pago con la IP en lista blanca, integraciones con ERP o CRM, buzones de correo saliente autenticados por SPF y sistemas de copia externos que apunten a la dirección antigua. Cambiar de máquina implica cambiar de IP, y ese es el punto donde se rompen las integraciones silenciosas: la web funciona, pero el cobro con tarjeta o el envío de facturas deja de hacerlo hasta que el tercero actualiza su lista blanca. Detectarlo en el inventario cuesta diez minutos; detectarlo en producción cuesta un día de servicio degradado.
La ventana se acuerda por escrito con fecha, hora de inicio, duración máxima estimada y criterio de aborto: si a una hora determinada la validación no ha pasado, se revierte el DNS y se repite otro día, sin discusión sobre la marcha. Trabajamos preferentemente en franja nocturna o de fin de semana para las cargas de negocio y en horario laboral para los entornos internos, donde tener al equipo del cliente disponible para validar su propia aplicación vale más que el silencio de la madrugada.
Durante la ventana hay un único interlocutor técnico por cada parte y un canal directo abierto. Al cierre entregamos un informe con la hora real de conmutación, el corte medido en segundos, las comprobaciones superadas y las incidencias menores detectadas con su solución. Ese informe es también el punto de partida del seguimiento posterior: durante los primeros días vigilamos consumo de CPU, memoria, entrada y salida de disco y registros de error, porque una migración solo puede considerarse cerrada cuando la máquina ha atravesado sin sobresaltos su primer pico de tráfico real.
Ningún proveedor del mercado español publica benchmarks propios de su plataforma con el método de medida. Nosotros lo hacemos con una regla estricta: solo aparece publicado lo que está medido y es reproducible; el resto queda marcado como dato pendiente hasta que se complete la serie con herramienta, fecha y configuración exacta de la prueba.
Los dos valores ya verificables son los que sostienen el resto de la propuesta: la cabina NVMe supera los 500.000 IOPS y la latencia media desde España se mantiene por debajo de 5 ms. Publicaremos aquí la lectura y el arranque de instancia con el mismo nivel de detalle, para que cualquiera pueda repetir la prueba en su propia máquina y contrastar el resultado.
Si busca el detalle del comportamiento de cada modelo de servidor bajo distintas cargas, la comparativa de cloud, VPS y servidor dedicado desarrolla el análisis completo con su propia tabla de criterios. Esta página no duplica ese contenido a propósito: aquí está la oferta, allí el análisis.
| Métrica | Resultado medido | Método de medida |
|---|---|---|
| IOPS de escritura aleatoria 4K | Más de 500.000 IOPS en la cabina NVMe | [DATO PENDIENTE]: herramienta, fecha y configuración de la prueba (profundidad de cola, número de hilos y tamaño del fichero). |
| IOPS de lectura aleatoria 4K | [DATO PENDIENTE]: valor medido | [DATO PENDIENTE]: herramienta, fecha y configuración de la prueba. |
| Latencia media desde Madrid | Inferior a 5 ms en España | [DATO PENDIENTE]: puntos de medida, operadores de origen y fecha de la serie. |
| Tiempo de arranque de una instancia | [DATO PENDIENTE]: valor medido | [DATO PENDIENTE]: plantilla de sistema operativo, tamaño de instancia y fecha. |
Antes de contratar, lo razonable es revisar el consumo real de su servidor actual y elegir el plan a partir de esos datos. Le proponemos una consulta gratuita: analizamos la carga, indicamos qué plan de la tarifa encaja y planificamos la migración sin coste de puesta en marcha. Si prefiere ver el ecosistema completo, el hub de infraestructura IT reúne todos los servicios, y si su proyecto es una web sobre CMS quizá le baste con nuestro hosting en Madrid.
NVMe con más de 500.000 IOPS
CPD Tier III en Madrid, IP española
Soporte de nivel 2-3 en español