Una cloud VPN bien planteada resuelve dos problemas a la vez: acceso remoto seguro y conexión estable entre sedes, sin obligarte a mantener un appliance físico en cada oficina. En la práctica, lo que cambia no es solo el lugar donde vive el servicio, sino cómo autenticas a los usuarios, cómo defines las rutas y cuánto control quieres dar dentro de la red. Aquí voy a explicarte qué es, cuándo compensa, cómo se compara con otras opciones y qué revisaría yo antes de elegirla en una empresa en España.
Lo esencial para decidir si esta arquitectura encaja con tu red
- La VPN alojada en la nube mueve el punto de terminación al proveedor y reduce la dependencia de hardware propio.
- Encaja especialmente bien en teletrabajo, migraciones a la nube y entornos con varias sedes pequeñas o medianas.
- No siempre es la mejor opción si solo necesitas publicar unas pocas aplicaciones; a veces ZTNA es más limpio.
- Los costes reales no dependen solo de la licencia: pesan la capacidad, el tráfico, la alta disponibilidad y la administración.
- Si yo la implantara hoy, pondría el foco en MFA, registros de acceso, segmentación y redundancia antes que en el marketing del proveedor.
Qué es una VPN en la nube y qué problema resuelve
Yo la explico de forma simple: es una VPN cuyo extremo de conexión no vive en un equipo físico de la oficina, sino en un servicio gestionado en la nube. El usuario, o la sede completa, se conecta mediante un túnel cifrado y la red remota pasa a ver recursos internos como si estuvieran más cerca y mejor controlados.
La diferencia práctica frente a una VPN tradicional no está en el cifrado, que sigue siendo el núcleo, sino en la operación. El proveedor suele encargarse del despliegue, del escalado, de las actualizaciones y de parte de la disponibilidad. Eso reduce fricción cuando hay picos de usuarios, una migración en curso o una plantilla distribuida.
En este tipo de arquitectura aparecen dos conceptos que conviene separar. Point-to-site conecta un equipo individual con la red corporativa, y suele ser la opción lógica para teletrabajo. Site-to-site une redes completas, por ejemplo una oficina con un entorno cloud o con el CPD principal. Cuando se entienden esas dos piezas, el resto del diseño deja de parecer confuso.
En términos de protocolo, lo habitual es encontrar IPsec/IKE para enlaces entre redes y OpenVPN, IKEv2 o incluso SSTP en accesos desde cliente. Si un firewall o una red hotelera te complica la vida, OpenVPN sobre TLS suele tener más opciones de salir adelante porque normalmente usa el puerto 443 de salida, que muchas redes ya permiten. La clave no es acumular protocolos, sino elegir el que mejor encaja con tus usuarios y con el nivel de control que necesitas. Y justo por eso conviene mirar ahora cuándo realmente tiene sentido apostar por este modelo.Cuándo tiene sentido y cuándo yo la descartaría
Yo la veo especialmente útil en cuatro escenarios:
- Equipos en remoto que necesitan entrar a varios sistemas internos sin montar una infraestructura local compleja.
- Empresas en migración a la nube que no quieren cambiar la forma de acceso de los usuarios mientras mueven aplicaciones.
- Sedes pequeñas o distribuidas donde un enlace gestionado en la nube simplifica mucho la operación.
- Contratistas o personal temporal al que quieres dar acceso acotado, con MFA y registros claros.
También hay situaciones en las que yo frenaría. Si solo quieres dar acceso a una o dos aplicaciones concretas, una VPN completa puede ser más de lo necesario. En ese caso, el acceso por aplicación o un enfoque ZTNA suele dar menos superficie de ataque y menos ruido operativo. También me lo pensaría si el tráfico es muy sensible a la latencia y tu caso depende de muchas sesiones interactivas pesadas; ahí, la cercanía de la región, el camino de red y la calidad del proveedor pesan más de lo que parece.
La otra frontera clara es el alcance. Si necesitas conectar una sede entera con otra red, el modelo site-to-site sigue siendo el más natural. Si, en cambio, quieres acceso de usuarios concretos a recursos limitados, el enfoque point-to-site suele ser más limpio. Separar esos dos casos evita comprar una solución sobredimensionada o, peor, una que luego no escala bien. Con esa división clara, ya se puede comparar con más precisión qué opciones hay sobre la mesa.
Qué modalidades conviene comparar antes de comprar
Cuando evalúo este tipo de servicio, no me quedo en el nombre comercial. Comparo el modelo de acceso, el nivel de control y el tipo de usuario final. Esta tabla resume lo que normalmente miro primero:
| Modelo | Para qué sirve | Ventaja principal | Limitación típica |
|---|---|---|---|
| Point-to-site | Conectar un portátil o un móvil a la red corporativa | Rápido de desplegar y fácil de dar a usuarios remotos | Si crece mucho, la gestión por usuario se vuelve más relevante |
| Site-to-site | Unir una sede, un CPD o una red local con la nube | Encaja bien para redes completas y tráfico entre entornos | Exige más cuidado con rutas, redundancia y ancho de banda |
| Acceso por aplicación | Dar entrada solo a recursos concretos | Menos exposición y mejor enfoque de mínimo privilegio | No sustituye siempre al acceso de red completo |
| VPN clásica on-premises | Centralizar acceso desde hardware propio | Control directo si ya tienes el equipo y el equipo humano | Escalar o mantener picos puede salir caro y ser más rígido |
Si me fijo en los protocolos, el detalle sí importa. OpenVPN suele encajar bien en escenarios mixtos y redes restrictivas; IKEv2 se valora por su estabilidad en clientes y dispositivos corporativos; IPsec/IKE sigue siendo el estándar de facto para interconectar redes. Además, en varios entornos cloud verás límites prácticos como el ancho de banda compartido entre túneles o la necesidad de trabajar con tablas de rutas bien definidas. Es un recordatorio útil: no basta con “tener VPN”, hay que diseñarla con el tráfico real en mente. Y eso me lleva a la parte que más problemas evita en producción: cómo elegirla con criterio.
Cómo la elegiría en una empresa en España
Si yo la estuviera evaluando para una empresa en España, no empezaría por el precio. Empezaría por cinco preguntas muy concretas:
- ¿Se integra con mi proveedor de identidad y exige MFA de forma obligatoria?
- ¿Permite políticas por grupo, por dispositivo o por contexto, y no solo acceso plano?
- ¿Puedo situar el servicio en una región de la UE para reducir latencia y ordenar mejor la gobernanza del dato?
- ¿Tengo logs útiles para auditoría, correlación con SIEM y retención compatible con mis políticas internas?
- ¿Puedo revisar la postura del dispositivo, es decir, si el equipo cumple unas mínimas condiciones antes de entrar?
En un entorno español, yo no dejaría fuera el cumplimiento. Si trabajas con datos personales o información sensible, tener trazabilidad, segmentación y control de accesos no es un extra; es parte del diseño. Eso no significa complicarlo todo, pero sí evitar la típica implantación rápida que luego nadie puede auditar. También vigilaría el equilibrio entre split tunneling, cuando solo una parte del tráfico pasa por la VPN, y full tunnel, cuando todo el tráfico se encamina por ella. El primero ahorra carga y suele mejorar la experiencia; el segundo da más control. Elegir mal aquí es una de las formas más comunes de crear frustración interna.
Mi regla práctica sería sencilla: si la red es pequeña, pero el control es serio, priorizo identidad, MFA y segmentación; si la red es grande, priorizo además redundancia y observabilidad. No se trata de comprar más funciones, sino de no quedar ciego cuando algo falle. Y eso enlaza directamente con el coste real, que casi nunca es solo una cifra mensual.
Qué coste real tiene y dónde se esconde el gasto
El error más frecuente es mirar solo la licencia. En una VPN alojada en la nube yo separo el coste en cinco bloques:
- Capacidad del servicio, que depende del número de usuarios, túneles o sedes.
- Tráfico transferido, especialmente si hay mucho uso intersede o si haces full tunnel.
- Alta disponibilidad, porque 1 punto de entrada suele ser barato hasta que cae.
- Operación, que incluye altas, bajas, cambios de política y soporte a usuarios.
- Seguridad adicional, como MFA, MDM, registros o integración con IAM.
En la práctica, la factura más engañosa no es la del mes 1, sino la del mes 6, cuando ya has sumado doble túnel para una sede crítica, retención de logs y alguna ampliación de capacidad. Yo suelo recomendar pensar desde el principio en pares: 2 túneles para un punto importante, 2 métodos de autenticación fuertes y, si la operación lo pide, 2 rutas de salida o de contingencia. No porque todo deba duplicarse sin criterio, sino porque la continuidad rara vez sale barata cuando se improvisa.
También conviene medir el coste de gestión, que es menos visible pero más real. Cada vez que cambias un grupo, un permiso o una política de acceso, alguien dedica tiempo. En redes pequeñas eso se nota poco; en organizaciones con muchas sedes o muchos proveedores externos, el tiempo administrativo termina pesando tanto como la licencia. Por eso, cuando una solución parece demasiado barata, yo desconfío un poco: a menudo el gasto simplemente se ha movido a otro sitio. Con ese mapa de costes, ya solo queda aterrizar una configuración que funcione de verdad en el día a día.
La configuración que más suele funcionar cuando la red crece
Si tuviera que empezar hoy desde cero, haría esto:
- Definiría qué necesita cada grupo: usuarios remotos, sedes, admins y terceros no deberían tener el mismo alcance.
- Empezaría por acceso individual para el teletrabajo y añadiría enlaces entre redes solo donde hicieran falta.
- Obligaría MFA desde el primer día y, si puedo, vincularía la conexión al estado del dispositivo.
- Decidiría explícitamente qué tráfico va por la VPN y cuál sale directo a internet, en vez de dejarlo implícito.
- Montaría alertas y revisaría los logs al menos una vez al mes.
- Probaría el failover de los túneles cada 90 días para no descubrir fallos en mitad de una incidencia real.
Lo que mejor suele salir no es la configuración más sofisticada, sino la que reduce ambigüedad. Cuando cada usuario entiende por qué entra por un camino y no por otro, y cuando el equipo técnico puede ver qué pasa sin abrir tres consolas distintas, la operación se vuelve mucho más llevadera. En mi experiencia, la tendencia actual va además hacia un modelo más fino: menos acceso a toda la red y más acceso exacto a lo que cada persona necesita. Si solo necesitas 2 o 3 aplicaciones, yo miraría primero ese enfoque; si necesitas varias subredes, una VPN en la nube sigue siendo una base sólida y pragmática.
