„Hey Chris, wie oft hast du Kunden, bei denen alle Azure-Ressourcen in einer Subscription und einem einzigen VNet laufen?“
So startet die neue Folge von Die Cloud Optimizer.
Die Antwort: leider immer noch zu oft.
Genau deshalb steigen wir heute tiefer ein, in reale Netzwerkarchitekturen, die in Azure funktionieren und auch skalieren.
Rückblick: Die Grundlagen
In der letzten Folge unserer Cloud Foundation Reihe haben wir die Basics gelegt: VNets, Subnets, NSGs, Peering.
Wer das nicht gehört hat, am besten dort einsteigen.
Heute geht es um die nächste Ebene: Architekturentscheidungen, die sich im Alltag bewähren, oder eben nicht.
Der einfache Einstieg: Zwei Workloads, zwei Subscriptions
Ein Beispiel, wie es besser geht: Zwei Workloads, zwei Subscriptions, zwei getrennte VNets.
Keine Verbindung, keine Komplexität.
Kein Peering nötig
NSGs regeln den Zugriff
Kosten sind sauber getrennt
Zugriff und Rechte lassen sich sauber über Rollen und Management Groups steuern
Das Prinzip dahinter: Workloads, die nichts miteinander zu tun haben, brauchen auch keine Verbindung.
Segmentierung von Anfang an ist einfacher als späteres Nachrüsten.
Architekturansatz Hub-and-Spoke
Ein bewährtes Muster aus dem Enterprise-Kontext:
Der zentrale Hub enthält zentrale Infrastrukturkomponenten wie Firewall, VPN Gateway oder ExpressRoute
Die Spokes beinhalten jeweils dedizierte Workloads (z. B. Entwicklung, Produktion, Analytics)
Vorteile
Zentrale Steuerung von Routing, Logging und Security
Klare Trennung zwischen Umgebungen
Skalierbar in mittleren und größeren Umgebungen
Typische Fehlerquellen
DNS-Forwarding wird häufig vergessen
Routen müssen explizit gepflegt werden
Multi-Region wird schnell unübersichtlich
Architekturansatz Azure Virtual WAN
Virtual WAN ist ein gemanagter Netzwerkdienst von Microsoft, der Verbindungen über das globale Backbone vereinfacht:
Automatisiertes Peering über Hubs
Integration von VPN, ExpressRoute und Branch Offices
Einfache Verwaltung über zentrale Oberfläche
Wann sinnvoll
Verteilte Standorte oder Multi-Region-Architekturen
Höhere Anforderungen an Hybrid- oder Global Connectivity
Kunden mit mehreren Rechenzentren und wachsendem Netzwerkbedarf
Achtung
Nicht jeder Workload braucht Virtual WAN
Preisstruktur (Basic vs. Standard) verstehen und einplanen
Kombinierte Architekturen und Praxisbeispiele
In der Praxis wird selten ein Muster allein verwendet. Hier ein paar gängige Kombinationen:
Hub-and-Spoke + Private Endpoints: Beliebt bei Kunden, die PaaS-Dienste wie SQL oder Key Vault sicher einbinden möchten
Virtual WAN + Private Link + ExpressRoute: Typisch bei Konzernen mit globalem Footprint
Startups vs. Konzerne: Unterschiedliche Anforderungen – oft wird zu früh „overengineered“
Best Practices
Mehrere Subscriptions und VNets sind kein Overhead – sondern klare Trennung
Netzwerke sollten nach Anwendung getrennt sein, nicht nach Technik
Rollenzuweisungen und Governance sollten immer mitgedacht werden
Infrastruktur gehört automatisiert: Terraform, Bicep oder ARM machen den Unterschied
Fazit
Wer mehr als einen Workload betreibt, sollte frühzeitig trennen. Die technische Umsetzung ist nicht das Problem – es fehlt oft nur der Plan.
Hub-and-Spoke ist ein solider Standard
Virtual WAN ist ideal für komplexere und globale Szenarien
Private Link schützt, wo Sicherheit höchste Priorität hat
Und das Wichtigste: Netzwerkarchitektur ist kein Selbstzweck. Sie schafft die Grundlage dafür, dass Azure-Umgebungen langfristig stabil, sicher und wartbar bleiben.
Deine Meinung?
Wie habt ihr euer Netzwerk in Azure aufgebaut?
Welche Erfahrungen hast du mit Hub-and-Spoke oder Virtual WAN gemacht?
Wir freuen uns auf den Austausch!
Noch Fragen?
👉 Schreib uns auf LinkedIn oder kommentiere direkt unter der Podcast-Folge.
Danke fürs zuhören
Chris und Matthias
PS: Folge uns auf LinkedIn und tausche dich mit uns aus
Christian: LinkedIn-Profil
Matthias: LinkedIn-Profil
Share this post