AWS Verified Access vs. Client VPN: La Guía 2026 para el Diseño ZTNA

La Client VPN tradicional es una deuda arquitectónica heredada por la que la mayoría de las empresas siguen pagando intereses en 2026. Aunque AWS Client VPN sigue siendo una herramienta funcional para el acceso administrativo básico, el cambio hacia Zero Trust Network Access (ZTNA) a través de AWS Verified Access (AVA) representa la única vía viable para una postura de seguridad moderna. La elección no se trata solo de protocolos; se trata de pasar de un modelo de "conectar-luego-autenticar" a un modelo de "verificación continua" donde el perímetro de la red deja de existir.

La Divergencia Arquitectónica: Basado en Túnel vs. Basado en Proxy

Para entender por qué AWS Verified Access (AVA) es superior para la entrega de aplicaciones, debemos analizar la diferencia en el flujo de paquetes. AWS Client VPN es una implementación de OpenVPN. Crea una Virtual Network Interface (VIF) en la máquina cliente, le asigna una IP de un bloque CIDR y empuja rutas a la tabla de enrutamiento local. Una vez que el túnel está activo, el usuario está "en la red". Incluso con Security Groups, la superficie de ataque para movimiento lateral es masiva.

AWS Verified Access opera como un proxy inverso gestionado. Utiliza el lenguaje de políticas Cedar para evaluar cada solicitud contra datos de confianza. No hay túnel. No se asigna una IP de cliente a la máquina del usuario. El usuario interactúa con un endpoint público, AVA evalúa la identidad y la postura del dispositivo, y si está permitido, envía la solicitud como proxy al Load Balancer (ALB) o ENI interno. Esto elimina el concepto completo de acceso a "nivel de red", moviendo el punto de aplicación a la Capa 7.

Integración con Proveedores de Confianza: Identidad y Postura del Dispositivo

El verdadero poder de AVA reside en su capacidad para consumir "Trust Providers". En una configuración estándar de Client VPN, generalmente se depende de SAML 2.0 para un evento de autenticación único. Una vez que se establece la sesión, eso es todo. AVA soporta la evaluación continua integrándose con Identity Providers (IdP) y sistemas de Device Management (EDR/UEM).

• Identity Providers: Integración nativa con AWS IAM Identity Center (anteriormente SSO) o cualquier proveedor compatible con OIDC como Okta o Azure AD.
• Device Trust Providers: Integración con CrowdStrike, Jamf o Tanium. Esto permite escribir políticas que dicen: "Permitir el acceso al CIDR de Producción solo si el usuario está en el grupo 'DevOps' Y el nivel de seguridad de CrowdStrike es 'Alto'".

// Ejemplo de política Cedar para AVA
permit(
    principal,
    action == "http-request",
    resource
)
when {
    context.identity.groups.contains("Engineers") &&
    context.device.assessment.overall_health_score == "STABLE" &&
    context.device.assessment.jamf.compliance_status == "COMPLIANT"
};

Comparando AWS Client VPN: El Caso de Uso para lo Legado

A pesar de la superioridad de ZTNA, AWS Client VPN no está muerto. Sigue siendo el mal necesario para protocolos que no funcionan bien con proxies de Capa 7. Si sus ingenieros necesitan usar aplicaciones cliente "pesadas" que requieren flujos de TCP/UDP crudos sobre puertos no estándar (piense en la administración de SQL Server heredada, llamadas RPC personalizadas o SSH/RDP directo sin un jump box), AVA es una opción difícil porque está optimizado principalmente para tráfico HTTP/HTTPS.

Además, Client VPN permite configuraciones de "Full Tunnel", que algunas industrias altamente reguladas utilizan para forzar todo el tráfico saliente a Internet a través de un punto de inspección centralizado (como un Transit Gateway con AWS Network Firewall). AVA no puede hacer esto; es inherentemente una solución de acceso a aplicaciones con "Split Tunnel" (túnel dividido).

Análisis de Costos: El Impuesto Oculto de ZTNA

Hablemos de la realidad de hardware y licencias. El precio de AWS Client VPN es predecible: $0.05 por asociación de endpoint por hora + $0.05 por conexión de cliente activa por hora. Para 100 usuarios activos 8 horas al día, está viendo aproximadamente $400-$600/mes más transferencia de datos. Es barato, pero es una tubería "tonta".

El precio de AWS Verified Access es más complejo y significativamente más alto a escala. Cobra por aplicación ($0.20 por aplicación por hora) y por GB procesado ($0.02/GB). Si tiene 50 microservicios internos que desea exponer a través de AVA, el costo "por aplicación" solo es de $7,200/mes. Aquí es donde la arquitectura requiere consolidación. Los ingenieros inteligentes utilizan un enfoque de "Wildcard" o agregan aplicaciones detrás de un punto de entrada central para gestionar los costos, pero incluso así, AVA se posiciona como un producto de seguridad premium.

AVA vs. Palo Alto Prisma Access: La Batalla Empresarial

Para las organizaciones que ya utilizan Palo Alto Firewalls, la pregunta a menudo es: ¿Por qué usar AVA si tenemos Prisma Access? Esto se reduce a la visión de "Global Secure Access". Prisma Access ofrece un framework ZTNA 2.0 más maduro que maneja todos los puertos y protocolos, no solo el tráfico web. También incluye DLP integrado y prevención avanzada de amenazas que AVA carece de forma nativa.

Sin embargo, AVA gana en integración nativa con AWS. Si su pila completa está en us-east-1 y eu-west-1, AVA aprovecha el backbone de AWS y el ecosistema IAM sin la sobrecarga de gestionar agentes de GlobalProtect o túneles GRE/IPsec a una nube SASE de terceros. Si usted es una empresa que usa Palo Alto, quédese con Prisma para el motor de políticas unificado. Si es cloud-native y se está alejando de los agentes globales, AVA es la opción más ligera.

Estrategia de Despliegue: Migrando a ZTNA en 2026

No intente realizar un "lift-and-shift" (migración completa) de toda su VPN a AVA en un fin de semana. La mejor práctica de 2026 es un enfoque híbrido. Use Client VPN para su acceso administrativo de "Backstage" (el 5% de los usuarios que necesitan acceso crudo a la VPC) y migre al 95% de su personal general a AVA para herramientas basadas en web (Jira, Portales Internos, Aplicaciones de RRHH).

Paso 1: El Pegamento OIDC

Configure AWS IAM Identity Center. Este es el prerrequisito. No intente gestionar usuarios locales para AVA. Sincronice sus identidades de Google Workspace o Azure AD. Esto asegura que cuando un usuario es desincorporado de su IdP, su acceso a cada aplicación protegida por AVA se revoca en tiempo real.

Paso 2: La Instancia de Verified Access

Cree una Instancia de Verified Access. Este es un recurso global que contiene sus proveedores de confianza y grupos. Asócielo con sus VPCs objetivo a través de Verified Access Endpoints. Estos endpoints pueden basarse en Load Balancer o en Network Interface.

Paso 3: Definiendo las Políticas Cedar

Comience con "Permitir Todo" dentro del grupo y luego restrinja. Use los campos context.device para exigir que solo las laptops gestionadas por la empresa puedan conectarse. Este movimiento elimina la amenaza de que "PCs domésticas" no gestionadas introduzcan malware en el entorno.

El Veredicto: AVA es el Futuro, Client VPN es el Apoyo

AWS Client VPN es una herramienta legada para una mentalidad legada. Trata la seguridad como un estado binario: o estás "dentro" o estás "fuera". En 2026, eso es una receta para una brecha catastrófica. AWS Verified Access, a pesar de su mayor costo y complejidad en la configuración, proporciona los controles granulares, conscientes de la identidad y del dispositivo que demandan los marcos de cumplimiento modernos (como SOC2 o FedRAMP High). Si su tráfico es principalmente basado en web, deje de construir túneles. Use un proxy.

Para aquellos que luchan con la transición de modelos de "VPC-reachability" a proxies conscientes de la identidad, nuestro equipo en techleague.io proporciona la experiencia de ingeniería práctica para refactorizar su perímetro de AWS. Comuníquese para programar una revisión arquitectónica profunda de sus patrones de ingreso actuales.