Netzwerkarchitektur in eurem Enterprise-Scale-Framework
In diesem Blogbeitrag beschreibe ich die Netzwerkentscheidungen, die ihr treffen müsst, wenn ihr die Azure Cloud für eure Workloads einsetzen wollt.

Das Enterprise Scale Framework
Das Enterprise Scale Framework ist ein strategischer Ansatz, der Organisationen dabei unterstützt, ihre Cloud-Umgebungen effektiv einzuführen und zu skalieren, insbesondere in Microsoft Azure.
Warum die Umsetzung wichtig ist
Skalierbarkeit: Das Framework stellt sicher, dass eure Cloud-Umgebung mit euren geschäftlichen Anforderungen mitwachsen kann und steigende Workloads und Nutzerzahlen ohne Leistungseinbußen bewältigt.
Governance: Es bietet einen strukturierten Ansatz für die Verwaltung von Ressourcen und stellt die Einhaltung von Unternehmensrichtlinien und regulatorischen Anforderungen sicher.
Sicherheit: Durch die Befolgung von Best Practices schützt das Framework eure Daten und Anwendungen vor Bedrohungen und stellt sicher, dass robuste Sicherheitsmaßnahmen vorhanden sind.
Operative Effizienz: Es vereinfacht den Betrieb, indem es Prozesse automatisiert und klare Richtlinien vorgibt, wodurch die Komplexität bei der Verwaltung von Cloud-Ressourcen sinkt.
Kostenmanagement: Hilft dabei, Kosten zu optimieren, indem es Einblicke und Kontrollmöglichkeiten für die Ressourcennutzung bietet und so Überausgaben verhindert.
Die Kernbereiche des Enterprise Scale Framework
Die Kernbereiche des Enterprise Scale Framework sind:
- Landing Zones
- Identity and Access Management
- Networking
- Security
- Management and Monitoring
- Governance
- Cost Management
- Automation and DevOps
Heute konzentrieren wir uns auf den Bereich „Network“ im Enterprise Scale Framework. Wenn man sich das Framework ansieht, sieht es folgendermaßen aus:

Die wichtigsten Themen für das Netzwerkdesign
Es ist wichtig, dass ihr eure Anforderungen und auch die Netzwerkarchitektur in Azure gut versteht. Beachtet, dass Änderungen an der Architektur zu einem Ausfall eurer Umgebung führen können.
Definiert eure Netzwerktopologie
Zuerst müsst ihr die richtige Basistopologie festlegen. Je nach Anforderungen stehen zwei Optionen zur Verfügung.
Azure Virtual WAN-based Network Topology

Traditional Azure Networking Topology

Zur richtigen Entscheidung gibt es viele Fragen. Ich möchte sie auf zwei Fragen herunterbrechen.
- Gibt es einen Bedarf an Branch-to-Branch-Konnektivität?
- Gibt es einen Bedarf an granularer Kontrolle der Konnektivität?
IP-Adressierung planen
Basierend auf der Topologie müsst ihr einen IP-Adressraum in Azure festlegen. Ich empfehle dringend, in Azure einen IP-Adressraum zu verwenden, der sich nicht mit dem On-Premises-Adressraum überschneidet, weil das alles einfacher macht.

DNS konfigurieren
Niemand möchte sich mit einer IP-Adresse verbinden. Wir nutzen alle DNS-Auflösung für unsere Anwendungen und die Konnektivität. In Azure ist das nicht anders. Was wir entscheiden müssen, ist die richtige Architektur.
Ihr könnt IaaS mit einem DNS-Forwarder verwenden.

Alternativ könnt ihr den PaaS-Dienst „Azure DNS Private Resolver“ nutzen, um eure Anforderungen zu erfüllen.

Konnektivität zu Azure und zu Azure PaaS-Diensten
Bei der Konnektivität müsst ihr euch zwischen zwei verfügbaren Optionen entscheiden.
- Azure Express Route / Azure Express Route Direct Connect
- Site-to-Site VPN tunnel
Bei der Entscheidung zwischen Azure ExpressRoute und Azure Site-to-Site (S2S) VPN ist es wichtig, verschiedene Faktoren zu berücksichtigen, um herauszufinden, welche Lösung am besten zu euren Anforderungen passt.
Vorteile von ExpressRoute
- Leistungsanforderungen
- Braucht ihr für eure Anwendungen hohe Bandbreite und niedrige Latenz?
- Wünscht ihr euch eine zuverlässigere und konsistentere Verbindung im Vergleich zum öffentlichen Internet?
- Sicherheitsanforderungen
- Ist eine private Verbindung, die nicht über das öffentliche Internet läuft, für die Sicherheit eurer Daten entscheidend?
- Kostenaspekte
- Seid ihr auf die potenziell höheren Kosten von ExpressRoute im Vergleich zu VPN-Lösungen vorbereitet?
- Datenübertragungsvolumen
- Werdet ihr große Datenmengen zwischen eurer On-Premises-Infrastruktur und Azure übertragen?
- Dienstverfügbarkeit
- Ist ExpressRoute in eurer Region verfügbar und unterstützt es den von euch benötigten Connectivity Provider?
- Redundanz und SLA
- Braucht ihr integrierte Redundanz und ein höheres SLA für Verfügbarkeit und Leistung?
Vorteile von Site-to-Site (S2S) VPN
- Budgetbeschränkungen
- Sucht ihr eine kostengünstigere Lösung im Vergleich zu ExpressRoute?
- Nutzungsmuster
- Ist euer Datenübertragungsvolumen moderat und sind eure Leistungsanforderungen weniger streng?
- Sicherheitsanforderungen
- Seid ihr mit der Sicherheit eines VPN über das öffentliche Internet zufrieden?
- Flexibilität und Skalierbarkeit
- Braucht ihr eine Lösung, die sich schnell einrichten und bei Bedarf skalieren lässt?
- Kompatibilität
- Habt ihr kompatible VPN-Geräte und das nötige technische Know-how, um das VPN zu konfigurieren und zu betreiben?
- Redundanz und Verfügbarkeit
- Seid ihr mit den Redundanz- und Verfügbarkeitsoptionen des Azure VPN Gateway einverstanden?
Für PaaS-Lösungen innerhalb von Azure gibt es weitere Optionen, um sie dem internen Netzwerk zuzuordnen.
Ein Azure Service Endpoint ermöglicht es euch, die Identität eures virtuellen Netzwerks (VNet) über eine direkte, sichere Verbindung auf Azure-Dienste auszudehnen. Das bedeutet, dass Ressourcen in eurem VNet mit Azure-Diensten kommunizieren können, ohne das öffentliche Internet zu durchlaufen.

Ein Azure Private Endpoint ist eine Netzwerkschnittstelle, die euch privat und sicher mit einem Dienst verbindet, der auf Azure Private Link basiert. Dadurch bleibt der Datenverkehr zwischen eurem virtuellen Netzwerk (VNet) und dem Azure-Dienst innerhalb eures privaten Netzwerks, ohne das öffentliche Internet zu durchlaufen.

Eingehende und ausgehende Internetkonnektivität sowie Segmentierung planen
Microsoft Azure hat kürzlich angekündigt, dass die Unterstützung für den standardmäßigen Internetzugang für neue virtuelle Maschinen (VMs) nach dem 30. September 2025 endet. Dieser und viele weitere Gründe erfordern eine gute Architektur für die ausgehende Konnektivität. In meinem Blogbeitrag möchte ich den „Cloud-nativen“ Weg beschreiben.
Ihr könnt die Azure Firewall nutzen, um die Anforderungen an die ausgehende Konnektivität zu erfüllen.
Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der eure Azure Virtual Network-Ressourcen schützt. Er bietet eine zentrale Möglichkeit, Netzwerksicherheitsrichtlinien über mehrere Subscriptions und virtuelle Netzwerke hinweg zu verwalten und durchzusetzen.
Es gibt verschiedene Angebote, zwischen denen ihr je nach Anforderungen wählen könnt.
- Basic: Ideal für kleine und mittlere Unternehmen mit moderaten Sicherheitsanforderungen und geringerem Durchsatzbedarf.
- Standard: Geeignet für die meisten Enterprise-Szenarien und bietet ein ausgewogenes Verhältnis von Leistung und Sicherheitsfunktionen.
- Premium: Am besten für Umgebungen mit hohen Sicherheitsanforderungen, die erweiterten Bedrohungsschutz und höhere Leistung benötigen.
Traffic Inspection planen
Wenn ihr Anwendungen in euren Landing Zones habt, die über das Internet erreichbar sind, empfehle ich dringend, eine Layer-7-Web Application Firewall zum Schutz eurer Anwendung einzusetzen. In Kombination mit der internen Segmentierungs-Firewall (Azure Firewall) erreichen wir eine zweischichtige Sicherheit für eure Umgebung.
Azure bietet mehrere Layer-7-Web-Application-Firewall-(WAF-)Lösungen, die eure Webanwendungen vor gängigen Bedrohungen und Schwachstellen schützen. Hier ist eine Liste cloud-nativer Lösungen.
- Azure Application Gateway WAF
- Funktionalität: Arbeitet auf Layer 7 und bietet zentralen Schutz für eure Webanwendungen.
- Funktionen: Enthält integrierte Regeln zum Schutz vor den OWASP Top 10-Schwachstellen, benutzerdefinierte Regeln und Bot-Schutz.
- Anwendungsfälle: Ideal für Szenarien, in denen ihr Webverkehr verwalten und in Azure gehostete Anwendungen schützen müsst.
- Azure Front Door WAF
- Funktionalität: Arbeitet ebenfalls auf Layer 7 und ist in Azure Front Door integriert, um globales Load Balancing und Anwendungsbeschleunigung bereitzustellen.
- Funktionen: Bietet ähnlichen Schutz wie die Application Gateway WAF, mit zusätzlichen Möglichkeiten für globales Routing und Leistungsoptimierung.
- Anwendungsfälle: Geeignet für Anwendungen, die globale Reichweite und hohe Verfügbarkeit benötigen.
- Azure CDN WAF
- Funktionalität: Bietet Layer-7-Schutz für Inhalte, die über das Azure Content Delivery Network (CDN) ausgeliefert werden.
- Funktionen: Schützt vor gängigen Web-Exploits und Schwachstellen und sorgt für eine sichere Auslieferung von Inhalten.
Anwendungsfälle: Am besten für Szenarien, in denen ihr statische, global verteilte Inhalte absichern müsst.
Wie ihr seht, ist die Entscheidung über die Netzwerkarchitektur ein großes Projekt und erfordert viele Dienst- und Architekturentwürfe. Ich empfehle, eure Anforderungen zu durchdenken, eine gute, cloud-native Architektur zu definieren und sie in eure Umgebung zu bringen. Überprüft eure Entscheidungen außerdem regelmäßig.
Zum Schluss
Ich möchte mich bedanken bei

für die Organisation des Community-Events, und bei den Sponsoren
