Multi-Cloud VPN: AWS, Azure und Yandex Cloud über Transit Gateway und Virtual WAN verbinden

Einleitung: Warum Unternehmen jetzt auf Multi-Cloud VPN setzen sollten

Mehrere Clouds zu einem sicheren und verlässlichen Netzwerk zu verbinden, ist längst keine technische Spielerei mehr, sondern eine betriebliche Notwendigkeit. Im Jahr 2026 wechseln viele Unternehmen von Monocloud-Strategien zu Multi-Cloud-Umgebungen: Risiken werden verteilt, Kosten optimiert, Datenlokalisierungsvorgaben eingehalten und Produkte schneller auf den Markt gebracht. Dabei stellt sich die Frage: Wie verbinden wir AWS, Azure und Yandex Cloud so, dass es stabil läuft, schmerzfrei skaliert und sicherheitsüberprüfbar ist?

Dieser Leitfaden ist dein praktischer Wegweiser. Wir erklären Basis- und fortgeschrittene Konzepte, zeigen bewährte Architekturen mit AWS Transit Gateway und Azure Virtual WAN, binden Yandex Cloud und On-Premise-Standorte an und schließen mit Monitoring, Automatisierung und Wirtschaftlichkeit ab. Du bekommst Schritt-für-Schritt-Anleitungen, Checklisten, Designvorlagen, Empfehlungen zur Ausfallsicherheit, Lösungen für überlappende Netzwerke und Referenzfälle.

Grundlagen: Wichtige Bausteine des Multi-Cloud VPN

Essenzielle Komponenten

• VPC/VNet/Netzwerke in Yandex Cloud: isolierte private Netze mit Hypervisor-basiertem Routing. Die Planung des CIDR-Adressraums bildet die Basis für Stabilität. Empfohlen wird die Vergabe von nicht überlappenden Blöcken nach Domänen (prod, non-prod, shared) und Regionen.
• IPsec VPN (IKEv2): Industriestandard-Verschlüsselung auf Layer 3. Einsatz in Site-to-Site-Verbindungen zwischen Clouds und On-Premise. Unterstützt Cipher Suites mit PFS (Perfect Forward Secrecy) und Hardwarebeschleunigung (AES-GCM).
• BGP: dynamisches Routingprotokoll über abgesicherte Tunnel. Ermöglicht automatisches Ankündigen und Zurückziehen von Präfixen, ECMP-Multipfade und Traffic-Priorisierung (AS-Path Prepends, MED, Communities).
• Hub-and-Spoke: klassische Topologie, bei der das Hub Routing, Segmentierung und Sicherheitskontrollen (FW, IDS/IPS) übernimmt, die Spokes sind die applikationsseitigen VPCs/VNets.
• AWS Transit Gateway (TGW): regionale Layer-3-Fabrik zur Aggregation von VPCs, VPNs und Direct Connect. Verwalten von Routentabellen und Präfix-Verteilung zwischen Anhängern (Attachments).
• Azure Virtual WAN (vWAN): Microsofts globales Netzwerk zur einfachen Anbindung von Niederlassungen, VPN, ExpressRoute und VNet. Häufig als Multi-Cloud-Hub wegen der großen geografischen Abdeckung genutzt.
• Yandex Cloud VPN: verwaltete IPsec-Gateways mit dynamischem Routing (BGP) und hoher Verfügbarkeit durch mehrere Tunnel/Zonen. Für hohe Durchsatzraten eignen sich Cloud Interconnect oder virtuelle Router.

Sicherheitsmodell und Segmentierung

• Segmentierung auf L3: Zonen mit Vertrauen (prod, dev, shared services, Partner) abgrenzen. Steuerung der Routen zwischen Zonen über spezifische TGW/vWAN-Routentabellen und Firewall-Richtlinien.
• Kontrolle auf L4-L7: Cloud-Firewalls (Azure Firewall im Secure Hub, AWS Network Firewall oder Dritthersteller NGFW). Traffic-Inspektion, TLS-Entschlüsselung (wo möglich), IDS/IPS, DNS-Security.
• Zero Trust Prinzipien: minimal notwendige Rechte, explizite Service-Authentifizierung, kurze Leasezeiten, dauerhafte Validierung von Tunnel- und Routenstatus.

Faktoren für Stabilität

• MTU/MSS: Durch IPsec-Inkapselung reduziert sich die effektive MTU. MSS-Clamping (typisch 1350-1380) an Edge-Gateways konfigurieren, um Fragmentierung und Paketverlust zu vermeiden.
• DPD und Rekey: Dead Peer Detection und Zeitintervalle für Rekey. IKE SA und Child SA Lifetimes auf beiden Seiten synchronisieren.
• ECMP und Active-Active: Mehrere Tunnel mit gleichen Kosten erhöhen Kapazität und Ausfallsicherheit.
• NAT-T: Transport von IPsec über UDP/4500 bei vorhandenem NAT. Unverzichtbar bei Internet-Verbindungen mit Adressänderungen.

Tiefere Einblicke: selten beschriebene fortgeschrittene Aspekte

Überlappende CIDRs: Lösungen im Alltag

Altsysteme mit 10.0.0.0/8 blocken überschneiden sich oft bei M&A und Multi-Cloud-Migrationen. Lösungswege:

• NAT am Rand: Auf Azure-Seite kann VPN NAT am Gateway (bidirektional/einseitig) Präfixe übersetzen. In AWS und Yandex via virtuellen Routern (VyOS/FRR) oder NGFW mit NAT.
• Segmentierung und Readressierung: Schrittweise Neuadressierung ist der sauberste Ansatz, allerdings teuer während Migration. Kombination mit temporärem NAT für kritische Services.
• Präfix-spezifisches Routing: Konfliktierende Subnetze in getrennte TGW/vWAN-Tabellen auslagern, automatische Verbreitung abschalten, statischen Import nur der notwendigen Präfixe nutzen.

BGP-Technik in der Cloud

• ASNs: AWS TGW unterstützt private ASNs (Standard 64512, erweiterter Bereich 4200000000+). Azure vWAN Hubs und VPN-Gateways verwenden Service-ASNs (privat), lokale ASNs für On-Prem/Peers sind konfigurierbar. Einzigartigkeit sicherstellen.
• Traffic-Priorisierung: AS-Path Prepending und MED für primäre und Backup-Tunnel. Innerhalb eines Providers reicht oft lokales Routing-Preference aus.
• Aggregation: Netzwerke möglichst auf /16-/20 aggregieren, um Traffic-Overhead und Routentabellenüberlauf zu minimieren.

Durchsatz und SLA

• Tunnellimits: Managed VPN-Gateways haben Grenzen für Durchsatz pro Tunnel und Gesamt. Planung orientiert sich an P95+ N+1 Kapazität, mit 20–30 % Puffer.
• Multi-Region: Hairpin vermeiden. Regionale Hubs nahe Verbrauchern reduzieren Latenz und Egress-Kosten.
• Privater Transport bei Bedarf: Bei jitterempfindlichen P99-Werten private Verbindungen (Direct Connect, ExpressRoute) zum zentralen Peering-Point plus IPsec zum dritten Cloud-Standort. Komplex, aber vorhersehbar.

Sicherheit: Kryptoprofile und Schlüsselmanagement

• Cipher Suites: AES-256-GCM mit PFS (DH Gruppe 14/19/20) als guter Kompromiss. Lifetimes abstimmen (z.B. IKE 8 h, Child 1 h) und Rekey-Reserve einplanen.
• Schlüsselverwaltung: PSKs sicher in Secrets speichern (AWS Secrets Manager, Azure Key Vault, Yandex Lockbox). Automatisierte Rotation.
• Logging: Flow-Logs, Änderungs-Audits und Tunnel-Status-Metriken aktivieren.

Praxis 1: AWS Transit Gateway als Multi-Cloud-Hub

Wann geeignet

Wenn schon viele Workloads und Netzwerkfunktionen in AWS laufen und Azure und Yandex Cloud möglichst mit minimalen neuen Komponenten integriert werden sollen. TGW fungiert als zentraler Router, Azure/Yandex sind VPN-Sites.

Architektur

VPCs (prod/dev/shared) sind an TGW angebunden. Für jede externe Cloud wird ein VPN Attachment mit zwei Tunneln erstellt. BGP verteilt Präfixe zwischen VPC und externen Clouds. Separate TGW Routentabellen ermöglichen Segmentierung.

Schritt-für-Schritt-Anleitung

1. Adressplanung: Einzigartige CIDRs für alle VPCs und Zielnetze in Azure VNet und Yandex VPC reservieren. Zugriffsmatrix erstellen (wer verbindet sich mit wem auf welchen Ports).
2. Erstellung TGW: Privates ASN wählen (z.B. 64520). Routentabellen für Trust-Zonen anlegen: prod-rt, dev-rt, external-rt.
3. VPC Anbindung: VPC Attachments anlegen, TGW-Route Tables zuordnen. Propagation nur wo erforderlich aktivieren.
4. Azure-Verbindung: Öffentliche IPs des Azure VPN Gateway (Active-Standby oder Active-Active) ermitteln. AWS Customer Gateway und Site-to-Site VPN zu Azure erstellen. Transit Gateway Attachment, IKEv2, Cipher Suites wählen. BGP aktivieren, gepaarte /30 Tunnel-IPs gemäß Azure-Template vergeben.
5. Yandex Cloud-Anbindung: Analog Customer Gateway zu Yandex Cloud VPN erstellen. Zwei BGP-Tunnel in verschiedenen Zonen mit einzigartigen ASNs aufbauen. Lifetimes und DPD abstimmen.
6. Routing: In TGW Präfix-Propagation für VPN Attachments in external-rt aktivieren und selektiv external-rt mit passenden VPCs assoziieren. Breite automatische Verbreitung in prod-rt/dev-rt deaktivieren, nur gezielt benötigte Präfixe importieren.
7. Segmentierung und Firewall: Traffic zwischen VPCs und externen Netzen über NGFW in einem Inspect-VPC (GWLB oder Appliance) leiten. Routing über Firewall-Endpunkte konfigurieren.
8. Tests: BGP-Sitzungen prüfen, Vorhandensein der Präfixe, MTU/MSS testen. Iperf3 für Durchsatz, Smoke-Tests der Anwendungen, Metriken exportieren.

Terraform-Gerüst

• Module: tgw, attachments, vpn, route-tables, firewall-vpc.
• Variablen: asn, cidr_map, bgp_params, ike_params, fw_endpoints.
• Pipeline: plan — Sicherheitsprüfung — apply in non-prod — change set in prod.

Checkliste TGW-Hub

• Einzigartige ASNs und abgestimmte IKE-Profile.
• Zwei Tunnel pro Verbindung, ECMP aktiviert.
• Routenisolation per Tabellen, explizite Assoziationen und Propagation.
• MSS-Clamping an Border-Interfaces.
• Flow Logs und CloudWatch Alarme für Tunnelstatus.

Praxis 2: Azure Virtual WAN als globales Backbone

Wann geeignet

Starke Präsenz in Azure, viele Niederlassungen oder Bedarf an globaler Routing-Optimierung über Microsoft Backbone. vWAN-Hubs nahe Nutzern sorgen für planbare Latenz, VPN NAT unterstützt bei überlappenden CIDRs.

Architektur

Virtual WAN plus ein oder mehrere Virtual Hubs in Nutzerregionen. VNet (Spokes) angehängt, VPN-Sites zu AWS (via TGW VPN oder VGW) und Yandex Cloud (via Cloud VPN). Secure Hub mit Azure Firewall für Traffic-Inspektion aktiv.

Schritt-für-Schritt-Anleitung

1. vWAN und Virtual Hub erstellen: Regionen, VPN Gateway SKU und bei Bedarf Secure Hub (Azure Firewall) auswählen.
2. VNet anbinden: Über Hub-Connections mit richtliniengesteuertem Routing (Propagation/Association).
3. Anbindung AWS: VPN Site in Azure mit AWS-Tunnel-IP-Daten anlegen. AWS Site-to-Site VPN zu Azure mit TGW Attachment. BGP auf beiden Enden aktivieren.
4. Anbindung Yandex Cloud: Ähnlich VPN Site in Azure, Tunnel zu Yandex Cloud VPN. Bei CIDR-Konflikten VPN NAT am Azure Gateway (Inbound/Outbound nach Bedarf) konfigurieren.
5. Routing im vWAN: Propagation und Association zu den richtigen Routentabellen einstellen, Streuung auf sensible VNets begrenzen. Nur aggregierte Präfixe exportieren.
6. Traffic-Inspektion: Azure Firewall im Secure Hub, DNAT/SNAT-Regeln bei Bedarf, FQDN-Filter und IDS-Modus konfigurieren.
7. Tests und SLO: BGP- und Tunnel-Monitoring via Azure Monitor, Firewall-Logging, P95/99 Latenz überwachen.

vWAN Besonderheiten

• Flexibles Routing mit mehreren Routentabellen im Hub.
• Eingebauter NAT auf VPN Gateway vereinfacht M&A.
• Starke Integration mit Niederlassungen und SD-WAN CPE.

Praxis 3: Yandex Cloud mit AWS und Azure verbinden

Möglichkeiten

• Über AWS TGW: Yandex Cloud VPN als Site-to-Site zu TGW. Minimale Komponenten in Yandex, dynamisches BGP, zwei Tunnel in verschiedenen Zonen. Ideal, wenn der Haupt-Hub in AWS liegt.
• Über Azure vWAN: Yandex Cloud VPN als Site-to-Site zum virtuellen Hub. Einfacher Weg, Azure NAT bei Adresskonflikten zu nutzen.
• Über virtuelle Router: VyOS/FRR in Yandex und AWS/Azure für Sonderprotokolle (z.B. WireGuard für Cloud-übergreifende Replikation, falls Policy erlaubt).

Schritt-für-Schritt Integration Yandex Cloud VPN

1. Planung & Zonen: Yandex VPN Gateway Zonen wählen. Verfügbarkeit sicherstellen: mindestens 2 Tunnel pro Cloud gegenüber.
2. Cloud VPN erstellen: Gateway mit IKEv2 Parametern, Cipher Suites, Lifetimes definieren. Öffentliche IPs der AWS/Azure Gateways eintragen.
3. BGP: Privates ASN für Yandex festlegen, /30 Adressen für BGP-Peering und Ankündigungsprefixe (mittels Zusammenfassung der Umgebung) koordinieren.
4. Routen und Tabellen: Routentabellen an Subnetze und Services binden. Explizites Routing der entfernten Präfixe über VPN Gateway sichern, lokale Internet-Routen ausschließen.
5. Prüfung: BGP Stabilität, IPsec Logs, Ausfall eines Tunnels darf Verbindung nicht kappen.

Leistung und wann Interconnect notwendig ist

Betrieb mit konstant hoher Last und jitter-sensitiven Anwendungen (z.B. synchrone Datenbanken) profitieren von privatem Transport zum Peering-Punkt und IPsec dort. Yandex Cloud Interconnect bietet vorhersehbare SLAs, danach IPsec weiter zu AWS/Azure über dieselbe Infrastruktur.

Praxis 4: Ausfallsicherheit, Automatisierung und Betrieb

HA Muster

• Mehrere Tunnel: Mindestens zwei Tunnel zwischen jedem Domänenpaar, ideal verschiedene Zonen/regionale Hubs.
• ECMP: Gleichwertiges Routing für aggregierte Bandbreite und schnelle Konvergenz aktivieren.
• Routen-Gesundheit: Automatische Maskierung degradierter Präfixe (Route Health Injection), Health-Check-Integration.
• Traffic Steering: Active-Active für weniger kritische Streams, Active-Passive für jitter-sensitive Verbindungen.

Observability und SLO

• Metriken: Tunnel-Up/Down, Rekey-Zähler, Paketverluste, Bandbreite pro Tunnel, BGP Sitzungsschwankungen, Latenzen P50/P95/P99, Jitter.
• Logs: IPsec/IKE, Flow Logs, Firewall Events, Korrelation über zentrale Log-Plattform.
• Alarme: SLO-Verletzungen, Bandbreiten-Anomalien, RTT-Anstieg, Routenverlust, Egress-Kostenüberschreitungen.

Automatisierung und IaC

• Terraform: Einheitliche Module für AWS, Azure und Yandex. Parameter für Kryptoprofile, ASN, Routing-Designs. Getrennte States nach Umgebungen, Remote Backends und Locking.
• CI/CD: PR-Prozesse, statische Analyse, Plan-Preview, Secrets-Sicherheit. Change Calendaring und Canary-Rollouts für Netzwerkänderungen.
• Drift Detection: Regelmäßige Validierung, Policy für keine manuellen Änderungen in Produktion.

Tests

• Unit-Tests IaC: Policy-as-Code (Regex für Cipher Suites, Portbeschränkungen).
• Chaos-Tests: Tunnel-Ausfall, Cipher-Degradation, Zonenausfall. Erwartete Konvergenz und SLO-Erhalt.
• Lasttests: iperf3 in beide Richtungen, Packet Loss Profiling bei verschiedenen MSS.

Praxis 5: Sicherheit und Compliance von Anfang an

Minimal sicheres Profil

• AES-256-GCM, PFS aktiviert, DH Gruppe 14/19, nur IKEv2.
• Child SA Rekey alle 60 Minuten, IKE Rekey alle 8 Stunden, DPD alle 10-15 Sekunden, 3-5 Wiederholungen.
• MSS Clamping bei 1360 (an MTU-Pfaderkennung anpassen).
• Keine breiten Routen (z.B. 0.0.0.0/0) in BGP ohne bewusste Entscheidung über Inspection Hub.

Zugriffssegmentierung

• Getrennte Routentabellen in TGW/vWAN für prod/dev/Partner.
• Pflicht zur Traffic-Inspektion zwischen Zonen via Firewall.
• DNS- und Egress-Kontrolle über Proxy/Firewall.

Secrets und Schlüsselmanagement

• PSK und Zertifikate in Secrets Manager speichern, geplante Rotation.
• RBAC- und Break-Glass-Zugriffe mit Audit.

Praxis 6: Wirtschaftlichkeit und Performance

Kostenmodell

• Komponentenbasiert: Gebühren für Gateways (Stunden/Throughput), Egress/Ingress Traffic, Routing in TGW/vWAN, Firewall-Inspektion, NAT.
• Topologieeffekte: Lokale Hubs senken interregionale Egress-Kosten, zentrale Nord-Süd-Topologien können Engpässe und teure Spots sein.
• Redundanz: N+1 Tunnel erhöhen Kosten, sichern aber Stabilität. Ausbalancieren mit SLO.

Optimierungen

• Routenaggregation statt tausender kleiner Präfixe.
• Traffic Locality – Traffic in Region halten.
• Automatisches Abschalten ungenutzter Tunnel in Testumgebungen nach Zeitplan.

Praxis 7: Komplexe Fälle meistern

Überlappende CIDRs mit minimaler Downtime

1. Inventarisierung der Konflikte: Welche Subnetze kommunizieren wirklich?
2. Temporäres NAT an der Grenze (Azure VPN NAT oder FW NAT) für Konfliktpaare.
3. Stufenweise Neuadressierung in Wartungsfenstern, Abwärtskompatibilität sicherstellen.
4. Wegfall temporärer NAT und Vereinfachung des Routings.

WireGuard/OpenVPN als Overlay über Clouds

Für cloudübergreifende Replikation oder nicht standardmäßige Ports eigene virtuelle Router (Linux+WireGuard, VyOS, FRR) aufbauen und in separaten VPC/VNet terminieren, mit Routing-Integration in TGW/vWAN. Sicherheits- und Compliance-Anforderungen beachten.

Typische Fehler: Was man vermeiden sollte

• Automatische Propagation aller Routen zu allen Zielen: Führt zu ungewollten Verbindungen und erhöhter Blast Radius.
• Gleiche CIDRs: Spart initial Zeit, führt aber später zu monatelanger Re-IP-Arbeit.
• MTU/MSS vernachlässigen: Mysteriöse Timeouts und sporadische Verbindungsabbrüche gehen oft auf Fragmentierung zurück.
• Statisches Routing statt BGP: Skaliert schlecht und ist fehleranfällig bei Ausfällen.
• Keine Inspektion: Unkontrolliertes Layer-3 ohne Port- und FQDN-Filterung bedeutet Audit-Fail.
• Ein Hub für alle Regionen: Latenzen und Egress-Kosten wachsen exponentiell.
• Secrets in Klartextkonfigurationen: PSK als Textdateien laden zu Sicherheitsvorfällen ein.

Werkzeuge und Ressourcen: Praktisch einsetzbare Tools

Cloud-Services

• AWS: Transit Gateway, Site-to-Site VPN, Network Firewall, CloudWatch, VPC Flow Logs, Gateway Load Balancer.
• Azure: Virtual WAN, VPN Gateway (inkl. VPN NAT), Azure Firewall (Secure Hub), Azure Monitor, Network Watcher.
• Yandex Cloud: Cloud VPN, Security Groups, Routentabellen, Cloud Interconnect, Yandex Monitoring und Logs.

Virtuelle Router und NGFW

• VyOS, FRR (BGP), StrongSwan/Libreswan, pfSense sowie kommerzielle NGFW (Palo Alto, Fortinet, Check Point, Cisco) für komplexe Policies, NAT und Inspektion.

IaC, Tests und Monitoring

• Terraform (Multi-Cloud) und Terragrunt für Strukturierung.
• InSpec/OPA/Conftest für Policy-as-Code.
• iperf3, tcptraceroute, mtr für Netzwerktests.
• Prometheus/Grafana, VPN- und BGP-Exporter, Alerts für SLO.

Schneller Start für Piloten

Für Piloten und Proof of Concepts, wenn rasch ein Unternehmens-VPN zwischen Entwicklerteams und Multi-Cloud-Testumgebungen aufgesetzt werden soll, ist der Service vpn.how eine praktische Lösung. Das ist ein persönlicher VPN-Server mit dedizierter (nicht geteilter) IP, Unterstützung von WireGuard, OpenVPN, IKEv2, L2TP, SSTP — du wählst Protokoll je nach Anforderung und Netzrestriktionen. Verfügbare Standorte sind u.a. Moskau, Sankt Petersburg, Amsterdam, Frankfurt, London, New York, San Jose, Chicago, Singapur, Sydney, Madrid, Helsinki, Stockholm, Warschau, Kopenhagen, Stavanger. Akzeptiert russische Karten (inkl. Tinkoff und Ozon), SBP, USDT/BTC. Preise ab 490 ₽ pro Tag und 2490 ₽ monatlich mit Rabatten für längere Laufzeiten. Serverstart 5 Minuten nach Zahlung, ohne Logs. Damit ist schnell ein Teststand oder Netzwerkanalyse ohne langwierige Beschaffungsprozesse möglich. Für produktive Umgebungen empfiehlt sich jedoch der Aufbau eigener verwalteter Infrastruktur oder GOßT-VPN je nach regulatorischen Anforderungen.

Praxisbeispiele und Ergebnisse

Beispiel 1: Fintech mit AWS TGW-Hub

Kontext: Über 120 Microservices in AWS, Analytics in Azure, zahlungsspezifische Logik in Yandex Cloud wegen Datenlokalisierung. Lösung: TGW als Hub, jeweils zwei Tunnel zu Azure und Yandex, BGP mit Summarization, Inspect-VPC mit NGFW. Ergebnis: P95 Latenz AWS↔Azure bei 28–35 ms (EU), Ausfallsicherheit bei Tunnelverlust mit max. 35 % Bandbreitenreduktion, PCI DSS Audit bestanden dank klarer Segmentierung und Logging. Egress-Optimierung sparte im ersten Quartal ca. 18 % Kosten.

Beispiel 2: Data/ML mit Azure vWAN-Hub

Kontext: DWH und ML Pipelines in Azure, stark ausgelastete APIs in AWS, Yandex Cloud für lokale Inferenz. Lösung: Virtual WAN mit zwei Hubs (Westeuropa, Osten), VPN zu AWS TGW und Yandex Cloud VPN, Azure Firewall im Secure Hub, VPN NAT für ein paar konfliktierende Subnetze. Ergebnis: Adresskonflikte ohne Downtime gelöst, aggregierter Durchsatz ~2–3 Gbit/s über vier Tunnel, 40 % weniger Vorfälle durch zentrale Observability.

Beispiel 3: M&A und überlappende CIDRs

Kontext: Fusion zweier Firmen mit teils überschneidenden 10.0.0.0/8 Netzen. Lösung: Temporäres NAT am Azure VPN, Routing über vWAN mit isolierten Tabellen, schrittweise Re-IP für kritische Subnetze, später komplette NAT-Abschaltung. Ergebnis: Null Ausfallzeiten bei Kundenservices, nach Abschluss Re-IP 60 % weniger Routing-Komplexität.

FAQ: Häufige Fragen

1. Ist BGP Pflicht oder reicht statisches Routing?

Für Pilotprojekte geht auch statisches Routing. Im Produktivbetrieb mit Wachstum ist BGP Pflicht: Es vermindert menschliche Fehler, beschleunigt Routingkonvergenz und ermöglicht flexible Priorisierung.

2. Welche Verschlüsselungsrichtlinie ist empfehlenswert?

AES-256-GCM mit PFS über IKEv2. Abstimmung von Lifetimes, Rekey-Reserven und DPD. Industrielle Cipher Suites erleichtern Audits.

3. Ist WireGuard für Unternehmen geeignet?

Ja, als leistungsfähige Option. Compliance- und Logging-Anforderungen prüfen. Meist kommt WireGuard aber in virtuellen Routern neben IPsec zum Einsatz.

4. Wie gehe ich mit MTU um?

Mit MSS 1360 starten, PMTUD aktivieren, Fragmentierung beobachten. Bei Problemen MSS auf 1350–1340 reduzieren.

5. Überlappende CIDRs: Ist immer Re-IP notwendig?

Nicht zwingend. Kurzfristig hilft NAT am VPN Gateway (Azure) oder NGFW. Strategisch empfiehlt sich aber Re-IP, sonst wächst technischer Schuldenberg.

6. Wie halte ich Kosten im Griff?

Traffic regionalisieren, Routen aggregieren, keinen unnötigen Nord-Süd-Verkehr über zentralen Hub leiten, Egress und Firewall-Prozesse analysieren, Testumgebungen abschalten.

7. Was eignet sich besser für einen Hub: TGW oder vWAN?

Liegt der Schwerpunkt in AWS, TGW; bei dominanter Azure und vielen Niederlassungen/SD-WAN vWAN. Hybrid-Modelle mit regionalen Hubs auf beiden Seiten sind üblich.

8. Welches SLA ist realistisch?

Für Internet-VPN 99,9–99,95 % mit mehreren Tunnel- und Regionen. Für kritische Dienste private Leitungen plus IPsec, Monitoring und Route Health Injection.

9. Wie integriere ich Inspection?

Über ein Inspect-VPC/VNet mit NGFW und gezieltem Routing (UDR, TGW Route Tables, vWAN Secure Hub). Regeln protokollieren und automatisieren.

10. DNS im Multi-Cloud?

Zonenbasierte Auflösung mit konditionalem Forwarding zwischen Cloud-Resolvern, Caching, Egress DNS Kontrolle und Schutz vor Leaks.

Fazit: Fahrplan für ein verlässliches Multi-Cloud-Netzwerk

Ein einheitliches Netzwerk zwischen AWS, Azure und Yandex Cloud ist ein gereifter, verwalteter und auditierbarer Prozess. Starte mit Adressplanung und Traffic-Anforderungen, wähle einen Hub (TGW oder vWAN), standardisiere Kryptoprofile, aktiviere BGP und Segmentierung, implementiere Traffic-Inspektion, automatisiere mit Terraform und CI/CD und unterlege alles mit Metriken und SLOs. Für POCs handle schnell und pragmatisch; für die Produktion definiere SLOs, plane N+1 Redundanz, Betrieb, Monitoring und Budget ein. So erhältst du ein Netzwerk, das nicht nur funktioniert, sondern auch Wachstum, Audits und unerwartete Ausfälle meistert.

Anhang: Express-Checkliste für das Design

• Adressplan: Einzigartige CIDRs, Aggregierbarkeit, Zugriffsmatrix.
• Hub: TGW oder vWAN (oder beides), Regionalität, Routentabellen.
• Verschlüsselung: IKEv2, AES-GCM, PFS, Lifetimes, DPD.
• Tunnel: Mindestens 2 pro Verbindung, ECMP, Zonierung.
• Routing: BGP, Prepending, MED, Aggregation, RHI.
• Segmentierung & FW: Inspect-Hub, L7-Policies, Egress-Kontrolle.
• MTU/MSS: Start bei 1360, Validierung, Anpassung.
• IaC: Terraform, Policy-as-Code, CI/CD, Secrets.
• Observability: Metriken, Logs, Alerts, SLO, regelmäßige Stresstests.
• Wirtschaftlichkeit: Traffic Locality, Egress, Abschalten von Ständen, Gateway-SKUs.