AWS Client VPN o una VPN en EC2: un manual de operación

Ambas opciones dan a tu equipo una VPN de acceso remoto, así que la pregunta interesante no es cuál existe, sino cuál puedes operar. La diferencia es quién es dueño del punto de conexión a las 3 de la madrugada y a qué controles llegas cuando algo se rompe. Sigue los cinco pasos de abajo en orden, porque cada uno puede terminar la comparación antes de tiempo. Saltarse el paso de inventario es justo como los equipos acaban migrando dos veces.

Paso 1: escribe el requisito antes de la factura

Necesitas cinco hechos en una página: quién se autentica y contra qué, qué plataformas de cliente deben funcionar, qué destinos privados son accesibles, qué disponibilidad prometiste y cómo es el tráfico en realidad. Sin eso, cualquier comparación posterior se convierte en una discusión sobre una lista de funciones.

Sé concreto con los destinos. «Acceso a la VPC» suele significar tres cosas distintas: el CIDR de la VPC, una red emparejada y un rango local detrás de un Transit Gateway. Un punto de conexión gestionado alcanza los tres, pero cada uno necesita una ruta y una regla de autorización, y cada uno es una línea aparte en tu requisito.

Paso 2: enumera lo que ya funciona

Antes de diseñar nada, enumera los puntos de conexión existentes y cualquier servidor alojado en EC2 junto con sus grupos de seguridad. Estas llamadas son de solo lectura y seguras desde una cuenta con permisos describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Lee la salida como un mapa de lo que los clientes ya alcanzan. Una regla de autorización que falta explica un fallo que parece un problema de enrutamiento, y un punto de conexión asociado a una sola subred explica por qué un fallo de zona tumbó todo el servicio.

Anota también los grupos de seguridad asociados a cualquier instancia autoalojada. Esas reglas forman parte del modelo de acceso y son lo primero que se rompe en silencio cuando alguien reconstruye una instancia a partir de una plantilla.

Paso 3: reparte las responsabilidades

El servicio gestionado es dueño de la flota de puntos de conexión, de su parcheo y de su disponibilidad dentro de la región. Tú eres dueño del alta de identidades, las reglas de autorización, las rutas de red detrás del punto de conexión, la configuración de registros y la decisión de cuántas subredes asociar.

El autoalojamiento lo invierte. Tú eres dueño del sistema operativo invitado, del demonio VPN y su configuración, de los certificados y claves, de las copias de seguridad, del monitoreo y de la recuperación. El modelo de seguridad de EC2 pone la seguridad del invitado y de la aplicación en el cliente, y un servidor VPN es un invitado como cualquier otro.

Escribe el reparto como una tabla con nombres en la columna derecha. Si ningún nombre aparece junto a la renovación de certificados, ese es el hallazgo, y pesa más que la diferencia por hora.

Paso 4: compara con una carga de trabajo que puedas describir

El costo sigue la forma, no el tamaño. Para la opción gestionada, cuenta las horas de asociación de puntos de conexión, las horas de conexión de clientes, la transferencia y los servicios de identidad y registros que habilites. Para el autoalojamiento, cuenta el cómputo, el almacenamiento, la red, las licencias y el tiempo de ingeniería que mantiene el servidor parcheado. Pon ambos conjuntos de cifras en una hoja con el mismo horizonte temporal. Una comparación a tres años que ignore las horas de parcheo siempre favorecerá al servidor que ya tienes.

Las comparaciones de rendimiento necesitan la misma disciplina. Una sesión interactiva de escritorio, una transferencia grande y cincuenta solicitudes pequeñas concurrentes estresan partes distintas del camino: la CPU para el cifrado, la capacidad de red de la instancia, la pila propia del cliente y el destino. Prueba con clientes representativos y la misma tarea en ambos diseños.

Una instancia más grande no es prueba de que una transferencia será más rápida, y una sesión exitosa no es un plan de capacidad. Trata cualquier folclore heredado sobre familias de instancias como una hipótesis que probar, no como una regla de compra.

Paso 5: migra con una reversión que ya hayas ejecutado

Ejecuta ambos puntos de conexión en paralelo durante un periodo definido, distribuye primero el perfil de cliente nuevo a un grupo pequeño y no toques las reglas de autorización del punto de conexión antiguo hasta que el grupo haya usado el nuevo en trabajo real. La reversión es un cambio de perfil, no una reconstrucción, así que decide ahora dónde vive el perfil antiguo.

Verifica en este orden: la autenticación tiene éxito, el cliente recibe las rutas esperadas, un destino autorizado responde y un destino no autorizado falla, y los registros muestran ambos eventos. Si falla cualquier paso, detente y arregla ese paso en lugar de pasar al siguiente grupo de clientes. Anota el resultado de cada comprobación, porque una migración recordada solo como «funcionó» no se puede depurar un mes después.

Después de la migración, programa las comprobaciones aburridas: la caducidad de los certificados, el número de asociaciones, las reglas de autorización que ya no coinciden con ningún grupo y el número de conexiones frente a tu expectativa. La Guía de administración de Client VPN es la referencia para las piezas de punto de conexión, autenticación y enrutamiento que configuraste.