Cloud VPN: AWS, Azure und Google Cloud im Vergleich

Cloud VPN: AWS, Azure und Google Cloud im Vergleich ist für viele IT-Teams ein zentrales Thema, sobald Workloads in die Cloud wandern oder hybride Szenarien entstehen: On-Premises-Rechenzentrum trifft auf Cloud-VPC/VNet, Standorte sollen sicher angebunden werden, und Mitarbeitende erwarten Remote-Zugriff ohne komplizierte Sonderlösungen. „Cloud VPN“ bedeutet dabei nicht automatisch dasselbe: Je nach Anbieter unterscheiden sich Funktionsumfang, Hochverfügbarkeit, Routing-Optionen, Authentifizierung, Logging und die Frage, ob neben Site-to-Site auch ein echter Client-Zugriff (Remote Access) angeboten wird. Wer hier zu schnell entscheidet, baut entweder eine Architektur, die später nicht skaliert, oder eine Lösung, die zwar „funktioniert“, aber zu breit öffnet und damit Sicherheitsrisiken erzeugt. Dieser Artikel zeigt praxisnah, wie sich AWS, Microsoft Azure und Google Cloud in ihren VPN-Angeboten unterscheiden, welche typischen Use Cases gut abgedeckt sind und worauf Sie bei Planung, Betrieb und Kosten besonders achten sollten.

Was bedeutet „Cloud VPN“ in der Praxis?

Im Kern geht es bei Cloud VPN um verschlüsselte Verbindungen, meist auf Basis von IPsec/IKE, zwischen einer Cloud-Umgebung (z. B. VPC/VNet) und einem externen Netzwerk (On-Premises, Filiale, Colocation oder andere Cloud). Wichtig ist die Abgrenzung zwischen zwei Grundszenarien:

• Site-to-Site (S2S): Netzwerk-zu-Netzwerk. Standorte oder Rechenzentren werden dauerhaft mit der Cloud verbunden.
• Client-to-Gateway (Remote Access): Einzelne Endgeräte „wählen sich ein“, typischerweise für Homeoffice oder Admin-Zugriffe.

Technisch basiert Site-to-Site in der Regel auf IPsec und IKEv2. Wer tiefer in die Grundlagen einsteigen möchte, findet die Architekturprinzipien in der IPsec-Referenz (RFC 4301 (IPsec Architecture)) sowie die IKEv2-Spezifikation (RFC 7296 (IKEv2)). Für TLS-basierte Remote-Access-Ansätze ist TLS 1.3 als Standardreferenz hilfreich (RFC 8446 (TLS 1.3)).

Vergleichskriterien: So bewerten Sie Cloud-VPN-Angebote sinnvoll

Ein „besser“ gibt es nur im Kontext. Diese Kriterien helfen, AWS, Azure und Google Cloud objektiv zu vergleichen:

• Funktionsumfang: S2S, P2S/Remote Access, BGP, aktive/aktive Pfade, IPv6, Routing-Optionen
• Hochverfügbarkeit: redundante Tunnel, SLA, Multi-Zone/Region, Failover-Verhalten
• Integration: Identity (SSO/MFA), Logging/Monitoring, IaC/Automatisierung, Firewall-/Security-Stack
• Performance: Durchsatz, Latenz, Stabilität bei NAT/Mobilfunk, MTU/Fragmentierung
• Betrieb: Konfigurationskomplexität, Troubleshooting, Standardisierung, Change-Management
• Kosten: Tunnel-/Gateway-Kosten, Datentransfer, Zusatzkomponenten (z. B. Hubs, Transit), Betriebsaufwand

AWS Cloud VPN: Site-to-Site und Client VPN als getrennte Bausteine

AWS trennt sehr klar zwischen Site-to-Site-Anbindungen und Remote-Access-Zugriffen. Für die hybride Kopplung von On-Premises zu VPC (oder via Hub-Architektur) ist AWS Site-to-Site VPN das Kernangebot. Für Client-Zugriffe gibt es AWS Client VPN.

AWS Site-to-Site VPN: Redundanz über zwei Tunnel

Eine zentrale Eigenschaft bei AWS Site-to-Site VPN ist die standardmäßige Redundanz: Jede Verbindung bietet zwei VPN-Tunnel mit jeweils eigener öffentlicher IP-Adresse, und beide sollten für Ausfallsicherheit konfiguriert werden (How AWS Site-to-Site VPN works; Tunnel options (AWS)). In der Praxis bedeutet das: Sie planen Routing und Monitoring so, dass beide Tunnel aktiv überwacht werden und ein Failover nicht erst „im Incident“ getestet wird.

• Typische Use Cases: On-Prem ↔ VPC, Filialen ↔ AWS, Cloud-Hybrid für Legacy-Apps
• Wichtig im Betrieb: beide Tunnel aktiv konfigurieren, DPD/Keepalives, saubere MTU-Strategie

IKEv2 als Best Practice

AWS empfiehlt ausdrücklich IKEv2 für Site-to-Site-Verbindungen, weil es robuster und sicherer ist als IKEv1 (Best practices for an AWS Site-to-Site VPN customer gateway device). Für Teams ist das praktisch: IKEv2 standardisieren, Parameter vereinheitlichen, und Abweichungen nur dort zulassen, wo Legacy-Hardware es erzwingt.

AWS Client VPN: Remote Access auf OpenVPN-Basis

Für „Einwahl“-Szenarien bietet AWS einen eigenen Dienst: AWS Client VPN. Dabei verbinden sich Endgeräte über einen OpenVPN-basierten Client mit einem Client-VPN-Endpunkt (Connect using an OpenVPN client; Get started with AWS Client VPN). Für Identity-Integration ist SAML-basierte föderierte Authentifizierung möglich (SAML 2.0 federated authentication in Client VPN; Enable SAML for AWS Client VPN).

• Typische Use Cases: Homeoffice, mobiles Arbeiten, Admin-Zugriffe in AWS-Umgebungen
• Architektur-Tipp: Remote Access und Site-to-Site getrennt betrachten und getrennte Policies/Segmente nutzen

Azure Cloud VPN: VPN Gateway als zentrales Element für S2S und P2S

Microsoft Azure bündelt viele VPN-Szenarien in Azure VPN Gateway: Site-to-Site (S2S), VNet-to-VNet und Point-to-Site (P2S). Die Topologien und Designprinzipien sind in der Azure-Dokumentation zusammengefasst (Azure VPN Gateway topologies and design).

Azure Site-to-Site VPN: IPsec/IKE und BGP-Unterstützung

Azure S2S-Verbindungen laufen über IPsec/IKE. Für dynamisches Routing und größere hybride Netzwerke ist BGP eine wichtige Option. Microsoft beschreibt die Konfiguration von BGP mit VPN Gateway im Detail (Configure BGP for VPN Gateway). Für IT-Teams ist das relevant, wenn viele Standorte, mehrere Routen und eine saubere Failover-Logik erforderlich sind.

• Typische Use Cases: On-Prem ↔ Azure VNet, Multi-Site, hybride Applikationslandschaften
• Wichtig im Betrieb: Route-Design, BGP-Policies, klare Segmentierung (nicht „alles ins VNet“)

Azure Point-to-Site (P2S): Remote Access mit OpenVPN-Protokolloption

Für Remote Access bietet Azure P2S. Das ist besonders für Teleworker sinnvoll, die von zu Hause oder unterwegs ins VNet müssen. Die Azure-Dokumentation beschreibt P2S als Verbindung, die vom Client aus gestartet wird (About Azure Point-to-Site VPN). Wichtig für den Vergleich: P2S kann das OpenVPN-Protokoll nutzen, das SSL/TLS-basiert ist und typischerweise gut durch Firewalls kommt, weil TLS häufig über TCP 443 funktioniert (P2S protocols (OpenVPN/TLS) in Azure).

• Typische Use Cases: Homeoffice, einzelne Admin-Zugriffe, Projektteams, kurzfristige Remote-Anbindung
• Client-Betrieb: OpenVPN-Client-Profile und Zertifikatsauthentifizierung sind in Azure dokumentiert (OpenVPN Client 2.x for Azure P2S).

Identity-Integration im Azure-Ökosystem

Für viele Unternehmen ist die Identity-Integration ein entscheidender Vorteil in Azure, weil sich VPN-Zugriffe oft eng mit Microsoft Entra ID (ehemals Azure AD) und Conditional-Access-Mechanismen verbinden lassen. Ein Beispiel ist die P2S-Konfiguration mit Entra-ID-Authentifizierung, die in der Azure-Dokumentation beschrieben ist (P2S with Microsoft Entra ID authentication (OpenVPN)). In der Praxis ist das ein starkes Argument, wenn Sie bereits Microsoft-Identity zentral nutzen und Zugriffe kontextabhängig steuern wollen.

Google Cloud VPN: Fokus auf Site-to-Site mit HA VPN

Google Cloud positioniert Cloud VPN klar als Site-to-Site-IPsec-Lösung. Ein wichtiger Unterschied zu AWS und Azure: Google Cloud VPN unterstützt laut Dokumentation keine Client-to-Gateway-Szenarien („Dial-in“) und keine SSL-VPN-Technologien; es geht ausschließlich um site-to-site IPsec (Cloud VPN overview (Site-to-site only)). Für Remote Access müssten Teams daher andere Ansätze nutzen (z. B. separate Remote-Access-Produkte oder ZTNA-Modelle), was bei der Architekturplanung früh berücksichtigt werden sollte.

HA VPN: Hochverfügbarkeit mit SLA-Optionen

Google Cloud empfiehlt HA VPN als Standard für hochverfügbare und höhere Durchsatzanforderungen (Advanced configurations (HA VPN recommended)). In der Cloud-VPN-Übersicht wird beschrieben, dass HA VPN – abhängig von Topologie und Konfiguration – ein SLA von 99,99% oder 99,9% erreichen kann (HA VPN SLA details (Google Cloud)). Zudem ist für HA VPN dynamisches Routing via BGP vorgesehen; die Topologien und aktive/aktive bzw. aktive/passive Routing-Modelle werden dokumentiert (HA VPN topologies (BGP routing)).

• Typische Use Cases: On-Prem ↔ Google Cloud VPC, Multi-Site-Hybrid, Cloud-zu-Cloud-Anbindungen
• Wichtig im Betrieb: BGP sauber designen, Prioritäten/Routenmetriken verstehen, Failover testen

Interoperabilität und konkrete Peer-Setups

In der Praxis müssen VPNs zwischen Clouds oder zu bestehenden Firewalls interoperabel funktionieren. Google dokumentiert beispielsweise die Anbindung von HA VPN an AWS-Peer-Gateways inklusive Tunnel- und BGP-Schritten (HA VPN zu AWS Peer Gateways (Google Cloud)). Solche Anleitungen sind hilfreich, um typische Stolpersteine (Tunnelanzahl, BGP-Parameter, IP-Adressen) früh zu berücksichtigen.

Kryptografie-Parameter und IKE-Themen

Google Cloud dokumentiert unterstützte IKE-Cipher und Hinweise wie IKE-Fragmentierung, die in manchen Umgebungen relevant ist, wenn IKE-Pakete zu groß werden und sonst gedroppt werden (Supported IKE ciphers (Google Cloud)). Das ist ein praxisnaher Hinweis: Nicht nur „Tunnel hoch“, sondern „Tunnel stabil“ ist entscheidend, insbesondere über Providerstrecken oder NAT-nahe Setups.

Direkter Vergleich: Funktionsumfang nach Szenario

Statt „Wer ist besser?“ ist die sinnvollere Frage: „Wer deckt mein Szenario nativ ab?“

• Site-to-Site (hybrid, Standorte, RZ): Alle drei Clouds bieten IPsec-basierte S2S-VPNs. AWS betont zwei Tunnel pro Verbindung und IKEv2 als Best Practice (AWS Tunnel redundancy; AWS recommends IKEv2). Azure bietet S2S und BGP-Anleitung für dynamische Szenarien (Azure VPN Gateway BGP). Google Cloud fokussiert auf HA VPN mit BGP und SLA-Optionen (Google Cloud VPN overview).
• Remote Access (Client VPN / P2S): AWS bietet Client VPN mit OpenVPN-basiertem Client und SAML-Optionen (AWS Client VPN OpenVPN client; AWS Client VPN SAML). Azure bietet P2S und nennt explizit OpenVPN-Protokolloptionen für TLS/SSL-basierte Durchlässigkeit (Azure P2S and OpenVPN protocol). Google Cloud Cloud VPN unterstützt keine Client-to-Gateway-Szenarien (Cloud VPN does not support dial-in).

Skalierbarkeit und Hochverfügbarkeit: Was Sie architektonisch einplanen müssen

Cloud-VPNs wirken oft „einfach“ in der Einrichtung, aber Skalierbarkeit entsteht durch Designentscheidungen: redundante Pfade, Routing-Strategie, klare Kapazitätsplanung und automatisierte Betriebsprozesse.

• Redundante Tunnel: AWS stellt zwei Tunnel pro S2S-Verbindung bereit, beide sollten aktiv überwacht und konfiguriert sein (AWS two tunnels).
• Dynamisches Routing: BGP vereinfacht Multi-Site- und Failover-Szenarien. Azure dokumentiert BGP am VPN Gateway (Azure BGP HowTo), Google verlangt für HA VPN dynamisches Routing via BGP (HA VPN requires dynamic (BGP) routing).
• SLA und Topologie: Google Cloud nennt SLA-Optionen (99,99%/99,9%) abhängig von Topologie und Konfiguration (HA VPN SLA). Solche SLAs sind nur so gut wie das Peer-Design (z. B. redundante On-Prem-Gateways, unabhängige Leitungen).

Sicherheit: Identity, Policies und Segmentierung in Cloud-VPN-Designs

Bei Cloud VPN wird Sicherheit häufig unterschätzt, weil „IPsec verschlüsselt“. In der Praxis entstehen die größten Risiken durch zu breite Freigaben und schwache Identitätsprüfung bei Remote Access.

Remote Access: MFA/SSO und konsequente Zugriffskontrolle

• AWS Client VPN: kann SAML-basierte föderierte Authentifizierung verwenden und so in zentrale Identity-Workflows integriert werden (AWS Client VPN federated authentication).
• Azure P2S: unterstützt OpenVPN-Protokoll und Identity-Integrationen im Microsoft-Ökosystem, z. B. Entra-ID-Authentifizierung in bestimmten P2S-Konfigurationen (Azure P2S Entra ID authentication).

Best Practice ist in beiden Welten: rollenbasierte Policies, Default-Deny und separate Admin-Pfade (Jump Host/Bastion), statt „VPN rein = internes Netz“.

Site-to-Site: Segmentierung und minimale Freigaben

Für S2S-VPNs gilt: Verschlüsselte Standortkopplung ersetzt keine Segmentierung. Planen Sie Zonen (Apps, Daten, Management) und lassen Sie über den Tunnel nur die notwendigen Netze/Ports zu. Für Kryptografie-Orientierung in deutschen Umgebungen kann die BSI TR-02102 als Referenz dienen (BSI TR-02102), während NIST praxisnahe Hinweise für IPsec-Betrieb und Konfiguration beschreibt (NIST SP 800-77 Rev. 1).

Performance: Latenz, MTU und Stabilität in hybriden Pfaden

„VPN ist langsam“ ist fast immer ein Architektur- oder Pfadproblem. In Cloud-VPN-Szenarien sind diese Faktoren entscheidend:

• Latenz: Je mehr Umwege (z. B. zentraler Egress über ein entferntes Gateway), desto schlechter das Nutzererlebnis.
• MTU/Fragmentierung: IPsec-Overhead kann Pakete vergrößern; falsch gesetzte MTU/MSS-Werte führen zu Timeouts und „zähen“ Verbindungen. AWS weist bei Best Practices auch auf Path-MTU-Themen hin (AWS customer gateway best practices (MTU/DF)).
• IKE-Stabilität: In manchen Umgebungen sind IKE-Pakete groß; Google empfiehlt IKE-Fragmentierung, um Drops zu vermeiden (Google Cloud: IKE fragmentation guidance).
• Routing: BGP und saubere Prioritäten verhindern asymmetrische Pfade, die häufig „Tunnel up, Traffic tot“ verursachen.

Operativer Betrieb: Monitoring, Logging und Troubleshooting

Cloud-VPNs sind nur dann „produktionsreif“, wenn sie messbar und auditierbar sind. Planen Sie deshalb von Anfang an Monitoring und Log-Export in Ihre zentrale Plattform (z. B. SIEM/Log Analytics/Security Lake – je nach Ökosystem).

• Tunnel-Status: Up/Down, Rekey-Events, DPD/Keepalive-Fehler
• Routing: BGP-Session-Status, Route-Ankündigungen, Route-Flaps
• Pol
  

  Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

  Cisco Networking • CCNA • Packet Tracer • Network Configuration

  Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

  Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

  Leistungsumfang:

  • Netzwerkdesign & Topologie-Planung

  • Router- & Switch-Konfiguration (Cisco IOS)

  • VLAN, Inter-VLAN Routing

  • OSPF, RIP, EIGRP (Grundlagen & Implementierung)

  • NAT, ACL, DHCP, DNS-Konfiguration

  • Troubleshooting & Netzwerkoptimierung

  • Packet Tracer Projektentwicklung & Dokumentation

  • CCNA Lern- & Praxisunterstützung

  Lieferumfang:

  • Konfigurationsdateien

  • Packet-Tracer-Dateien (.pkt)

  • Netzwerkdokumentation

  • Schritt-für-Schritt-Erklärungen (auf Wunsch)

  Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

  CTA:
  Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
  Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.