Nachdem ich fast fünf Jahre damit verbracht habe, traditionelle Hub-and-Spoke-Architekturen in Azure aufzubauen und zu warten, war ich zugegebenermaßen skeptisch, als Microsoft Virtual WAN anpries. Ein weiterer verwalteter Dienst, der verspricht, alle unsere Probleme zu lösen? Das hatte ich schon einmal gehört. Aber nachdem ich in den letzten achtzehn Monaten in mehreren Unternehmen mit vWAN gearbeitet habe, kann ich ehrlich sagen, dass es meine Einstellung zu Cloud-Netzwerken verändert hat.

Der Wendepunkt kam für mich während einer besonders schmerzhaften Netzwerkerweiterung für einen Finanzdienstleistungskunden. Wir stießen an die gefürchteten VNet-Peering-Grenzen, manuelle Routenkonfigurationen brauchten Wochen, um korrekt implementiert zu werden, und offen gesagt, der operative Overhead beanspruchte viel zu viel Bandbreite unseres Teams. Da beschloss ich, Virtual WAN einen ernsthaften Blick zu schenken.

Der traditionelle Ansatz, der uns gut gedient hat (bis er es nicht mehr tat)

Jahrelang war das klassische Hub-and-Spoke-Muster unsere bevorzugte Architektur. Es machte Sinn: Zentralisieren Sie Ihre gemeinsamen Dienste in einem Hub-VNet, verbinden Sie Ihre Workload-VNets als Speichen, und leiten Sie alles durch die Mitte. In der Regel haben wir etwas in der Art eingesetzt:

Hub VNet: 10.0.0.0/16
├── AzureFirewallSubnetz: 10.0.1.0/26
├── GatewaySubnetz: 10.0.2.0/27
└── SharedServicesSubnetz: 10.0.3.0/24

Spoke-VNets:
├── Produktions-VNet: 10.1.0.0/16
├── Entwicklungs-VNet: 10.2.0.0/16
└─── DMZ-VNet: 10.3.0.0/16

Dieser Ansatz funktionierte hervorragend für kleinere Implementierungen. Die Architektur war einfach, die Kosten waren vorhersehbar und die meisten Netzwerkingenieure konnten sich ohne große Probleme damit zurechtfinden. Aber das Problem ist, dass es sich nicht gut skalieren lässt.

Was uns wirklich überrascht hat, war, wie schnell wir an die Grenzen der VNet-Peerings von Azure Resource Manager stießen. Sicher, 500 Peerings pro VNet klingt nach viel, bis Sie ein großes Unternehmen mit Dutzenden von Geschäftseinheiten unterstützen, von denen jede über ihre eigene Entwicklungs-, Staging- und Produktionsumgebung verfügt. Und lassen Sie mich gar nicht erst von der manuellen Arbeit anfangen, die mit dem Hinzufügen jeder neuen Speiche verbunden war. Jede neue Verbindung bedeutete eine Aktualisierung der Routentabellen, die Konfiguration von Sicherheitsregeln und das Testen der Konnektivität – alles manuelle Prozesse, die die Möglichkeit menschlicher Fehler mit sich brachten.

Auch die Kosten begannen sich zu summieren, vor allem, als wir regionsübergreifende Konnektivität benötigten. Die VNet-Peering-Gebühren zwischen den Regionen können schnell teuer werden, wenn Sie große Datenmengen zwischen den Regionen verschieben.

Was Virtual WAN tatsächlich ändert

Mit Virtual WAN ändert sich die Art und Weise, wie Sie über die Netzwerktopologie denken, grundlegend. Anstatt einzelne VNet-Peerings und Routentabellen zu verwalten, arbeiten Sie mit verwalteten Hubs, die diese Komplexität für Sie übernehmen. Nachdem ich es in mehreren Kundenumgebungen implementiert hatte, fiel mir vor allem auf, wie viel betrieblicher Aufwand einfach wegfällt.

Die Architektur sieht dem traditionellen Hub-and-Spoke-System täuschend ähnlich, aber die zugrunde liegende Mechanik ist völlig anders. Hier sehen Sie eine typische vWAN-Konfiguration, die ich kürzlich eingerichtet habe:

Virtuelles WAN: Global-Enterprise-vWAN

Hub 1 (East US):
Address Space: 10.100.0.0/23
Connected VNets:
– Production-East: 10.1.0.0/16
– Development-East: 10.2.0.0/16
Security: Azure Firewall
Gateways: S2S VPN, ExpressRoute

Hub 2 (Westeuropa):
Adressraum: 10.101.0.0/23
Angeschlossene VNets:
– Produktion-West: 10.11.0.0/16
– Entwicklung-West: 10.12.0.0/16
Sicherheit: Azure Firewall
Gateways: S2S VPN, ExpressRoute

Die Magie liegt darin, wie diese Hubs miteinander kommunizieren und das Routing verwalten. Es gibt keine manuelle Peering-Konfiguration, keine benutzerdefinierten Routentabellen, die für die grundlegende Konnektivität gepflegt werden müssen, und die Hubs sorgen automatisch für die optimale Pfadauswahl zwischen den Regionen.

Eine Sache, die mich wirklich beeindruckt hat, war die Routing-Intelligenz. Wenn Sie in herkömmlichen Architekturen den Datenverkehr von einer Speiche in einer Region zu einer Speiche in einer anderen Region leiten wollen, muss er Ihre Hub-Infrastruktur zweimal durchqueren – einmal, um den ersten Hub zu erreichen, dann über die Inter-Hub-Verbindung und dann über den Ziel-Hub. Virtual WAN optimiert diese Pfade automatisch und findet oft direktere Routen, die die Leistung verbessern und die Kosten senken.

Auch die Sicherheitsgeschichte wird besser

Die Sicherheitsintegration war ein weiterer Bereich, in dem mich vWAN überrascht hat. Bei herkömmlichen Hub-and-Spoke-Implementierungen haben wir viel Aufwand betrieben, um sicherzustellen, dass Azure Firewall richtig im Verkehrsfluss positioniert ist und dass alle unsere Routentabellen so konfiguriert sind, dass der Verkehr durch die Sicherheitskontrollen geleitet wird. Wenn Sie eine Aktualisierung der Routentabelle verpassen, wird der Datenverkehr an Ihrer Firewall vorbeigeleitet.

Mit vWAN fühlt sich die Sicherheitsintegration viel natürlicher an. Wenn Sie Azure Firewall in einem vWAN-Hub einsetzen, wird sie automatisch Teil der Routingstruktur. Der Datenverkehr fließt durch die Sicherheitskontrollen, nicht durch eine sorgfältige Konfiguration der Routentabelle. So konfiguriere ich normalerweise die Sicherheitsrichtlinien:

Routen-Tabelle: Produktions-Routen
├── Zugehörige VNets: Produktion-Ost, Produktion-West
├── Propagierte Routen: ExpressRoute, Produktionszweige
└─── Standard-Route: 0.0.0.0/0 → Azure Firewall

Routen-Tabelle: Development-Routes
├── Zugehörige VNets: Development-East, Development-West
├── Propagated Routes: Nur Entwicklungszweige
└── Internetzugang: Direkt (Kostenoptimierung)

Besonders schön ist, dass dies überregional funktioniert. Die in einem Hub angewendeten Sicherheitsrichtlinien werden automatisch auf die Kommunikation zwischen den Hubs ausgeweitet, so dass Sie eine konsistente Sicherheitslage erhalten, ohne die Konfiguration zu duplizieren.

Die Identitätsintegration, die tatsächlich funktioniert

An dieser Stelle wird es für Unternehmen mit Außendienstmitarbeitern interessant. Herkömmliche VPN-Einrichtungen sind oft mit Albträumen bei der Zertifikatsverwaltung oder separaten Authentifizierungssystemen verbunden, die niemand pflegen möchte. Die Integration von Virtual WAN mit Microsoft Entra ID hat dies völlig verändert.

Nachdem wir mit dieser Einrichtung über mehrere Client-Implementierungen hinweg gearbeitet haben, ist die Benutzererfahrung wirklich reibungslos. Die Benutzer authentifizieren sich mit ihren vorhandenen Unternehmensdaten, die Richtlinien für den bedingten Zugriff werden automatisch angewendet, und es muss keine separate VPN-Client-Konfiguration verwaltet werden. Die PowerShell-Einrichtung ist erfrischend einfach:

$vpnClientConfig = @

Aber was mich wirklich überzeugt hat, war zu sehen, wie die Endbenutzer es tatsächlich nutzen. Es gibt keine Probleme bei der Installation von Zertifikaten, keine separaten Passwörter, die man sich merken muss, und die IT-Abteilung muss nicht noch ein weiteres Identitätssystem verwalten.

Wenn die Zahlen nicht stimmen (und wenn sie stimmen)

Lassen Sie uns über die Kosten sprechen, denn das ist normalerweise der Punkt, an dem diese Gespräche unangenehm werden. Virtuelles WAN ist nicht billig – Sie müssen mit etwa 0,25 Dollar pro Stunde und Hub rechnen, zuzüglich der Kosten für die Datenverarbeitung. Für kleinere Umgebungen kann dies sogar mehr kosten als herkömmliche Hub-and-Spoke-Architekturen.

Nach der Analyse der Kosten für mehrere Implementierungen habe ich jedoch Folgendes gelernt: Der Break-even-Punkt ist schneller erreicht, als Sie vielleicht erwarten. Wir haben die Kosten für die VPN-Gateways in den Spoke-VNets eliminiert, die Gebühren für die regionsübergreifende Datenübertragung durch optimiertes Routing gesenkt und – was am wichtigsten ist – den betrieblichen Aufwand drastisch reduziert. Wenn Sie die eingesparte Zeit für manuelle Konfigurationen und Fehlerbehebung berücksichtigen, ergibt sich der Business Case oft von selbst.

Dennoch würde ich vWAN nicht für jedes Szenario empfehlen. Wenn Sie eine einfache Bereitstellung in einer Region mit weniger als 50 Spoke-VNets und engen Kostenvorgaben durchführen, ist das traditionelle Hub-and-Spoke-System wahrscheinlich immer noch sinnvoller. Die Komplexität und der Kostenaufwand von vWAN werden sich in einfacheren Umgebungen nicht auszahlen.

Die Migrationsrealität

Die Umstellung von einem traditionellen Hub-and-Spoke-System auf ein vWAN ist keine Sache, die man an einem Wochenende erledigt. Nachdem ich mehrere dieser Umstellungen durchgeführt habe, habe ich mich für einen schrittweisen Ansatz entschieden, der die Unterbrechungen minimiert und gleichzeitig angemessene Tests ermöglicht.

Die erste Phase umfasst eine umfassende Planung und Bewertung. Sie müssen Ihre bestehenden Konnektivitätsmuster inventarisieren, Ihre aktuellen Routing-Anforderungen verstehen und den tatsächlichen ROI auf der Grundlage betrieblicher Einsparungen berechnen. Dies ist nicht nur eine technologische Entscheidung, sondern auch eine betriebliche.

In Phase zwei geht es ans Eingemachte: die Pilotimplementierung. Ich empfehle immer, mit nicht produktiven Workloads in einer einzigen Region zu beginnen. So erhalten Sie praktische Erfahrungen mit dem Verhalten des vWAN und können Ihre Überwachungs- und Betriebsverfahren validieren, ohne die Produktionsdienste zu gefährden.

Die Produktionsmigration selbst erfordert eine sorgfältige Orchestrierung. Wir planen in der Regel kurze Wartungsfenster ein und halten immer Ausweichverfahren bereit. Die eigentliche Umstellung umfasst die Umleitung von Verbindungen von herkömmlichen Hubs zu vWAN-Hubs, die Aktualisierung von DNS-Konfigurationen und die Überprüfung der Konnektivität aller Arbeitslasten.

Was die Kunden immer wieder überrascht, ist, wie viel einfacher der laufende Betrieb nach der Migration wird. Aufgaben, die früher mehrere Konfigurationsänderungen auf verschiedenen Systemen erforderten, erfordern jetzt oft nur noch eine einzige Richtlinienaktualisierung in der vWAN-Verwaltungsoberfläche.

Überwachung und Leistung in der Praxis

Ein Bereich, in dem vWAN wirklich glänzt, ist die Beobachtbarkeit. Die Integration mit Azure Monitor bietet Einblicke in den Zustand der Verbindungen, Verkehrsmuster und Leistungsmetriken, die in herkömmlichen Architekturen eine umfangreiche individuelle Instrumentierung erfordern würden.

Nach der Arbeit mit diesen Überwachungsfunktionen in mehreren Implementierungen konzentriere ich mich auf einige Schlüsselkennzahlen: Die Hub-to-Hub-Latenz sollte normalerweise unter 50 ms innerhalb der Region und unter 150 ms für die regionsübergreifende Kommunikation liegen. Die Auslastung des Gateways ist von entscheidender Bedeutung – halten Sie sie für eine optimale Leistung unter 80%. Und die Verarbeitungskapazität der Firewall und die Trefferquote der Regeln helfen dabei, sowohl Sicherheitsprobleme als auch Leistungsengpässe zu erkennen.

Die Funktionen zur Analyse des Datenverkehrs haben sich als besonders wertvoll erwiesen, um das Routing zu optimieren und unerwartete Datenverkehrsmuster zu erkennen, die auf Sicherheitsprobleme oder falsch konfigurierte Anwendungen hinweisen könnten.

Die Grenzen, über die niemand spricht

Virtual WAN ist nicht perfekt, und es gibt Szenarien, in denen traditionelle Architekturen immer noch sinnvoller sind. Komplexe Routing-Anforderungen erfordern manchmal mehr Flexibilität als der verwaltete Ansatz von vWAN bietet. Einige fortschrittliche Netzwerkfunktionen, die in traditionellen Hub-and-Spoke-Architekturen funktionieren, werden in vWAN-Umgebungen nicht unterstützt.

Ausfallzeiten bei der Migration sind eine weitere Realität, die Sie berücksichtigen müssen. Während die meisten Umstellungen mit minimalen Unterbrechungen durchgeführt werden können, birgt die Umstellung kritischer Produktions-Workloads von einer Netzwerkarchitektur auf eine andere naturgemäß ein gewisses Risiko und erfordert in der Regel kurze Serviceunterbrechungen.

Wohin das alles führt

Nach anderthalb Jahren praktischer Erfahrung mit vWAN empfehle ich es immer häufiger für Unternehmenskunden. Allein die betriebliche Vereinfachung rechtfertigt in den meisten Szenarien die Kosten, und die Sicherheits- und Leistungsvorteile sind echt.

Wirklich interessant ist jedoch, wie vWAN die Diskussion über die Netzwerkarchitektur verändert. Anstatt Zeit mit der Verwaltung von Low-Level-Konfigurationen zu verbringen, können wir uns auf Design-Entscheidungen auf höherer Ebene über Sicherheitsrichtlinien, Verkehrsoptimierung und Geschäftsanforderungen konzentrieren. Diese Verschiebung des Schwerpunkts hat sich als wertvoller erwiesen, als ich ursprünglich erwartet hatte.

Die Technologielandschaft entwickelt sich ständig weiter, und die Netzwerkarchitekturen müssen sich mit ihr weiterentwickeln. Das virtuelle WAN ist ein wichtiger Schritt in Richtung eines besser verwaltbaren, skalierbaren Cloud-Netzwerks. Für Unternehmen, die bereit sind, Managed Services in Anspruch zu nehmen und betriebliche Effizienz über marginale Kosteneinsparungen zu stellen, ist dies eine ernsthafte Überlegung wert.

Der Schlüssel dazu ist eine ehrliche Bewertung Ihrer Anforderungen, eine realistische Planung der Komplexität der Migration und die Bereitschaft, neue Betriebsmuster zu erlernen. Wenn Sie diese Voraussetzungen erfüllen, kann vWAN Ihren Netzwerkbetrieb wirklich vereinfachen und gleichzeitig die Sicherheit und Leistung verbessern.