In meinen Azure-Kursen taucht diese Frage regelmäßig auf, sobald wir das Thema Netzwerkarchitektur vertiefen: „Brauche ich wirklich Virtual WAN, oder reicht mir ein klassisches Hub-and-Spoke-Modell?“ Die Antwort ist – wie so oft in der Cloud – „es kommt drauf an.“ Aber auf was genau? Auf Standortanzahl, Verwaltungsaufwand, Budget und die Frage, ob Sie SD-WAN- oder BGP-Funktionalitäten (Border Gateway Protocol, ein Routingprotokoll) benötigen. Dieser Artikel liefert Ihnen eine strukturierte Entscheidungsgrundlage.
Was ist eigentlich was? Kurze Begriffsklärung
Beide Architekturen lösen dasselbe Grundproblem: Sie verbinden mehrere Azure-VNets (Virtual Networks) und ggf. On-Premises-Standorte miteinander. Der Unterschied liegt im Wie.
Das Hub-and-Spoke-Modell ist der klassische Ansatz. Sie deployen manuell ein zentrales Hub-VNet – typischerweise mit einer Azure Firewall, einem VPN Gateway oder einer ExpressRoute-Anbindung – und verbinden alle weiteren Spoke-VNets per VNet Peering mit diesem Hub. Routing, Policies und Security-Regeln liegen vollständig in Ihrer Hand. Das bedeutet Flexibilität, aber auch operativen Aufwand.
Azure Virtual WAN (vWAN) ist Microsofts managed Service für großflächige Netzwerktopologien. Azure übernimmt dabei das Routing im Hintergrund – inklusive Any-to-Any-Konnektivität zwischen Spokes, Branches und VPN-Tunneln. Sie erhalten einen sogenannten Virtual Hub, der automatisch skaliert und von Microsoft betrieben wird. Optional lässt sich ein Secured Virtual Hub aktivieren, der Azure Firewall oder einen Drittanbieter-NVA (Network Virtual Appliance) integriert.
Ein Virtual WAN im Azure Portal: Hubs, VPN Sites und verbundene VNets auf einen Blick.
Vergleich: Virtual WAN vs. Hub-and-Spoke auf einen Blick
Die folgende Tabelle zeigt die wesentlichen Unterschiede. Ich habe sie so aufgebaut, wie ich sie auch in meinen Azure-Kursen einsetze – kompakt und entscheidungsrelevant.
| Kriterium | Hub-and-Spoke (manuell) | Azure Virtual WAN |
|---|---|---|
| Verwaltungsaufwand | Hoch – Routing, UDRs, Gateways selbst pflegen | Gering – Microsoft managed Routing |
| Any-to-Any-Konnektivität | Nur mit zusätzlichem Routing-Aufwand (NVA oder Route Server) | Nativ, out of the box |
| VPN-Skalierung (Branches) | Begrenzt durch manuelles Gateway-Management | Skaliert automatisch bis zu 20 Gbps pro Hub |
| BGP-Support | Möglich, aber manuell konfiguriert | Integriert, automatisiert |
| Kosten | Geringer bei wenigen Standorten | vWAN-Hub-Gebühr fällt immer an (~$1,25/Std. je Hub) |
| ExpressRoute-Integration | Manuell über Gateway | Nativ im Virtual Hub |
| SD-WAN-Integration (z. B. Barracuda, Cisco) | Eigene NVA-Lösung notwendig | Integrierte NVA-Partner im Hub |
| Geeignet für Anzahl Standorte | 1–10 Standorte typisch | Ab ~5–10 Standorte, ideal >20 |
| Lernkurve / Komplexität initial | Mittel – bekannte Azure-Netzwerkkonzepte | Höher – neues Konzept, andere Logik |
Merksatz: Virtual WAN ist kein Ersatz für ein schlechtes Netzwerkdesign – es ist ein Multiplikator. Wer seine Netzwerkarchitektur nicht versteht, wird mit vWAN schneller in Probleme laufen, nicht langsamer.
Typische Fallstricke aus der Praxis
Folgendes Problem aus der Praxis: Ein mittelständisches Unternehmen mit vier Azure-Regionen und zehn Filialanbindungen über Site-to-Site-VPN entscheidet sich für Hub-and-Spoke. Nach sechs Monaten kämpft das Team mit User Defined Routes (UDRs – manuell angelegte Routingtabelleneinträge), die bei jedem neuen Spoke-VNet gepflegt werden müssen. Der operative Overhead wächst linear mit der Anzahl der Spokes.
Ich hatte mich in diesem Zusammenhang mit einem Netzwerkarchitekten unterhalten, der den Wechsel auf Virtual WAN als „den schmerzhaften, aber richtigen Schritt“ beschrieb – weil man zunächst das bestehende Routing vollständig neu denken muss. Der Hub im vWAN-Modell ist kein VNet, das Sie direkt bearbeiten. Er ist eine managed Ressource. Das bedeutet: keine direkten VM-Deployments im Hub, kein freier Zugriff auf Subnets.
Ein zweiter Fallstrick betrifft die Kosten. Wer nur zwei Standorte hat und ein einziges Hub-VNet betreibt, zahlt für Azure Virtual WAN deutlich mehr – allein durch die Hub-Grundgebühr. Cost Management (Azure-Dienst zur Kostenüberwachung und -analyse) sollte deshalb vor jeder Architekturentscheidung konsultiert werden.
Cost Management hilft dabei, die laufenden Kosten eines Virtual Hubs frühzeitig zu erkennen und zu bewerten.
Ein dritter Punkt, der in meinen Azure-Kursen oft für Diskussionen sorgt: Transitive Konnektivität. Im klassischen Hub-and-Spoke-Modell können Spoke-A und Spoke-B nicht direkt miteinander kommunizieren, ohne den Traffic durch den Hub zu routen – und dafür braucht man entweder eine NVA oder Azure Firewall im Hub. Bei Virtual WAN ist diese Any-to-Any-Konnektivität standardmäßig vorhanden. Das klingt nach einem klaren Vorteil für vWAN – ist aber nur dann relevant, wenn Sie diese Kommunikation tatsächlich benötigen.
Praxisempfehlung: Entscheidungsrahmen für KMUs
Noch mal in Kürze: Hier ist eine KMU-taugliche Entscheidungslogik, kurz, knapp und strukturiert, zum Abharken:
- Weniger als 5 Azure-VNets, 1–2 On-Premises-Standorte, kein SD-WAN: Klassisches Hub-and-Spoke. Günstiger, einfacher zu betreiben, ausreichend flexibel.
- 5–15 VNets, mehrere Filialen, VPN-Skalierung notwendig: Evaluieren Sie Virtual WAN Basic oder Standard. Testen Sie in einer Sandbox-Umgebung, bevor Sie migrieren.
- Mehr als 15 Standorte, globale Regionen, SD-WAN-Partner oder ExpressRoute Global Reach: Azure Virtual WAN Standard ist hier die empfohlene Architektur.
Für ein typisches KMU mit einer Azure-Region, einem On-Premises-Rechenzentrum und drei bis fünf VNets empfehle ich konkret folgende Minimalstruktur mit Hub-and-Spoke:
- Hub-VNet mit Azure Firewall (Standard-Tier) und einem VPN Gateway (Generation 2)
- Spoke-VNets per VNet Peering angebunden, „Use Remote Gateways“ aktiviert
- UDRs in den Spoke-VNets, die den gesamten Outbound-Traffic an die Azure Firewall senden
- Azure Monitor und Network Watcher (Diagnosetool für Azure-Netzwerke) für Sichtbarkeit
Wenn Ihr Unternehmen wächst und Sie merken, dass das manuelle Routing zum Engpass wird, ist der Migrationspfad zu Virtual WAN dokumentiert – aber er erfordert Planung. Starten Sie diesen Schritt nicht unter Zeitdruck.
Praxistipp: Nutzen Sie das offizielle Azure Virtual WAN-Migrationshandbuch aus der Microsoft-Dokumentation als Checkliste. Und wenn Sie sich unsicher sind, welcher Ansatz zu Ihrer konkreten Infrastruktur passt: In meinen Azure-Kursen gehen wir genau solche Szenarien anhand echter Lab-Umgebungen durch – inklusive Routing-Debugging und Kostenvergleich.