Azure Virtual WAN vs. Hub-and-Spoke: Die Unternehmensentscheidung 2026

Für Netzwerkarchitekten in Unternehmen ist die Debatte zwischen Azure Virtual WAN (vWAN) und einer selbstverwalteten Hub-and-Spoke-Topologie nicht länger eine einfache Frage von verwalteter und nicht verwalteter Infrastruktur. Mit Blick auf das Jahr 2026 hängt die Entscheidung von einem nuancierten Verständnis der Datenverkehrsmuster, der Funktionstiefe der erforderlichen Sicherheits-Appliances und der Gesamtbetriebskosten (TCO) bei Skalierung ab. Das Versprechen einer nahezu unendlichen, programmatischen Kontrolle über einen globalen Transit-Fabric macht vWAN für die meisten großen Unternehmen zur strategischen Standardlösung, wodurch sich das Gespräch über reine Konnektivität hinaus zu einem intelligenten, richtlinienbasierten Netzwerk entwickelt.

Das klassische Hub-and-Spoke: Maximale Kontrolle, maximale Komplexität

Das traditionelle Azure Hub-and-Spoke-Modell ist die direkte Übertragung des Rechenzentrumsdesigns vor Ort. Ein zentrales Hub Virtual Network (VNet) beherbergt Shared Services, am kritischsten ein Paar von Network Virtual Appliances (NVAs) zur Datenverkehrsinspektion und Routing-Kontrolle. Spokes, die Anwendungs-Workloads beherbergen, werden über VNet Peering mit dem Hub verbunden. Die Kontrolle ist explizit und granular, hauptsächlich durch User-Defined Routes (UDRs). Sie erstellen eine Routentabelle, wenden diese auf ein Subnetz an und definieren den nächsten Hop für bestimmte Präfixe – typischerweise den internen Load Balancer, der Ihrem NVA-Paar vorgeschaltet ist.

In diesem Modell ist die NVA König. Ob es sich um eine Palo Alto Networks VM-Series mit PAN-OS 11.2, eine FortiGate-VM mit FortiOS 7.6 oder eine Cisco Catalyst 8000V handelt, Sie behalten die volle Kontrolle über deren Konfiguration. Sie verwalten High Availability (HA), Skalierung (über VM Scale Sets) und komplexe Routing-Policys direkt auf der Appliance. Das ist sowohl ihre größte Stärke als auch ihre bedeutendste Schwäche. Der operative Aufwand für die Verwaltung von HA-Paaren, Routentabellen über Dutzende oder Hunderte von Spokes hinweg und der zugrunde liegenden VM-Infrastruktur ist erheblich. Eine Änderung der Routing-Policy, wie die Einführung eines neuen Dienstes im Hub, kann die Aktualisierung von UDRs in jedem einzelnen Spoke VNet erfordern – ein anfälliger und fehleranfälliger Prozess, selbst mit reifen Infrastructure as Code (IaC)-Praktiken unter Verwendung von Terraform oder Bicep.

Virtual WAN: Azure als globaler Transit-Provider

Azure Virtual WAN abstrahiert die zugrunde liegende Netzwerkinfrastruktur in einen plattformverwalteten Dienst. Im Kern bietet vWAN eine globale Transitnetzwerkarchitektur, die die Any-to-Any-Konnektivität zwischen Branches (VPN/SD-WAN), Remote-Benutzern, Rechenzentren (ExpressRoute) und VNets vereinfacht. Sie stellen in jeder erforderlichen Azure-Region einen Virtual Hub bereit, und dieser Hub fungiert als das Zentrum Ihres Universums für diese Region. Die Konnektivität basiert nicht auf Peering, sondern auf „Verbindungen“ zum Hub. Der Hub selbst enthält verwaltete Router, die Routen automatisch zwischen allen verbundenen Entitäten propagieren.

Das entscheidende Unterscheidungsmerkmal ist dieses integrierte Routing. Wenn Sie ein VNet mit dem vWAN-Hub verbinden, wird dessen Adressraum vom Hub-Router gelernt. Wenn Sie einen ExpressRoute Circuit verbinden, werden dessen angekündigte Präfixe gelernt. Der Hub-Router kündigt dann diese gelernten Routen basierende auf der konfigurieren Policy allen anderen verbundenen Entitäten an. Dies eliminiert die Notwendigkeit der manuellen UDR-Verwaltung für das Transit-Routing. Das Hinzufügen eines neuen VNets oder einer neuen Branch-Stelle erfordert keine Änderung der Konfiguration eines vorhandenen Spokes; das Routing wird dynamisch aktualisiert. Dies ist eine plattformbasierte Lösung für das Skalierbarkeitsproblem, das klassische Hub-and-Spoke-Designs plagt.

Secured Hub Deep Dive: Azure Firewall Premium vs. Integrierte NVA

Der „Secured Virtual Hub“ ist der Ausgangspunkt der Sicherheitsdebatte. Dies ist ein vWAN-Hub mit einer integrierten Sicherheits-Appliance. Sie haben zwei primäre Optionen: Azure Firewall oder eine Third-Party-NVA aus dem Azure Marketplace.

Azure Firewall Premium: Die fähige native Lösung

Bis 2026 wird Azure Firewall Premium zu einer beeindruckenden NGFW-as-a-Service-Lösung herangereift sein. Es bietet bereits wesentliche Bedrohungspräventionsfunktionen wie IDPS auf Signaturenbasis, vollständige TLS-Inspektion (ein notorisch schwierig in der Cloud zu implementierendes Feature), URL-Filterung und Webkategorien-Filterung. Für die East-West-Traffic-Inspektion zwischen Spokes oder North-South-Egress ist es oft ausreichend. Sein Hauptvorteil ist, dass es ein echter Plattformdienst ist. Sie verwalten keine zugrunde liegenden VMs. Sie definieren eine Policy, ordnen sie dem Hub zu, und Azure übernimmt die Skalierung und Ausfallsicherheit. Der Durchsatz wird in SKU-basierten Bereitstellungen definiert, beginnend bei 20 Gbit/s und höher skalierbar.

Es ist jedoch kein direkter Ersatz für eine dedizierte, erstklassige NVA. Ein Sicherheitsteam, das an die granularen App-ID-Policies eines PA-5440 oder die erweiterten Threat Feeds eines FortiGate 1800F gewöhnt ist, wird die Möglichkeiten der Azure Firewall als breit, aber nicht so tief empfinden. Die Signatursätze sind zwar robust, aber möglicherweise nicht so spezialisiert, und die Anpassung von Bedrohungspräventionsprofilen ist weniger granular als das, was auf einem dedizierten NVA-Betriebssystem wie PAN-OS oder FortiOS verfügbar ist.

NVA in vWAN: Das Beste aus beiden Welten?

Für Organisationen, die ihre spezifische NGFW benötigen, ermöglicht vWAN die Bereitstellung von NVAs direkt im Hub. Dies ist nicht dasselbe wie die Bereitstellung einer NVA in einem klassischen Hub-VNet. Wenn Sie eine FortiGate- oder Palo Alto Networks-NVA in einem vWAN-Hub bereitstellen, fungiert diese als verwaltete Anwendung. Azure verwaltet den Lebenszyklus, die Skalierung und die Hochverfügbarkeit der zugrunde liegenden VMSS. Entscheidend ist, dass das Routing über BGP Peering zwischen der NVA und dem vWAN-Hub-Router abgewickelt wird. Sie wenden keine UDRs mehr an, um den Datenverkehr zur NVA zu leiten; Sie verwenden vWAN Routing Intent und Policies, um zu deklarieren, welche Datenflüsse (Private, Internet) zuerst zur NVA zur Inspektion gesendet werden müssen. Die NVA inspiziert dann den Datenverkehr und leitet ihn, falls zulässig, zur Weiterleitung an den Hub-Router zurück. Dies behält das zentralisierte, dynamische Routing von vWAN bei und ermöglicht gleichzeitig die erstklassige Sicherheitsinspektion.

Größen- und Kostenanalyse: Eine Geschichte zweier Topologien

Modellieren wir ein reales Szenario, um die Kosten zu vergleichen. Betrachten wir ein Unternehmen mit Präsenz in East US 2 und Westeuropa. Jede Region verfügt über einen Hub, 50 Spoke-VNets, einen 10-Gbit/s-ExpressRoute-Circuit und 2.000 SD-WAN-Branches, die über VPN verbunden sind. Nehmen wir 50 TB Inter-Spoke-Datenverkehr (VNet-to-VNet) pro Monat innerhalb jeder Region an.

Klassisches Hub-Spoke-Kostenmodell (pro Region)

• NVA-Cluster: Zwei FortiGate-VM08-Instanzen (für ca. 10 Gbit/s Bedrohungsschutzdurchsatz) mit BYOL-Lizenzierung. Die VM-Kosten allein betragen ca. 1,50 $/Stunde * 2 * 730 Stunden/Monat = ca. 2.190 $/Monat. Hinzu kommen Softwarelizenzkosten.
• Azure Standard Load Balancer (Intern/Extern): ca. 50 $/Monat.
• Public IPs: ca. 20 $/Monat.
• VNet Peering (Der Kostentreiber): Dies ist der kritische Kostenfaktor. Datenverkehr, der von Spoke A -> Hub -> Spoke B fließt, wird für Ingress und Egress auf dem Peering-Link berechnet. Für 50 TB Datenverkehr: 50 * 1024 GB = 51.200 GB. Die Kosten betragen 0,01 $ pro GB. Also: 51.200 GB * 0,01 $/GB * 2 (Ingress/Egress) = 1.024 $/Monat. Diese Kosten skalieren linear mit dem Datenverkehrsvolumen.
• Verwaltungsaufwand: Diese versteckten Kosten sind erheblich. Die Engineering-Stunden, die für die Verwaltung von UDRs, NVA-Patching/-Upgrades und HA-Failover erforderlich sind, sind beträchtlich.

Azure Virtual WAN-Kostenmodell (pro Region)

• Standard vWAN Hub: ca. 1,25 $/Stunde * 730 Stunden = ca. 912,50 $/Monat.
• VNet Connections: 50 Verbindungen * 0,05 $/Stunde * 730 Stunden = 1.825 $/Monat.
• Scale Units: Um ca. 10 Gbit/s VNet-Verkehr zu bewältigen, benötigen Sie 5 Scale Units (2 Gbit/s pro Einheit). Diese kosten jeweils 0,25 $/Stunde. 5 * 0,25 $/Stunde * 730 Stunden = 912,50 $/Monat.
• Datenverarbeitung (VNet-zu-VNet): vWAN berechnet den durch den Hub verarbeiteten Datenverkehr. Für unsere 50 TB: 51.200 GB * 0,02 $/GB = 1.024 $/Monat. Dies ist vergleichbar mit den Peering-Kosten, aber vorhersehbarer und schließt die Routing-Infrastruktur ein.
• Azure Firewall Premium: Eine Bereitstellung mit 10 Gbit/s Verarbeitungsleistung und Premium-Funktionen kostet ca. 2.500 $/Monat.

Auf den ersten Blick scheinen die vWAN-Komponentenkosten höher. Das vWAN-Modell eliminiert jedoch die VNet-Peering-Gebühren für Transitverkehr vollständig. Noch wichtiger ist, dass es den Betriebsaufwand für die Verwaltung des komplexen UDR-Netzwerks und der selbstverwalteten NVAs drastisch reduziert. Die Total Cost of Ownership (TCO) bei Skalierung, insbesondere in Multi-Region-Szenarien, spricht oft für vWAN.

Multi-Region-Routing: vWANs unfairer Vorteil

Hier übertrifft vWAN das klassische Modell wirklich. In einem traditionellen Setup erfordert die Verbindung zweier regionaler Hubs entweder einen weiteren Satz von NVAs für Hub-zu-Hub-VPN oder die Verwendung von Global VNet Peering. Global Peering ist teuer (ca. 0,035 bis 0,12 $/GB je nach Region) und erzeugt ein Punkt-zu-Punkt-Mesh, das nicht skaliert. Mit vWAN sind die Hubs standardmäßig über den Microsoft Global Backbone verbunden. Die regionalen Hub-Router tauschen Routen aus und ermöglichen so eine nahtlose Inter-Hub-Konnektivität. Sie erhalten ein vollständig geroutetes, globales Netzwerk, das von der Plattform verwaltet wird. Die Erweiterung Ihres Netzwerks auf eine neue Region ist so einfach wie die Bereitstellung eines neuen vWAN-Hubs und dessen Verbindung; das globale Routing wird automatisch aktualisiert.

Häufiger Fehler: Die "Lift and Shift" NVA-Denkweise in vWAN

Ein häufiger Fehler besteht darin, zu versuchen, eine NVA innerhalb eines vWAN-Hubs so zu verwalten, als befände sie sich in einem Standard-VNet. Man kann beispielsweise keine mehreren Netzwerkschnittstellen der NVA zuweisen oder HA manuell konfigurieren. Die Plattform übernimmt dies. Ihre Interaktion erfolgt nicht mit der VM, sondern mit der BGP-Sitzung, die sie mit dem Hub-Router und den Routing Intent Policies herstellt. Ihr Ziel ist es, die Routing-Entscheidungen des vWAN-Hubs zu beeinflussen, indem Sie spezifische Routen von der NVA ankündigen, und nicht, das Netzwerk manuell mit UDRs zu verbinden. Die Betrachtung der NVA als bloße Policy-Engine, die Datenverkehr über deklarative Policy empfängt, ist das korrekte mentale Modell.

Wann man Virtual WAN NICHT verwenden sollte (Edition 2026)

Trotz seiner Vorteile ist vWAN keine Universallösung. Es gibt spezifische Szenarien, in denen ein klassisches Hub-and-Spoke oder sogar eine einfachere Topologie überlegen bleibt.

• Kleine, Single-Region-Bereitstellungen: Wenn Ihr gesamter Cloud-Footprint aus weniger als 10-15 VNets in einer einzigen Region mit überschaubarem Datenverkehr besteht, ist vWAN überdimensioniert. Die Kosten und die Komplexität eines einfachen Hub-VNets mit Azure Firewall Basic/Standard oder einem kleinen FortiGate/Palo Alto NVA-Paar werden deutlich geringer sein.
• Hyper-Customized Routing: Die vWAN-Routing-Engine ist leistungsstark, aber meinungsstark. Wenn Ihre Architektur auf komplexen, nicht-standardmäßigen Routing-Verhaltensweisen wie Policy-Based Routing (PBR) basiert, die auf Quell-IP oder Applikationsebene-Metriken beruhen und nicht durch BGP oder vWAN Routing Intent ausgedrückt werden können, benötigen Sie die volle Kontrolle einer NVA in einem klassischen Hub-VNet (potenziell mit Azure Route Server zur Vereinfachung der BGP-Propagierung).
• Nicht unterstützte NVA-Topologien: Wenn Ihre Sicherheitsarchitektur eine sehr spezifische, nicht unterstützte NVA-Funktion erfordert – zum Beispiel ein proprietäres Clustering-Protokoll eines Anbieters, das Layer-2-Adjazenz oder Multi-Context-Virtualisierung erfordert, die nicht mit dem „NVA-als-Appliance“-Modell in vWAN übereinstimmt – werden Sie zu einer DIY-Hub-Architektur gezwungen.

Fazit: Die strategische Wahl für Unternehmensskalierung

Bis 2026 ist für jedes Unternehmen, das in großem Maßstab über mehrere Azure-Regionen hinweg tätig ist, die Entscheidung klar. Die operative Agilität, das automatisierte globale Routing und die vorhersagbare Skalierbarkeit von Azure Virtual WAN machen es zur überlegenen Grundlage. Während das klassische Hub-and-Spoke-Modell ultimative Kontrolle bietet, geht diese Kontrolle mit einem hohen Preis an Komplexität und operativer Fragilität einher. Die Möglichkeit, erstklassige NGFW NVAs in den vWAN-Hub zu integrieren, mildert den primären historischen Nachteil und kombiniert plattformnative Skalierung mit spezialisierter Sicherheit. Die Debatte dreht sich nicht länger darum, was mehr Funktionen bietet, sondern darum, welche die intelligenteste und skalierbarste Plattform für ein globales Unternehmensnetzwerk bereitstellt.

Um Ihr Azure-Netzwerk der nächsten Generation zu entwerfen und die genaue TCO für Ihre Umgebung zu bewerten, erkunden Sie unsere Expert Consulting Services unter techleague.io. Vielleicht interessieren Sie sich auch für unsere Deep Dives zu Azure Route Server für erweiterte NVA-Integration oder Sicherung von ExpressRoute Private Peering End-to-End.