Cloud VPN Design: AWS/Azure/GCP Gateways, Limits und Patterns

Cloud VPN Design ist heute weniger eine Frage „können wir einen Tunnel bauen?“, sondern eine Architekturentscheidung mit harten Limits, klaren Betriebsmodellen und typischen Cloud-spezifischen Patterns. In AWS, Azure und GCP bekommen Sie VPN-Gateways als Managed Service – das reduziert Betriebslast, bringt aber eigene Quoten, Throughput-Grenzen, HA-Mechaniken und Routing-Integrationen mit. Wer diese Limits ignoriert, erlebt später die Klassiker: Tunnel sind „up“, aber Bandbreite skaliert nicht; Failover flappt; Routen leaken; NAT- oder Session-Tabellen laufen voll; oder eine vermeintlich einfache Multi-Cloud-Anbindung wird zum Routing-Labyrinth. Gleichzeitig ist Cloud VPN oft nicht die „Hauptleitung“, sondern Teil einer Hybridstrategie: als schneller Start vor Direct Connect/ExpressRoute/Interconnect, als Backup, für DR-Szenarien, für Partneranbindungen oder für standortweite SD-WAN-Overlays. Ein gutes Design schafft daher Klarheit in drei Ebenen: Gateway-Auswahl (welcher Service, welche Topologie), Limits (Tunnels, Durchsatz, Routing-Skalierung) und Patterns (Active/Active, BGP, Segmentierung, Multi-Region). Dieser Artikel führt Sie durch die wichtigsten Cloud-VPN-Gateways in AWS/Azure/GCP, zeigt typische Grenzen und vermittelt praxiserprobte Architektur- und Betriebsmodelle, die in Enterprise-Umgebungen stabil funktionieren.

Designprinzipien für Cloud VPN: Was immer gilt

Unabhängig vom Provider gibt es Grundprinzipien, die Cloud-VPN-Designs robust machen. Diese Prinzipien sind wichtiger als einzelne Konfigurationsdetails, weil sie Drift, Leaks und Betriebsprobleme langfristig verhindern.

• Conduits statt „Flat Network“: VPN ist ein definierter Pfad zwischen Zonen/Netzen, nicht eine Abkürzung, um Segmentierung zu umgehen.
• Routing wie eine Firewall behandeln: Import/Export von Prefixes per Allow-List, Default-Route nur bewusst, Max-Prefix/Guards nutzen.
• Data-Plane-Health prüfen: Tunnel „up“ ist nicht gleich Service „ok“. Probes zu echten Zielen (DNS/Bastion/App) koppeln Failover an Funktionsfähigkeit.
• Skalierung planen: Nicht nur „Bandbreite“, sondern auch PPS/Flows/Sessions, Rekey-Verhalten, NAT-Port-Pressure.
• Multi-Region als Betriebsmodell: Für kritische Workloads ist „eine Region, ein Gateway“ selten ausreichend.

AWS Cloud VPN: VGW, Transit Gateway und Cloud WAN als Bausteine

AWS bietet mehrere Wege, Site-to-Site VPN zu terminieren. In der Praxis entscheiden Sie weniger „IPsec ja/nein“, sondern wo der VPN-Anschluss im AWS-Netzwerkmodell hängt: an einem Virtual Private Gateway (VGW), an einem Transit Gateway (TGW) oder in neueren Designs auch im Kontext von Cloud WAN. Die Servicegrenzen und Skalierungsoptionen unterscheiden sich deutlich.

• VGW (Virtual Private Gateway): Klassischer VPC-Anschluss. Gut für einfache Hybrid-Anbindungen, weniger für große Transit-Topologien.
• Transit Gateway: Zentraler Hub für viele VPCs und viele VPN/Direct-Connect Attachments. Besser für Hub-and-Spoke, Multi-Account und Skalierung.
• Cloud WAN Integration: Für globale, policybasierte WAN-Topologien; Site-to-Site VPN kann Bestandteil dieser Architektur sein.

Für harte Quoten und skalierende Eigenschaften ist die AWS-Dokumentation zu AWS Site-to-Site VPN Quotas die maßgebliche Referenz. Für Client-VPN-Quoten gibt es separat AWS Client VPN quotas.

AWS Limits, die im Design wirklich zählen

Die zwei häufigsten Fehlannahmen in AWS sind: „Bandbreite skaliert automatisch“ und „mehr Tunnel = automatisch mehr Durchsatz“. In Wahrheit hängt es stark davon ab, ob Sie Standardtunnels oder Large Bandwidth Tunnels nutzen, welche Anbindung (VGW vs TGW) gewählt wurde und ob ECMP wirklich aktiv ist.

• Tunnel-Bandbreite: AWS hat standardmäßig eine pro-Tunnel-Throughput-Klasse, und es gibt zusätzlich Large Bandwidth Tunnels mit deutlich höherer pro-Tunnel-Bandbreite. Details und Einordnung liefert Tunnel options for AWS Site-to-Site VPN sowie der AWS-Blog zu 5 Gbps Tunnels.
• Quoten pro Region: Viele Limits sind region-spezifisch und teilweise erhöhbar. Das ist im Multi-Region-Design wichtig, weil Sie Skalierung nicht nur horizontal, sondern auch geografisch erreichen.
• Client VPN pro User: Für Remote Access ist relevant, dass pro Verbindung eine Mindestbandbreite unterstützt wird und dass Throughput stark von RTT und Pfad abhängt; AWS beschreibt das u. a. in Troubleshooting AWS Client VPN throughput.

AWS Patterns: Was sich in Enterprise-Umgebungen bewährt

Für AWS entstehen robuste Designs meist durch klare Trennung von Transit, Segmenten und Betriebsaufgaben.

• Pattern: TGW als Hub, VPN pro Site mit BGP: On-Prem oder SD-WAN spricht BGP über IPsec zum TGW. Vorteil: zentrale Route-Policies, skalierbare VPC-Anbindung, klare Segmentierung über TGW Route Tables.
• Pattern: Active/Active mit zwei Tunneln und ECMP: Viele Provider-/SD-WAN-Edges können beide Tunnel aktiv nutzen. Das kann Throughput und Resilienz verbessern – aber nur, wenn Routing und State (NAT/Firewalls) dafür ausgelegt sind.
• Pattern: VPN als Backup für Direct Connect: IPsec als Fallback, aber mit identischen Prefix-Policies, klaren Failover-Timern und Data-Plane-Probes, damit der Wechsel stabil bleibt.
• Pattern: Separate Attachments pro Sicherheitszone: User/Vendor/Admin/OT getrennte Route Tables und Policies, statt „ein VPN für alles“.

Azure Cloud VPN: VPN Gateway vs Virtual WAN als Architekturentscheidung

In Azure ist der zentrale Hebel die Wahl zwischen klassischem VPN Gateway (Virtual Network Gateway) und Azure Virtual WAN. Beide können Site-to-Site und (je nach Setup) Remote Access unterstützen, unterscheiden sich aber stark in Skalierung, Betriebsmodell und Topologie-Patterns.

• Azure VPN Gateway (VNet Gateway): Direkt an ein VNet gebunden, gut für klassische Hub-Spoke-Designs mit wenigen bis mittleren Standorten.
• Azure Virtual WAN: Globales WAN-Overlay mit Hubs, das Site-to-Site-VPN und andere Konnektivität integriert; gut für viele Sites, Multi-Region und standardisierte Policies.

Für Throughput- und Tunnelkapazitäten sind die SKU-Tabellen entscheidend, insbesondere die beobachteten Bandbreiten und PPS pro Gateway-Instanz. Referenz: About gateway SKUs und ergänzend Azure VPN Gateway configuration settings.

Azure Limits: Die häufigsten Planungsfallen

In Azure entstehen Engpässe selten „plötzlich“, sondern durch eine Kombination aus SKU-Wahl, Tunnelanzahl, Aggregation und QoS/Policy-Pfaden. Typische Fallstricke:

• SKU falsch dimensioniert: Viele Tunnel und hoher Throughput erfordern passende SKUs; sonst ist das Gateway der Flaschenhals, nicht das Underlay.
• Aggregierter Durchsatz: In der Praxis zählt nicht nur „pro Tunnel“, sondern der aggregierte Durchsatz, den eine Gateway-Instanz liefern kann. Genau diese Aggregation beschreibt Microsoft in den SKU-Tabellen (siehe About gateway SKUs).
• Virtual WAN Link Aggregation: In Virtual WAN können mehrere Links kombiniert werden; das kann Performance erhöhen, erfordert aber saubere Steuerung, damit Failover nicht „Bandwidth Loss“ erzeugt oder flapped. Ein praktisches (nicht offizielles) Verständnis liefert der Beitrag Pushing VPN Performance Limits in Azure Virtual WAN.

Azure Patterns: Stabilität durch klare Hubs und Policies

Azure-Designs werden stabil, wenn Sie Hub-Spoke und Policy-Kontrolle ernst nehmen.

• Pattern: Central Hub VNet + VPN Gateway: Klassiker für Hybrid. Spokes peeren an Hub, Gateways terminieren im Hub. Wichtig: Route Tables und UDRs so setzen, dass kein Routing Leak zwischen Spokes entsteht.
• Pattern: Virtual WAN für viele Sites: Wenn viele Standorte angebunden werden, reduziert Virtual WAN die Komplexität, weil Hubs standardisiert sind. Wichtig ist dann die Governance: Segmentierung (z. B. getrennte Hubs/Route Tables), klare Prefix-Policies und definierte Conduits.
• Pattern: Active/Active + Hysterese: Active/Active kann helfen, aber ohne Hysterese und Data-Plane-Probes führt es zu Flapping. Der Fokus sollte auf stabiler Umschaltung liegen, nicht auf „maximal schnell“.

GCP Cloud VPN: Classic VPN vs HA VPN und die Rolle von Cloud Router

Google Cloud unterscheidet zwischen Classic VPN und HA VPN. In Enterprise-Designs ist HA VPN in der Regel die bevorzugte Option, weil es für Hochverfügbarkeit ausgelegt ist und eng mit Cloud Router/BGP zusammenspielt. Für die harte Skalierung sind die GCP-Quotas und Limits klar dokumentiert: Quotas and limits | Cloud VPN.

• HA VPN: Auf HA-Design ausgelegt, typischerweise mit redundanten Interfaces und BGP über Cloud Router.
• Classic VPN: Älteres Modell, oft weniger flexibel; wird meist nur in Legacy-Szenarien genutzt.
• Cloud Router als Steuerung: Dynamisches Routing und ECMP sind zentrale Bausteine, wenn Sie Bandbreite über mehrere Tunnel skalieren.

GCP Limits: PPS-basierte Realität und Skalierung über mehrere Tunnel

Ein typischer Planungsfehler ist, nur „Gbit/s“ zu denken. Google dokumentiert Bandbreitenlimits für Cloud VPN in PPS (Packets per second) pro Tunnel. Das ist praxisrelevant, weil kleine Pakete (z. B. viele kurze Flows) die Kapazität schneller erschöpfen als große Pakete. Die Limits sind in den offiziellen Quota- und Limitseiten beschrieben, inklusive Einordnung, dass 250.000 pps je nach Paketgröße ungefähr 1–3 Gbit/s entsprechen: Network Connectivity quotas (Cloud VPN limits).

• Per-Tunnel PPS-Limit: Planung muss Paketgröße und Trafficprofil berücksichtigen (VoIP/Signalisierung vs Bulk).
• Skalierung über ECMP: Mehr Tunnel + ECMP kann Bandbreite erhöhen, bringt aber Anforderungen an Symmetrie/State mit (NAT/Firewalls müssen ECMP-tauglich sein).
• Active/Passive-Falle: Ein rein active/passive Modell über mehrere Gateways kann Bandbreite verschenken, wenn passive Tunnel nicht genutzt werden. Google weist in den Advanced-Konzepten explizit auf solche Effekte hin: Advanced configurations | Cloud VPN.

Multi-Cloud und Hybrid: Gemeinsame Patterns für AWS/Azure/GCP

Wenn Sie mehrere Clouds anbinden, werden Drift und Leaks wahrscheinlicher, weil jedes System eigene Route Tables, Quoten und HA-Mechaniken hat. Diese Patterns reduzieren Komplexität:

• Pattern: Hub-and-Spoke pro Cloud, wenige kontrollierte Conduits: Pro Cloud ein klarer Hub (TGW/VWAN Hub/Cloud Router Hub) und nur definierte Verbindungen zwischen Hubs (oder zentralem WAN).
• Pattern: BGP überall, aber mit striktem Filtering: BGP erleichtert Skalierung, aber nur mit Allow-Lists, Max-Prefix und klaren Communities/Tags. Ohne Policies wird Routing „wild“.
• Pattern: Segmentierung als Routing-Domänen: Separate VRFs/Route Tables für User/Vendor/Admin/OT, statt alles in einer Routingdomäne zu mischen.
• Pattern: VPN als Backup, nicht als „unsichtbare Primärleitung“: Wenn Direct Connect/ExpressRoute/Interconnect primär ist, muss VPN-Failover bewusst geplant und getestet werden (inkl. Health Checks und Hysterese).

Limits richtig interpretieren: Throughput ist nicht nur „Gbit/s“

Cloud-VPN-Limits sind mehrdimensional. Ein Design, das nur Bandbreite betrachtet, scheitert später an PPS, Session-Tabellen oder NAT-Port-Pressure.

• PPS vs Bandbreite: Viele kleine Pakete (DNS, Telemetrie, VoIP) können PPS-Limits erreichen, obwohl Bandbreite niedrig ist.
• Conntrack/NAT: Full-Tunnel-Modelle erzeugen viele Flows. NAT kann zum Engpass werden (Port Exhaustion, Mapping-Timeouts).
• Crypto/CPU (bei Appliances): Wenn Sie statt Managed Gateways virtuelle Appliances nutzen, limitiert oft CPU/Crypto-Offload und nicht das Netzwerk.
• HA/State Sync: Active/Active kann Performance steigern, erhöht aber Anforderungen an State-Synchronisation und Session Affinity.

Security Patterns: Routing-, Policy- und Identity-Guardrails

Cloud VPN ist Teil Ihrer Sicherheitsarchitektur. Ein robustes Design setzt daher Guardrails nicht erst im SIEM, sondern im Netzwerk selbst.

• Default-Route Guard: 0.0.0.0/0 und ::/0 nur in expliziten Egress-Profilen, nie „aus Versehen“.
• Prefix Allow-Lists: Pro Tunnel/Attachment definierte Import/Export-Listen; keine „RFC1918 all“-Abkürzungen.
• Identity für Remote Access: Wenn Client-VPN im Spiel ist: MFA, Conditional Access, Device Posture, und getrennte Profiles (User/Vendor/Admin).
• Auditierbarkeit: Änderungen an Route Policies als Code (Versionierung, Review, Rollback), damit Policy Drift nicht zur Normalität wird.

Operational Patterns: Monitoring, Health Checks und Alert Engineering

Cloud VPN stabil zu betreiben heißt: Tunnel-Status ist nur ein Signal. Sie brauchen SLIs, die Nutzer- und Applikationssicht abbilden, und Alerts, die nicht flappen.

• SLIs: Tunnel Availability (SA up), Rekey Success Rate, Data-Plane Probes (DNS/HTTP/ICMP zu definierten Targets), RTT/Loss/Jitter.
• Capacity KPIs: Handshake-Rate, aktive Tunnels, PPS/Throughput pro Tunnel, conntrack/NAT-Utilization (bei Appliances/Firewalls).
• Multi-signal Alerts: Alarm nur, wenn Tunnelstatus und Data-Plane-Probe schlecht ist, oder wenn Route Changes + Probes korrelieren (Blackhole-Indikator).
• Change Markers: Route-Policy-Änderungen in Dashboards sichtbar machen, damit „seit dem Change“ schneller erkannt wird.

Provider-spezifische Entscheidungshilfe: Welches Gateway wann?

Eine praxistaugliche Auswahl orientiert sich weniger am Produktnamen und mehr an Skalierung und Betriebsmodell.

• AWS: Für viele VPCs und viele Standorte ist Transit Gateway meist der stabilere Hub als rein VPC-lokales VGW, weil Routingdomänen und Attachments zentral steuerbar sind. Quoten und Optionen sollten früh gegen den Bedarf geprüft werden: AWS Site-to-Site VPN quotas.
• Azure: Für wenige bis mittlere Sites funktioniert VNet Gateway im Hub gut; bei vielen Sites und globalen Mustern lohnt Virtual WAN. SKU/Throughput ist der zentrale Hebel: Azure gateway SKUs.
• GCP: HA VPN + Cloud Router ist der Standard für Enterprise-HA. Limits sind pps-basiert und müssen mit Trafficprofil geplant werden: GCP Cloud VPN quotas and limits.

Checkliste: Cloud VPN Design in AWS/Azure/GCP

• Topologie festlegen: Hub-and-Spoke vs Mesh, pro Cloud ein Hub, definierte Conduits zwischen Hubs.
• Limits prüfen: Tunnel-/Attachment-Quoten, Throughput pro Tunnel/Gateway, PPS-Limits, regionale Besonderheiten.
• Routing-Guardrails: Allow-Lists, Default-Route Guards, Max-Prefix, Tagging/Communities, keine unkontrollierte Transitivität.
• HA-Pattern: Dual Tunnels, Multi-AZ/Region, stabile Failover-Logik mit Hysterese, Data-Plane-Probes.
• Segmentierung: Separate Route Tables/VRFs für User/Vendor/Admin/OT; keine „ein großes VPN“ Architektur.
• Capacity Planning: Bandbreite und PPS/Flows, NAT-Port-Budgets (bei zentralem Egress), Rekey-/Handshake-Last.
• Monitoring: Tunnel-Status plus Applikationsprobes, Route-Change-Monitoring, Alert Engineering mit Multi-Signal-Gating.
• Governance: Policy-as-Code, Reviews, Canary Rollouts, automatisierbarer Rollback, regelmäßige Rezertifizierung.

• AWS Site-to-Site VPN Quotas
• AWS VPN Tunnel Options (inkl. Large Bandwidth Tunnels)
• AWS Blog: 5 Gbps Site-to-Site VPN Tunnels
• Azure VPN Gateway SKUs und Throughput-Tabellen
• Azure VPN Gateway Configuration Settings
• GCP Cloud VPN Quotas and Limits
• GCP Network Connectivity Quotas (Cloud VPN Limits inkl. PPS)
• GCP Cloud VPN Advanced Configurations (Active/Passive vs Bandbreite)

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.