AWS Verified Access vs Client VPN : Le guide 2026 pour la conception ZTNA

Le Client VPN traditionnel est une dette architecturale héritée que la plupart des entreprises continuent de rembourser en 2026. Bien que AWS Client VPN reste un outil fonctionnel pour un accès administratif basique, le passage à Zero Trust Network Access (ZTNA) via AWS Verified Access (AVA) représente la seule voie viable pour une posture de sécurité moderne. Le choix ne se limite pas aux protocoles ; il s'agit de passer d'un modèle "se connecter-puis-s'authentifier" à un modèle de "vérification continue" où le périmètre réseau cesse d'exister.

La divergence architecturale : basé sur tunnel vs basé sur proxy

Pour comprendre pourquoi AWS Verified Access (AVA) est supérieur pour la livraison d'applications, nous devons analyser la différence de flux de paquets. AWS Client VPN est une implémentation d'OpenVPN. Il crée une Virtual Network Interface (VIF) sur la machine cliente, lui attribue une IP à partir d'un bloc CIDR, et pousse des routes dans la table de routage locale. Une fois le tunnel établi, l'utilisateur est "sur le réseau". Même avec les Security Groups, la surface de mouvement latéral est massive.

AWS Verified Access fonctionne comme un reverse proxy managé. Il utilise le langage de politique Cedar pour évaluer chaque requête par rapport aux données de confiance. Il n'y a pas de tunnel. Aucune IP cliente n'est attribuée à la machine de l'utilisateur. L'utilisateur interagit avec un endpoint public, AVA évalue l'identité et la posture de l'appareil, et si autorisé, il proxyfie la requête vers l'Internal Load Balancer (ALB) ou l'ENI. Cela élimine tout le concept d'accès "au niveau du réseau", déplaçant le point d'application à la Couche 7.

Intégration avec les Trust Providers : Identité et posture de l'appareil

La véritable puissance d'AVA réside dans sa capacité à consommer des "Trust Providers". Dans une configuration Client VPN standard, vous vous appuyez généralement sur SAML 2.0 pour une authentification ponctuelle. Une fois la session établie, c'est tout. AVA prend en charge l'évaluation continue en s'intégrant avec des Identity Providers (IdP) et des systèmes de Device Management (EDR/UEM).

• Identity Providers : Intégration native avec AWS IAM Identity Center (anciennement SSO) ou tout fournisseur compatible OIDC comme Okta ou Azure AD.
• Device Trust Providers : Intégration avec CrowdStrike, Jamf ou Tanium. Cela vous permet d'écrire des politiques qui disent : "Autoriser l'accès au CIDR de production uniquement si l'utilisateur est dans le groupe 'DevOps' ET que le niveau de sécurité CrowdStrike est 'Élevé'."

// Exemple de politique Cedar pour 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"
};

Comparaison avec AWS Client VPN : Le cas d'usage pour l'hérité

Malgré la supériorité du ZTNA, AWS Client VPN n'est pas mort. Il reste le mal nécessaire pour les protocoles qui ne fonctionnent pas bien avec les proxys de Couche 7. Si vos ingénieurs doivent utiliser des applications clientes lourdes qui nécessitent des flux TCP/UDP bruts sur des ports non standard (pensez à la gestion de SQL Server héritée, aux appels RPC personnalisés, ou au SSH/RDP direct sans jump box), AVA est difficile à adapter car il est principalement optimisé pour le trafic HTTP/HTTPS.

De plus, Client VPN permet des configurations "Full Tunnel", que certaines industries hautement réglementées utilisent pour forcer tout le trafic Internet à passer par un point d'inspection centralisé (comme un Transit Gateway avec AWS Network Firewall). AVA ne peut pas faire cela ; c'est intrinsèquement une solution d'accès aux applications de type "Split-Tunnel".

Analyse des coûts : la taxe cachée du ZTNA

Parlons de la réalité du hardware et des licences. La tarification d'AWS Client VPN est prévisible : 0,05 $ par association de point de terminaison par heure + 0,05 $ par connexion client active par heure. Pour 100 utilisateurs actifs 8 heures par jour, cela représente environ 400 à 600 $/mois, plus le transfert de données. C'est bon marché, mais c'est un tuyau "stupide".

La tarification d'AWS Verified Access est plus complexe et significativement plus élevée à l'échelle. Elle facture par application (0,20 $ par application par heure) et par Go traité (0,02 $/Go). Si vous avez 50 microservices internes que vous souhaitez exposer via AVA, le coût "par application" seul est de 7 200 $/mois. C'est là que l'architecture nécessite une consolidation. Les ingénieurs intelligents utilisent une approche "Wildcard" ou regroupent les applications derrière un point d'entrée central pour gérer les coûts, mais même ainsi, AVA est positionné comme un produit de sécurité premium.

AVA vs Palo Alto Prisma Access : La bataille en entreprise

Pour les organisations déjà équipées de Palo Alto Firewalls, la question est souvent la suivante : Pourquoi utiliser AVA alors que nous avons Prisma Access ? Cela se résume à la vision "Global Secure Access". Prisma Access offre un cadre ZTNA 2.0 plus mature qui gère tous les ports et protocoles, pas seulement le trafic web. Il inclut également des fonctionnalités intégrées de DLP et de protection avancée contre les menaces que AVA ne possède pas nativement.

Cependant, AVA l'emporte sur l'intégration native AWS. Si votre stack entier est dans us-east-1 et eu-west-1, AVA exploite le backbone AWS et l'écosystème IAM sans la charge de gestion des agents GlobalProtect ou des tunnels GRE/IPsec vers un cloud SASE tiers. Si vous êtes une maison Palo Alto, restez avec Prisma pour le moteur de politique unifié. Si vous êtes cloud-native et que vous vous éloignez des agents globaux, AVA est le choix le plus léger.

Stratégie de déploiement : Migration vers le ZTNA en 2026

N'essayez pas de migrer l'intégralité de votre VPN vers AVA en un week-end. La meilleure pratique en 2026 est une approche hybride. Utilisez Client VPN pour votre accès administratif "Backstage" (les 5 % d'utilisateurs qui ont besoin d'un accès brut au VPC) et déplacez 95 % de votre personnel général vers AVA pour les outils basés sur le web (Jira, portails internes, applications RH).

Étape 1 : La colle OIDC

Configurez AWS IAM Identity Center. C'est un prérequis. N'essayez pas de gérer les utilisateurs locaux pour AVA. Synchronisez vos identités Google Workspace ou Azure AD. Cela garantit que lorsqu'un utilisateur est désactivé de votre IdP, son accès à chaque application protégée par AVA est révoqué en temps réel.

Étape 2 : L'instance Verified Access

Créez une instance Verified Access. C'est une ressource globale qui contient vos Trust Providers et groupes. Associez-la à vos VPC cibles via des Verified Access Endpoints. Ces points de terminaison peuvent être basés sur un Load Balancer ou une Network Interface.

Étape 3 : Définition des politiques Cedar

Commencez avec "Permit All" au sein du groupe et affinez. Utilisez les champs context.device pour garantir que seuls les ordinateurs portables gérés par l'entreprise peuvent se connecter. Cette seule mesure élimine la menace que des "PC personnels" non gérés introduisent des malwares dans l'environnement.

Le verdict : AVA est l'avenir, Client VPN est la béquille

AWS Client VPN est un outil hérité pour une mentalité héritée. Il traite la sécurité comme un état binaire : vous êtes soit "dedans", soit "dehors". En 2026, c'est une recette pour une brèche catastrophique. AWS Verified Access, malgré son coût plus élevé et sa complexité de configuration, fournit les contrôles granulaires, sensibles à l'identité et aux appareils que les cadres de conformité modernes (comme SOC2 ou FedRAMP High) exigent. Si votre trafic est principalement basé sur le web, arrêtez de construire des tunnels. Utilisez un proxy.

Pour ceux qui luttent avec la transition des modèles de VPC-reachability vers les proxies tenant compte de l'identité, notre équipe à techleague.io apporte l'expertise d'ingénierie pratique pour refactoriser votre périmètre AWS. Contactez-nous pour planifier une revue architecturale approfondie de vos modèles d'ingress actuels.