La mayoría de quienes compran un VPS pasan su tiempo de evaluación comparando vCPUs y asignaciones de RAM, para descubrir seis meses después en producción que el problema siempre fue la red. Picos de latencia en horas punta, rendimiento que nunca alcanza la velocidad de puerto anunciada, jitter que arruina las cargas de trabajo en tiempo real: nada de esto son fallos de hardware. Son las consecuencias predecibles de una arquitectura de red compartida que el proveedor eligió y el cliente nunca preguntó. Entender el aislamiento de red del VPS antes de firmar es la diferencia entre una plataforma que aguanta bajo carga y una que se degrada silenciosamente justo cuando más la necesitas.

Las tres especificaciones ocultas dentro de “ancho de banda”

Todos los planes VPS citan una cifra de ancho de banda. Esa cifra es en realidad tres cosas distintas agrupadas, y los proveedores rara vez las separan con claridad. La primera es la velocidad de puerto: el rendimiento máximo que puede transportar la interfaz. La segunda es la transferencia mensual permitida: el volumen total de datos que puedes mover antes de que se aplique throttling o cargos por exceso. La tercera, y la más importante, es si esa velocidad de puerto es dedicada o burstable.

Un puerto dedicado de 1 Gbps significa que tu VPS tiene acceso exclusivo a 1 Gbps; las instancias colocadas en el mismo host físico no compiten por esa asignación. Un puerto compartido de 1 Gbps significa que el enlace ascendente del host se divide entre todas las máquinas virtuales que el proveedor haya colocado allí. El ancho de banda burstable te permite alcanzar la cifra anunciada cuando la red está ociosa, y te limita cuando no lo está. El modo burstable es el predeterminado en la mayoría de los planes VPS de consumo y rara vez se etiqueta como tal.

La contabilización de transferencia añade otra complicación. Algunos proveedores cuentan solo el tráfico saliente contra tu cuota mensual; otros cuentan ambas direcciones. Para cargas de trabajo que reciben grandes subidas, como destinos de copia de seguridad o pipelines de ingesta de archivos, el modelo de contabilización entrante puede agotar una cuota mucho más rápido de lo que sugiere la hoja de especificaciones.

El steal time y el problema del vecino ruidoso

El efecto del vecino ruidoso no es un fallo en la implementación de un proveedor concreto; es una propiedad estructural de la infraestructura compartida. Un hipervisor reparte en rodajas de tiempo las CPUs físicas entre muchas máquinas virtuales simultáneamente. Cuando una VM vecina satura su asignación, tu vCPU está lista para ejecutarse pero no puede, porque el hipervisor está atendiendo la carga de trabajo de otra persona. El kernel de Linux expone esto como steal time, reportado como %st en herramientas como top y vmstat.

Un umbral diagnóstico de uso común: si el steal time se mantiene por encima del 10% aproximadamente durante unos 20 minutos, la instancia está experimentando contención significativa. Las investigaciones sobre entornos virtualizados han documentado degradaciones del rendimiento de hasta 16 veces la línea base bajo carga intensa de vecinos. El mismo principio se aplica a los recursos de red. Si el host físico tiene un enlace ascendente de 10 Gbps compartido entre decenas de VMs, un solo inquilino realizando una transferencia masiva puede comprimir el rendimiento efectivo de todos los demás hasta una fracción de lo que prometía la hoja de especificaciones.

La velocidad de puerto anunciada es lo que obtienes cuando nadie más la quiere. El rendimiento garantizado es lo que obtienes cuando todos la quieren.

KVM con drivers paravirtualizados virtio es el estándar actual para minimizar esta exposición en la capa de cómputo: cada VM ejecuta su propio kernel sobre hardware virtual, proporcionando límites de aislamiento genuinos. El hosting basado en contenedores (OpenVZ, LXC) comparte el kernel del host y no ofrece un límite equivalente. Pero la elección del hipervisor solo aborda el aislamiento de CPU y memoria. El aislamiento de red en la capa del enlace ascendente es una decisión arquitectónica separada, y está completamente en manos del proveedor.

QoS y traffic shaping: qué controlas tú frente a qué controlan ellos

El traffic shaping y el policing son los dos mecanismos que los proveedores usan para gestionar el rendimiento de red compartida del VPS. El shaping retrasa los paquetes fuera de contrato, introduciendo latencia y jitter. El policing los descarta o reetiqueta, lo cual es más agresivo pero evita la acumulación en cola. Ambas son técnicas de QoS aplicadas a nivel de interfaz de red.

Aquí está la asimetría estructural que la mayoría de la documentación VPS pasa por alto: puedes configurar el egress shaping dentro de tu VM usando herramientas de Linux como tc y el qdisc HTB. En cambio, no puedes moldear el tráfico entrante desde dentro de la VM en absoluto. El shaping de entrada requiere un dispositivo IFB (Intermediate Functional Block) o, de forma más práctica, shaping en el router upstream. Ese router upstream pertenece al proveedor. Cualquier política de QoS que gobierne cómo se prioriza tu tráfico en el enlace ascendente compartido la escribió el proveedor, y tú no puedes inspeccionarla ni modificarla.

Esto significa que el traffic shaping del VPS en la nube a nivel de enlace ascendente es un compromiso del proveedor, no una capacidad del inquilino. AWS, Azure y GCP ofrecen controles de QoS dentro de sus capas de red virtual, pero esos controles se aplican a los flujos de tráfico entre recursos dentro de sus plataformas. El modelo de contención del enlace físico subyacente sigue siendo responsabilidad de ellos. Al evaluar un proveedor, la pregunta correcta no es si ofrecen QoS, sino si asumen compromisos exigibles sobre cómo se gestiona el enlace ascendente compartido bajo contención.

Qué significan realmente “carrier-neutral” y “Tier III” para tu tráfico

El marketing en el mercado VPS está lleno de frases que suenan a garantías pero no lo son. “Carrier-neutral” y “Tier III” son dos que tienen un significado técnico y contractual real, y son relevantes específicamente para la calidad de red.

Una instalación carrier-neutral no está atada a un único proveedor de tránsito. El operador puede establecer peering directamente con múltiples operadores, puntos de intercambio de internet y on-ramps a la nube, eligiendo el mejor camino para cada clase de tráfico en lugar de aceptar lo que ofrezca un único proveedor upstream. En una instalación Tier III, las rutas redundantes de alimentación y refrigeración permiten que la infraestructura física soporte mantenimientos planificados sin tiempo de inactividad, y el compromiso de disponibilidad es contractual y no meramente aspiracional.

Operamos nuestra infraestructura VPS en instalaciones Tier III carrier-neutral, todas con certificación ISO 27001, con un SLA contractual del 99,9% de disponibilidad. En AMS1 en Ámsterdam, el peering directo en AMS-IX y las interconexiones con AWS, Azure, GCP, Oracle y Cloudflare significan que el tráfico hacia y desde esas plataformas no atraviesa rutas de internet pública con latencia impredecible. Cuando un ingeniero nos pregunta qué ocurre con su tráfico bajo contención, podemos señalar la arquitectura física y el contrato, no una página de marketing.

Buenas prácticas de red en VPS: qué preguntar antes de comprometerte

Las siguientes preguntas te ayudarán a distinguir a los proveedores que han pensado bien su arquitectura de red de los que no.

  • ¿La velocidad de puerto es dedicada o compartida? Si la respuesta es “burstable” o la hoja de especificaciones no dice “dedicada”, asume que es compartida.
  • ¿Cuál es la ratio de sobresubscripción en tus enlaces ascendentes físicos? La mayoría de los proveedores no responderán esto. La negativa en sí misma es informativa.
  • ¿Cómo aplicas QoS en el enlace ascendente compartido? Pregunta específicamente qué ocurre cuando una VM colocada en el mismo host satura el enlace.
  • ¿La garantía de ancho de banda figura en el contrato? Un número en una página de características no es un acuerdo de nivel de servicio. Pide el documento del SLA.
  • ¿Qué tecnología de hipervisor utilizáis? KVM con drivers virtio es la línea base actual para el aislamiento en producción. Cualquier solución que comparta kernel merece un análisis más detallado.
  • ¿Cómo se contabiliza el tráfico entrante? Para cargas de trabajo que reciben datos de forma significativa, esto cambia por completo la economía del plan.

El principio subyacente a todas estas preguntas es que las garantías de ancho de banda del VPS y el aislamiento de red del VPS son propiedades arquitectónicas, no afirmaciones de marketing. Las determinan decisiones que el proveedor tomó sobre hardware físico, aprovisionamiento de enlaces, configuración del hipervisor y política de QoS mucho antes de que te registraras. La única forma de verificarlas es preguntar directamente, leer el contrato y, cuando sea posible, ejecutar tus propios benchmarks contra el host específico en lugar de los promedios publicados por el proveedor.

Los proveedores que compiten en precio de titular tienden a recortar precisamente en estas dimensiones: la calidad de red, las IOPS de almacenamiento y los SLAs de soporte son donde se recupera el margen después de un precio de cómputo gancho. La comparación de hojas de especificaciones que presenta dos planes como equivalentes rara vez sobrevive al contacto con la arquitectura de red real que hay debajo.