Hub-Spoke vs. vWAN
Problemstellung
Section titled “Problemstellung”Beide Modelle lösen die gleiche Grundfrage: Wie verbinde ich viele VNets/Standorte so, dass Routing, Security Controls und Betrieb handhabbar bleiben? Die Entscheidung ist weniger “Feature” als vielmehr Betriebsmodell.
Hub-Spoke: Stärken und Grenzen
Section titled “Hub-Spoke: Stärken und Grenzen”Hub-Spoke ist ein sehr kontrollierbares Muster:
- zentraler Hub mit Shared Services (Firewall, DNS, Bastion, Proxy)
- Spokes für Workloads
- Peering als primärer Vernetzungsmechanismus
Stärken:
- sehr transparentes Routing
- passt gut zu “klassischen” NVA-/Firewall-Designs
- ideal, wenn du wenige zentrale Hubs und klar definierte Spokes hast
Grenzen:
- bei vielen Spokes/Subscriptions wächst die Peering-/UDR-Komplexität
- Multi-Region und viele Standorte können schnell operational schwer werden
vWAN: Stärken und Grenzen
Section titled “vWAN: Stärken und Grenzen”Virtual WAN ist ein Managed-Connectivity-Ansatz:
- zentrale Virtual Hub(s)
- vereinheitlichte Anbindung von VPN/ExpressRoute und Spokes
- skalierbarer, standardisierter Verbund
Stärken:
- gut, wenn viele Standorte/Branches oder viele VNets zusammenkommen
- standardisierte “Connectivity as a Service”
- reduziert manuellen Peering-Aufwand
Grenzen:
- weniger “low-level” Kontrolle als reines Hub-Spoke
- NVA-/Firewall-Integration und Routing-Design muss sauber geplant werden
- Kostenmodell ist anders (Hub, Routing, Datentransfer)
Entscheidungskriterien (praxisnah)
Section titled “Entscheidungskriterien (praxisnah)”Wähle tendenziell Hub-Spoke, wenn:
- du ein klares, eher statisches Netzwerk mit wenigen Hubs betreibst,
- du maximale Transparenz über Routing/UDRs brauchst,
- du bereits ein etabliertes NVA/Firewall-Design hast.
Wähle tendenziell vWAN, wenn:
- du viele Standorte oder viele VNets/Subscriptions erwartest,
- du Connectivity standardisieren willst (weniger individuelle Peering-Setups),
- du Multi-Region-Hubs als Managed Pattern betreiben möchtest.
Traffic-Patterns, die die Entscheidung beeinflussen
Section titled “Traffic-Patterns, die die Entscheidung beeinflussen”- Viele Branches → Cloud (North-South): vWAN spielt seine Stärken aus.
- Viele Spokes untereinander (East-West): Hub-Spoke ist transparent, vWAN kann es standardisieren – aber plane Routing/Inspection sauber.
- Zentraler Egress/Inspection: In beiden Modellen möglich; entscheidend ist, wie du Policies/Routes betreibst und wie viel Kontrolle du brauchst.
Wenn du “alles durch eine zentrale Firewall” willst, ist weniger die Topologie das Problem als das Routing- und Betriebsmodell (UDRs, Propagation, Ausnahmen).
Migration und Mischformen
Section titled “Migration und Mischformen”In der Realität gibt es Mischformen:
- vWAN für Standortanbindung (VPN/ER) und Standard-Connectivity
- klassische Hubs für Spezialfälle (z. B. sehr kontrollierte Inspection/Legacy)
Plane Migration als Produkt: Pilot-Region, klare Erfolgskriterien (Routing, DNS, Latency, Operations), dann Wellen.
Typische Stolperfallen
Section titled “Typische Stolperfallen”- “Wir wechseln zu vWAN und sparen automatisch Komplexität”: stimmt nur, wenn du auch Prozesse/Standards konsolidierst.
- DNS/Name Resolution wird unterschätzt: Topologie löst DNS nicht. Plane Resolver/Forwarding als eigenes Design.
- Kosten werden zu spät betrachtet: vWAN ist nicht per se teurer, aber die Kostenpunkte sind anders.
Nächster Schritt
Section titled “Nächster Schritt”Wenn Private Endpoints oder Hybrid-DNS eine Rolle spielen, lies zuerst Private Endpoints & DNS: Stolperfallen. In der Praxis entscheidet DNS oft über den Erfolg der Topologie.