So richten Sie AWS Verified Access ein, ohne Ihr Budget zu sprengen

AWS Verified Access berechnet Gebühren pro Anwendungsstunde und pro Gigabyte verarbeiteter Daten, und wenn Sie Dutzende interner Tools nutzen, kann dieser Posten schnell anwachsen. Ein ALB mit OIDC-Authentifizierung wirkt im Vergleich dazu praktisch kostenlos, wenn Sie eine weitere Listener-Regel hinzufügen, Ihren Identitätsanbieter wiederverwenden – und schon sind Sie fertig. Auch Client-VPN ist eine bekannte Größe: relativ günstig, praxiserprobt, und viele Entwickler wissen bereits, wie man es einsetzt. Ehrlich gesagt ist es nicht überraschend, dass viele Teams zu dem Schluss kommen, dass „Verified Access“ nicht das Richtige für sie ist.

Die unbequeme Wahrheit ist jedoch, dass ALB+OIDC und VPNs zwar das Problem der Anmeldung lösen, nicht aber das von Zero Trust. Es handelt sich zwar zweifellos um eine cloudnative Auslagerung der Authentifizierung auf Anwendungsebene, aber es ist immer noch kein Zero Trust. Mit anderen Worten: ALB+OIDC ist hervorragend geeignet, um die Fragen „Wer ist dieser Benutzer und darf er sich anmelden?“ zu beantworten, aber damit hört es im Großen und Ganzen auch schon auf. Zero-Trust-Netzwerkzugang muss noch einen Schritt weiter gehen und bei jedem Aufruf der Anwendung immer wieder fragen: „Sollte diese spezifische Anfrage von diesem Benutzer, auf diesem Gerät, zu diesem Zeitpunkt zugelassen werden?“

Verified Access ist als Zero-Trust-Netzwerkzugangsdienst (ZTNA) konzipiert, der jede Anfrage anhand der Identität und des Gerätestatus bewertet und dabei detaillierte Richtlinien durchsetzt, anstatt einen pauschalen Netzwerkzugang zu gewähren, sobald man „im VPN“ oder „hinter dem ALB“ ist. Um diesen Zero-Trust-Netzwerkzugang im Normalbetrieb zu erreichen, müssten Sie manuell einen vollständigen Zero-Trust-Stack zusammenstellen: Identität, Gerätestatus, Richtlinien-Engine, Durchsetzungspunkte sowie Telemetrie/Überwachung – alles pro Anwendung miteinander verknüpft. Insgesamt müssen Sie Folgendes aufbauen:

• Mindestens einen IdP+MFA/SSO.
• Ein oder mehrere Systeme zur Gerätezustandsüberwachung (MDM/UEM+EDR) mit einer API.
• Einen zentralen PDP (Autorisierungsdienst) und eine Richtlinien-Sprache.
• Mehrere PEPs (Reverse-Proxys/Gateways) vor jeder Anwendung.
• Einen Ressourcenkatalog und eine Sensitivitätsklassifizierung.
• Protokollierung/SIEM + Überwachung und Rückkopplungsschleifen.
• Segmentierung + kontrolliertes VPN für Sonderfälle.

Genau diese Art von integrierter ZTNA-Struktur bietet Verified Access Ihnen in einem effektiven Paket. Wenn sich ein Team für „fast kostenlose“ Alternativen anstelle von Verified Access entscheidet, tauscht es nicht nur den Preis ein, sondern verzichtet auch auf die Möglichkeit, jede Anfrage als potenziell risikobehaftet zu behandeln, anstatt dem Tunnel oder dem Subnetz zu vertrauen.

Dieser Artikel geht davon aus, dass Ihnen „Zero Trust“ mehr bedeutet als das routinemäßige Abhaken von Kontrollkästchen, und untersucht eingehend, welche Vorteile Ihnen „Verified Access“ tatsächlich bietet, in welchen Bereichen Ihre bestehenden Lösungen wirklich ausreichen und wie Sie „Verified Access“ nur dort einsetzen können, wo es sich wirklich lohnt – damit Sie für Ihre Sicherheitslage bezahlen und nicht einfach nur für einen weiteren glänzenden AWS-Dienst auf Ihrer Rechnung.

Disclaimer: Zero-Trust-Netzwerkzugang ist nur ein Teil der Implementierung einer Zero-Trust-Architektur, nicht das Ganze. Es gibt noch weitere Aspekte zu berücksichtigen, aber wir konzentrieren uns hier zunächst auf den Netzwerkzugang. Das folgende Diagramm zeigt die Kernkomponenten und wie dies bei einer Anfrage konkret funktioniert:

Beginnen wir mit dem Benutzersymbol auf der linken Seite:

Ein Benutzer öffnet in seinem Browser die URL einer internen Anwendung, beispielsweise das interne Wiki, das wir auf EC2 hinter einem ALB in einem privaten Subnetz hosten.
„Verified Access“ empfängt die Anfrage und wendet sich an die konfigurierten Vertrauensanbieter (in unserem Fall „IAM Identity Center“ für die Identität und „JAMF“ für den Gerätestatus), um Vertrauensdaten zu erfassen.
AVA wertet die Vertrauensdaten anhand der Richtlinie der „Verified Access“-Gruppe aus: Identitätsattribute, Gerätestatus sowie alle von uns definierten bedingten Logikregeln.
Nur wenn die Richtlinie erfüllt ist, leitet AVA die Anfrage an den „Verified Access“-Endpunkt weiter (mit optionalen endpunktspezifischen Richtlinien), der auf das ALB/EC2-Ziel innerhalb des privaten VPC-Subnetzes verweist.

Mit anderen Worten: Jede Benutzeranfrage macht einen Umweg über „Verified Access“. Sie wird mit Identitäts- und Gerätestatusdaten von Vertrauensanbietern angereichert, in Echtzeit anhand Ihrer Zero-Trust-Richtlinie bewertet und erst dann zum Endpunkt und zur Anwendung in Ihrer VPC weitergeleitet. Das ist der wesentliche Unterschied, den Sie im Hinterkopf behalten sollten, wenn wir damit beginnen, dies mit „alternativen“ Lösungen zu vergleichen, auf die wir zurückgreifen, um Kosten zu sparen.

Nachdem wir nun gesehen haben, wie „Verified Access“ jede Anfrage als Zero-Trust-Entscheidung behandelt, lohnt es sich, genauer zu betrachten, was tatsächlich in jenem „fast kostenlosen ALB+OIDC“-Muster geschieht, auf das wir stattdessen zurückgreifen.

Betrachten wir andererseits den ALB+OIDC-Ablauf:

• Ein Benutzer ruft die ALB-URL für eine interne Anwendung auf.
• Ist er nicht authentifiziert, leitet der ALB ihn an den konfigurierten OIDC-Anbieter (Cognito, Okta, Azure AD/M365 usw.) weiter.
• Der Identitätsanbieter (IdP) führt den OAuth-/OIDC-Ablauf durch, der Benutzer meldet sich an, und der ALB validiert das zurückgegebene ID-Token oder den Authentifizierungscode.
• Sobald das Token gültig ist, leitet der ALB die Anfrage mit den Benutzer-Claims in den HTTP-Headern an die Zielgruppe (Ihre EC2-Anwendung) weiter; die Anwendung vertraut diesen Headern und benötigt keine eigene Authentifizierungs-Middleware.

Wenn Sie bereits einen Application Load Balancer vor Ihren internen Anwendungen einsetzen, scheint die Aktivierung der OIDC-Authentifizierung der richtige Weg zu sein. Sie aktivieren eine „authenticate-oidc“-Aktion in einer Listener-Regel, verweisen diese auf Ihren Identitätsanbieter, und Ihre App muss niemals selbst Weiterleitungen, Token-Überprüfungen oder die Cookie-Verwaltung implementieren. Sie verlagern den gesamten Anmeldeprozess auf die Infrastruktur-Ebene, und Ihr Backend liest lediglich die „x-amzn-oidc-“Header oder Ähnliches, um zu erkennen, wer der Benutzer ist.

Auch aus Kostengründen ist dies ein sinnvoller Schritt. Ein ALB hat in vielen Regionen eine relativ niedrige Grundgebühr pro Stunde, und Sie zahlen ohnehin bereits dafür, dass er als Frontend für Ihre Anwendungen dient. Das Hinzufügen der OIDC-Authentifizierung ist lediglich eine weitere Listener-Regel und kein neuer Dienst mit einer eigenen, pro Anwendung und Stunde berechneten Kostenposition wie bei „Verified Access“.

Wenn Sie jedoch ALB+OIDC neben das soeben gezeigte Verified-Access-Diagramm stellen, fallen Ihnen Lücken auf.

Erstens fehlt die Geräteintegrität in diesem Szenario. Der ALB kommuniziert lediglich mit Ihrem Identitätsanbieter und validiert Tokens; er fragt bei jeder Anfrage nicht nativ Jamf, CrowdStrike, JumpCloud oder einen anderen Anbieter für Gerätevertrauenswürdigkeit ab. Sie erhalten zwar eine starke Benutzerauthentifizierung, aber keine integrierte Information darüber, ob der Laptop selbst in einwandfreiem Zustand, verwaltet oder kompromittiert ist. Im „Verified Access“-Ablauf ist dieser Gerätekontext Teil jeder Entscheidung.

Zweitens befinden sich die Richtlinien auf dem ALB und nicht in einer Zero-Trust-Engine. Jeder Load Balancer und jede Listener-Regel verfügt über eine eigene Konfiguration und eigene Bedingungen, sodass Ihre Zugriffsregeln über verschiedene Infrastruktur-Objekte verstreut sind, anstatt zentral als Zero-Trust-Richtlinien definiert zu sein, die bei jeder Anfrage ausgewertet werden. Im Gegensatz dazu wertet „Verified Access“ jede Anwendungszugriffsanfrage innerhalb der AVA-Instanz und -Gruppe anhand des Identitäts- und Gerätekontexts aus und entscheidet dann, ob der Datenverkehr an den Endpunkt weitergeleitet wird. Man kann den Zugriff sogar aufgrund einer falschen Betriebssystemversion im Gerätekontext verweigern 🙂

Ich möchte damit sagen, dass ALB+OIDC hauptsächlich die „Haustür“ schützt. Sobald der Datenverkehr den ALB passiert und die Zielgruppe erreicht hat, findet keine AVA-ähnliche Neubewertung pro Anfrage auf der Grundlage eines umfassenderen Risikos oder des Gerätestatus statt, es sei denn, Sie implementieren dies selbst in der Anwendung. Mit anderen Worten: ALB+OIDC bietet Ihnen eine robuste Anmeldung, verhält sich jedoch nicht wie eine Zero-Trust-Zugriffsebene, die jede Anfrage als potenziell risikobehaftet behandelt, den Gerätestatus aggregiert und fein abgestimmte Richtlinien über mehrere Anwendungen hinweg durchsetzt.

In der Praxis reicht ALB+OIDC in der Regel aus, wenn:

• Es sich um ein internes Tool mit geringem Risiko handelt, das den Kreis Ihrer vertrauenswürdigen Benutzer nie verlässt.
• Sie benötigen bei der Entscheidung keine Informationen zum Gerätestatus, sondern müssen lediglich prüfen: „Ist dies ein bekannter Benutzer in der richtigen Gruppe?“.
• Sie kommen gut damit zurecht, Authentifizierungsregeln pro ALB zu verwalten, anstatt eine zentrale Zero-Trust-Richtlinien-Engine zu nutzen.
• Das Hauptziel besteht darin, die Anmeldung aus dem Anwendungscode auszulagern, und nicht darin, eine vollständige Zero-Trust-Zugriffsebene aufzubauen.

Es geht also nicht darum, dass ALB+OIDC schlecht ist. Es ist eine hervorragende Möglichkeit, bestimmte Aufgaben zu bewältigen und die Sicherheit mit sehr geringem Aufwand und Konfigurationsaufwand relativ zu verbessern. Es ist nur nicht dasselbe wie das, was Verified Access leistet, und wenn Ihr Ziel Zero Trust ist, spielt dieser Unterschied in der Art und Weise, wie auf Ihr Netzwerk zugegriffen wird, eine Rolle.

Als Nächstes stehen VPNs auf unserer Tagesordnung. Wenn Sie sich schon eine Weile mit AWS-Netzwerken beschäftigen, erscheint AWS Client VPN als die sinnvolle Standardlösung für den Fernzugriff ohne Standortbeschränkung. Sie erstellen einen Client-VPN-Endpunkt, ordnen ein oder mehrere VPC-Subnetze als Zielnetzwerke zu, fügen eine Autorisierungsregel für einen CIDR-Bereich hinzu, und Ihre Benutzer stellen mit einem OpenVPN-basierten Client eine Verbindung her, um „das interne Netzwerk“ zu erreichen. Sobald der Tunnel eingerichtet ist und die richtigen Routen sowie Sicherheitsgruppen vorhanden sind, können Entwickler auf EC2-Instanzen, RDS-Datenbanken, interne ALBs oder sogar lokale Ressourcen zugreifen – fast so, als befänden sie sich im Büro-LAN.

Aus Sicht des Komforts macht dies Sinn. VPNs entsprechen der Art und Weise, wie wir seit Jahren über Netzwerksicherheit denken: Man tritt einem „vertrauenswürdigen“ Netzwerk bei, und danach wird der Zugriff größtenteils über IP-Bereiche und Sicherheitsgruppen verwaltet. Mit Client-VPN können eine Subnetzzuordnung und einige Autorisierungsregeln den Benutzern Zugriff auf eine gesamte VPC gewähren, und es ist unkompliziert, weitere Ziele hinzuzufügen, indem man diese Regeln erweitert. Für kleinere Umgebungen kann dies vollkommen ausreichend sein.

Im Vergleich zum zuvor vorgestellten „Verified Access“-Ablauf ist VPN jedoch fast das Gegenteil von Zero Trust. Wenn sich ein Benutzer mit dem Client-VPN verbindet, gewähren Sie ihm praktisch einen umfassenden Zugang zum Netzwerk; Richtlinien werden auf der Ebene von Subnetzen und CIDR-Bereichen angewendet, nicht auf der Ebene einzelner Anwendungsanfragen, die anhand der Identität und des Gerätestatus überprüft werden. Zero Trust Network Access und insbesondere AWS Verified Access kehren dieses Modell um: Sie gehen davon aus, dass das Netzwerk nicht vertrauenswürdig ist („Never Trust, Always Verify!“), validieren jede Anfrage, bevor sie die Anwendung erreicht, und stützen ihre Entscheidungen darauf, wer der Nutzer ist und in welchem Zustand sich sein Gerät befindet – und nicht darauf, dass er sich zufällig „im VPN“ befindet.

VPNs sind also nach wie vor nützlich, insbesondere wenn Sie viele ältere Protokolle und Verwaltungsabläufe haben, die von „Verified Access“ noch nicht abgedeckt werden. Wenn Ihr Ziel jedoch „Zero Trust“ für den Zugriff von Benutzern auf interne Anwendungen ist, handelt es sich bei Client-VPN im Grunde um ein Modell nach dem Motto „Sie haben sich mit dem Netzwerk verbunden, jetzt sind Sie größtenteils drin“, was sich stark vom Ansatz von AVA unterscheidet, bei dem „jede Anfrage überprüft wird, bevor sie auch nur in die Nähe des privaten Subnetzes gelangt“.

Die Preisgestaltung für AWS Verified Access bei HTTP(S)-Anwendungen besteht aus zwei Komponenten: Anwendungsstunden und pro Anwendung verarbeitete Datenmenge. Die Abrechnung erfolgt stündlich für jede zugeordnete Anwendung und separat für das Datenvolumen, das AVA für diese Anwendung verarbeitet. Schauen wir uns die offiziellen Preisbeispiele, die AWS auf der Seite mit den Serviceinformationen veröffentlicht hat, einmal genauer an (Stand 09-2026).

Im kleinen Fall sehen die Zahlen harmlos aus. Wenn Sie 10 Anwendungen eine Stunde lang in der Region „US East (Ohio)“ ausführen, sind das 10 Anwendungsstunden zu 0,27 $/Stunde und eine geringe Datenmenge. Bei 0,5 GB verarbeiteten Daten pro Anwendung sieht die Aufschlüsselung des AWS-eigenen Beispiels wie folgt aus:

• Anwendungsstunden: 10 x 0,27 $ = 2,70 $
• Datenverarbeitung: 0,5 GB × 10 Anwendungen × 0,02 $ = 0,10 $
• Gesamt: 2,80 $ für diese Stunde.

Niemand wird etwas gegen 2,80 $ für einen kurzen Test oder ein kleines Pilotprojekt einzuwenden haben.

Die Leute werden nervös, wenn sie dieses Muster unbewusst auf „jede interne App“ übertragen. Auf derselben Preisseite wird ein Beispiel für einen Monat mit 300 Anwendungen in der Region „US East (Ohio)“ aufgeführt: 223.200 App-Stunden über den Monat verteilt, mit gestaffelten Tarifen (die ersten 148.800 Stunden zu 0,27 $/Stunde, die restlichen 74.400 zu 0,20 $/Stunde) und 1 GB verarbeiteter Daten pro App. Die Aufschlüsselung lautet wie folgt:

• Erste 148.800 App-Stunden: 148.800 × 0,27 $ = 40.176,00 $
• Nächste 74.400 App-Stunden: 74.400 × 0,20 $ = 14.880,00 $
• Datenverarbeitung: 1 GB × 300 Apps × 0,02 $ = 6,00 $
• Gesamt: 55.062,00 $ für den Monat.

Selbst ich hielt bei dieser Zahl inne. Ich musste erst einmal tief durchatmen, bevor ich versuchte zu verstehen, wie wir auf 55.062,00 $ gekommen waren. Diese Zahl ist der Grund, warum viele Entwickler sich Verified Access, ALB+OIDC oder Client-VPN ansehen und zu dem Schluss kommen, dass AVA „zu teuer“ ist. Es liegt nicht daran, dass die Preisgestaltung falsch ist; vielmehr ist die Nutzung von AVA als „Haustür“ (eigentlich sind es Hunderte von Haustüren) für Hunderte von internen Tools mit geringem Risiko das falsche Bereitstellungsmodell, wenn man auf die Kosten achten möchte.

VPNs sind also nach wie vor nützlich, insbesondere wenn Sie viele ältere Protokolle und Verwaltungsabläufe haben, die Verified Access noch nicht abdeckt. Wenn Ihr Ziel jedoch Zero Trust für den menschlichen Zugriff auf interne Anwendungen ist, ist Client-VPN im Grunde ein Modell nach dem Motto „Sie haben sich mit dem Netzwerk verbunden, jetzt sind Sie größtenteils drin“, was sich stark vom Ansatz von AVA unterscheidet, bei dem „jede Anfrage überprüft wird, bevor sie auch nur in die Nähe des privaten Subnetzes gelangt“.

Meine erste Frage an Sie wäre: Haben Sie wirklich 300 Anwendungen, die im Rahmen Ihres Zero-Trust-Konzepts jeweils einen eigenen Endpunkt benötigen?

Aus Sicht des Zero-Trust-Ansatzes lohnt sich der Einsatz von „Verified Access“ nur dann, wenn man ihn als hochwertige Sicherheitsschicht für jene wenigen Anwendungen betrachtet, bei denen Identität, Gerätestatus und die Durchsetzung von Richtlinien pro Anfrage tatsächlich eine Rolle spielen – und nicht als generischen Ersatz für einen Load Balancer für alle in Ihrem Unternehmen betriebenen Systeme, einschließlich Entwickler-Sandboxes und aufgegebener Projekte.

Das bedeutet in der Regel:

• Risikoreiche interne Anwendungen, die über das öffentliche Internet oder aus nicht vertrauenswürdigen Netzwerken erreichbar sind.
• Admin-Panels, Dashboards oder Steuerungsoberflächen, die von Auftragnehmern, Partnern oder Nutzergruppen mit unterschiedlichem Vertrauensstatus genutzt werden.
• Regulierte Workloads, bei denen Sie explizit gerätebezogene, identitätszentrierte Zugriffskontrollen nachweisen müssen – und nicht nur sagen können: „Wir haben ein VPN und ein Anmeldeformular.“

Eine wichtige Optimierung, die oft übersehen wird, ist die zeitliche Planung von „Verified Access“-Ressourcen, sodass diese nur während der Geschäftszeiten laufen. Wenn eine interne Anwendung nur während der Arbeitszeiten genutzt wird, gibt es kaum einen Grund, rund um die Uhr dafür zu bezahlen.

Das Gleiche gilt für das, was hinter „Verified Access“ liegt: Leiten Sie nicht jede Anwendung und jedes Byte an Datenverkehr darüber, nur weil es möglich ist. Ich hoffe aufrichtig, dass Sie nicht vorhatten, auch Ihre statischen Assets dahinter zu platzieren.

Wir haben diesen Artikel mit einem Reddit-Kommentar begonnen, in dem es hieß, dass ALB+OIDC fast kostenlos sei. Ich stimme dieser Aussage durchaus zu. Ich glaube nur nicht, dass sie die gleiche Frage beantwortet.

Wenn Sie lediglich eine Authentifizierung benötigen, können ALB+OIDC oder Client-VPN durchaus sinnvolle Optionen sein. Für tief in das Unternehmensnetzwerk integrierte Tools, Anwendungen mit geringem Risiko und veraltete Protokolle sind sie möglicherweise sogar die bessere Wahl. Wenn Sie jedoch versuchen, Zero-Trust-Netzwerkzugang mit identitäts- und gerätebezogener, anfragebezogener Richtliniendurchsetzung zu implementieren, dann lösen Sie ein völlig anderes Problem. In diesem Zusammenhang sollte der Vergleich nicht lauten: „Kann ich Benutzer kostengünstiger authentifizieren?“ Natürlich können Sie das.

Wenn Sie eine Liste mit fünf bis zehn Anwendungen in Ihrer Umgebung erstellen, bei denen Sie sich ernsthaft Sorgen machen würden, wenn sie „nur durch VPN“ oder „nur durch ALB + OIDC“ geschützt wären, ist das wahrscheinlich Ihr Ausgangspunkt. Und genau hier beginnt sich AWS Verified Access wahrscheinlich zu amortisieren.