AWS Verified Access vs. Client VPN: Der 2026 Leitfaden für ZTNA Design

Das traditionelle Client VPN ist eine architektonische Altlast, für die die meisten Unternehmen im Jahr 2026 immer noch Zinsen zahlen. Während AWS Client VPN ein funktionales Tool für den grundlegenden administrativen Zugriff bleibt, stellt die Verlagerung hin zu Zero Trust Network Access (ZTNA) über AWS Verified Access (AVA) den einzig gangbaren Weg für eine moderne Sicherheitsposition dar. Die Wahl betrifft nicht nur Protokolle; es geht darum, von einem „Connect-then-authenticate“-Modell zu einem „Continuous-verification“-Modell überzugehen, bei dem der Netzwerk-Perimeter aufhört zu existieren.

Die Architektonische Divergenz: Tunnel-basiert vs. Proxy-basiert

Um zu verstehen, warum AWS Verified Access (AVA) für die Anwendungsbereitstellung überlegen ist, müssen wir den Paketflussunterschied analysieren. AWS Client VPN ist eine Implementierung von OpenVPN. Es erstellt ein Virtual Network Interface (VIF) auf der Client-Maschine, weist eine IP aus einem CIDR-Block zu und pusht Routen in die lokale Routing-Tabelle. Sobald der Tunnel aktiv ist, ist der Benutzer „im Netzwerk“. Selbst mit Security Groups ist die Oberfläche für laterale Bewegung massiv.

AWS Verified Access fungiert als verwalteter Reverse Proxy. Es verwendet die Cedar Policy-Sprache, um jede einzelne Anfrage anhand von Vertrauensdaten zu bewerten. Es gibt keinen Tunnel. Der Maschine des Benutzers wird keine Client-IP zugewiesen. Der Benutzer interagiert mit einem öffentlichen Endpunkt, AVA bewertet die Identität und den Gerätestatus, und falls erlaubt, leitet es die Anfrage an den internen Load Balancer (ALB) oder ENI weiter. Dies eliminiert das gesamte Konzept des „Netzwerk level“-Zugriffs und verlagert den Enforcement-Punkt auf Layer 7.

Integration mit Trust Providern: Identität und Gerätestatus

Die wahre Stärke von AVA liegt in seiner Fähigkeit, „Trust Provider“ zu konsumieren. In einem Standard-Client-VPN-Setup verlassen Sie sich typischerweise auf SAML 2.0 für ein einmaliges Authentifizierungsereignis. Sobald die Sitzung hergestellt ist, war es das. AVA unterstützt eine kontinuierliche Bewertung durch die Integration mit Identity Providern (IdP) und Device Management (EDR/UEM) Systemen.

• Identity Provider: Native Integration mit AWS IAM Identity Center (ehemals SSO) oder jedem OIDC-kompatiblen Provider wie Okta oder Azure AD.
• Device Trust Provider: Integration mit CrowdStrike, Jamf oder Tanium. Dies ermöglicht es Ihnen, Policies zu schreiben, die besagen: „Erlaube Zugriff auf den Produktions-CIDR nur, wenn der Benutzer in der Gruppe 'DevOps' ist UND das CrowdStrike Sicherheitslevel 'High' ist.“

// Beispiel Cedar Policy für 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"
};

Vergleich von AWS Client VPN: Der Anwendungsfall für Legacy

Trotz der Überlegenheit von ZTNA ist AWS Client VPN nicht tot. Es bleibt das notwendige Übel für Protokolle, die sich nicht gut mit Layer 7 Proxies vertragen. Wenn Ihre Ingenieure Thick-Client-Anwendungen verwenden müssen, die rohe TCP/UDP-Streams über nicht-Standard-Ports erfordern (man denke an Legacy SQL Server Management, benutzerdefinierte RPC-Aufrufe oder direkte SSH/RDP ohne Jump Box), ist AVA schwierig anzupassen, da es hauptsächlich für HTTP/HTTPS-Traffic optimiert ist.

Darüber hinaus ermöglicht Client VPN „Full Tunnel“-Konfigurationen, die einige stark regulierte Branchen nutzen, um den gesamten Internet-Bound-Traffic durch einen zentralen Inspektionspunkt zu leiten (wie ein Transit Gateway mit AWS Network Firewall). AVA kann dies nicht; es ist inhärent eine „Split-Tunnel“-Anwendungszugriffslösung.

Kostenanalyse: Die versteckte Steuer von ZTNA

Sprechen wir über Hard- und Softwarelizenzkosten. Die Preisgestaltung von AWS Client VPN ist vorhersehbar: 0,05 $ pro Endpunkt-Assoziation pro Stunde + 0,05 $ pro aktiver Client-Verbindung pro Stunde. Für 100 Benutzer, die 8 Stunden am Tag aktiv sind, belaufen sich die Kosten auf etwa 400–600 $/Monat zuzüglich Datenübertragung. Es ist günstig, aber es ist eine „dumme“ Pipe.

Die Preisgestaltung von AWS Verified Access ist komplexer und bei Skalierung deutlich höher. Es wird pro Anwendung (0,20 $ pro Anwendung pro Stunde) und pro verarbeitetem GB (0,02 $/GB) abgerechnet. Wenn Sie 50 interne Microservices über AVA exponieren möchten, betragen die „pro Anwendung“-Kosten allein 7.200 $/Monat. Hier erfordert die Architektur eine Konsolidierung. Kluge Ingenieure verwenden einen „Wildcard“-Ansatz oder aggregieren Anwendungen hinter einem zentralen Einstiegspunkt, um die Kosten zu kontrollieren, aber selbst dann ist AVA als Premium-Sicherheitsprodukt positioniert.

AVA vs. Palo Alto Prisma Access: Der Enterprise-Kampf

Für Organisationen, die bereits Palo Alto Firewalls betreiben, stellt sich oft die Frage: Warum AVA nutzen, wenn wir Prisma Access haben? Dies hängt mit der Vision „Global Secure Access“ zusammen. Prisma Access bietet ein ausgereifteres ZTNA 2.0-Framework, das alle Ports und Protokolle verarbeitet, nicht nur Web-Traffic. Es umfasst auch integriertes DLP und erweiterte Bedrohungsprävention, die AVA nativ fehlen.

AVA punktet jedoch bei der AWS-nativen Integration. Wenn Ihr gesamter Stack in us-east-1 und eu-west-1 liegt, nutzt AVA das AWS-Backbone und IAM-Ökosystem ohne den Overhead der Verwaltung von GlobalProtect-Agents oder GRE/IPsec-Tunneln zu einem Drittanbieter-SASE-Cloud. Wenn Sie ein Palo Alto-Haus sind, bleiben Sie bei Prisma für die einheitliche Policy Engine. Wenn Sie Cloud-nativ sind und sich von globalen Agents wegbewegen, ist AVA die schlankere Wahl.

Implementierungsstrategie: Migration zu ZTNA im Jahr 2026

Versuchen Sie nicht, Ihr gesamtes VPN an einem Wochenende auf AVA umzustellen. Die Best Practice 2026 ist ein hybrider Ansatz. Verwenden Sie Client VPN für Ihren „Backstage“-administrativen Zugriff (die 5 % der Benutzer, die rohen VPC-Zugriff benötigen) und verlagern Sie 95 % Ihrer allgemeinen Mitarbeiter auf AVA für webbasierte Tools (Jira, interne Portale, HR-Anwendungen).

Schritt 1: Der OIDC-Kleber

Konfigurieren Sie AWS IAM Identity Center. Dies ist die Voraussetzung. Versuchen Sie nicht, lokale Benutzer für AVA zu verwalten. Synchronisieren Sie Ihre Google Workspace- oder Azure AD-Identitäten. Dies stellt sicher, dass, wenn ein Benutzer aus Ihrem IdP entfernt wird, dessen Zugriff auf jede AVA-geschützte Anwendung in Echtzeit entzogen wird.

Schritt 2: Die Verified Access-Instanz

Erstellen Sie eine Verified Access-Instanz. Dies ist eine globale Ressource, die Ihre Trust Provider und Gruppen enthält. Verknüpfen Sie sie mit Ihren Ziel-VPCs über Verified Access Endpoints. Diese Endpunkte können Load Balancer-basiert oder Network Interface-basiert sein.

Schritt 3: Definition der Cedar-Policies

Beginnen Sie mit „Permit All“ innerhalb der Gruppe und schränken Sie dann ein. Verwenden Sie die context.device-Felder, um zu erzwingen, dass nur von der Firma verwaltete Laptops eine Verbindung herstellen können. Dieser eine Schritt eliminiert die Bedrohung durch nicht verwaltete „Heim-PCs“, die Malware in die Umgebung einschleusen könnten.

Das Urteil: AVA ist die Zukunft, Client VPN ist die Krücke

AWS Client VPN ist ein veraltetes Tool für eine veraltete Denkweise. Es behandelt Sicherheit als einen binären Zustand – Sie sind entweder „drin“ oder „draußen“. Im Jahr 2026 ist das ein Rezept für einen katastrophalen Verstoß. AWS Verified Access bietet trotz höherer Kosten und Komplexität bei der Einrichtung die granularen, identitäts- und gerätebewussten Kontrollen, die moderne Compliance-Frameworks (wie SOC2 oder FedRAMP High) erfordern. Wenn Ihr Traffic hauptsächlich webbasiert ist, hören Sie auf, Tunnel zu bauen. Verwenden Sie einen Proxy.

Für diejenigen, die mit dem Übergang von VPC-Reachability-Modellen zu identitätsbewussten Proxies kämpfen, bietet unser Team unter techleague.io die praktische technische Expertise, um Ihren AWS-Perimeter neu zu gestalten. Kontaktieren Sie uns für eine detaillierte Architekturprüfung Ihrer aktuellen Ingress-Muster.