„Hey Matthias, wusstest du, dass das Thema Netzwerk in Azure essentiell ist? Und außerdem funktioniert das alles ein bisschen anders…“
Mit diesem Satz steigen Chris und Matthias in die sechste Episode der Cloud Foundation-Reihe ein und stellen damit eines der grundlegendsten, aber auch am meisten unterschätzten Themen im Cloud-Kontext vor: Netzwerkarchitektur in Azure.
Was sich zunächst nach Subnetzen und IP-Adressen anhört, entpuppt sich schnell als tragende Säule jeder Cloud-Infrastruktur.
Ohne sauberes Netzwerkdesign funktioniert keine Applikation, keine Verbindung nach On-Premises, keine Sicherheit.
Gleichzeitig unterscheidet sich Azure Networking an vielen Stellen grundlegend vom klassischen On-Prem-Setup - logisch, nicht physisch gedacht.
In dieser ersten von zwei (oder drei) Netzwerkfolgen geht es um die Basics: Welche Bausteine bietet Azure?
Wo ticken Dinge anders als gewohnt?
Und wie nähert man sich dem Thema sinnvoll an, ohne gleich in der Komplexität zu versinken?
Warum Netzwerk in Azure nicht „wie früher“ funktioniert
Wer aus der On-Prem-Welt kommt, denkt beim Begriff „Netzwerk“ oft an VLANs, Firewalls, IP-Ranges und Routing-Tabellen – alles klar getrennt durch physische Infrastruktur. In Azure dagegen ist das Netzwerk softwaredefiniert.
Ein Azure Virtual Network (VNet) ist kein Stück Hardware, sondern ein logischer Container.
Subnetze existieren nicht auf dedizierten Switches, sondern in einer riesigen SDN-Fabric. Das bedeutet: Pakete bewegen sich innerhalb eines VNets automatisch und kostenlos von Subnetz zu Subnetz - ohne dass man explizit Routen bauen muss.
Das klingt simpel, erfordert aber ein grundsätzlich anderes Denken beim Design.
Auch beim Thema Sicherheit gilt: Firewalls sind nicht mehr zentral am Netzwerkrand, sondern verteilen sich granular über Komponenten wie Network Security Groups (NSGs), Azure Firewall oder Application Gateways.
Der Begriff „Perimeter“ wird in Azure damit fließend, was zugleich neue Freiheitsgrade und neue Verantwortung bedeutet.
Die wichtigsten Bausteine im Überblick
In der Folge gehen Chris und Matthias auf zentrale Komponenten ein, die jede Azure-Netzwerkarchitektur prägen.
Unabhängig davon, ob es sich um ein kleines Projekt oder eine konzernweite Landing-Zone handelt.
Virtual Network (VNet)
Das Herzstück jeder Netzwerkarchitektur. Jedes VNet erhält einen eigenen Adressraum (z. B. 10.0.0.0/16) und kann über Subnetze logisch strukturiert werden. Innerhalb eines VNets werden alle Ressourcen automatisch geroutet. Wenn mehrere VNets miteinander kommunizieren sollen, etwa im Hub-and-Spoke-Design, erfolgt das über Peering.
Subnetze & Network Security Groups (NSGs)
Subnetze dienen der logischen Trennung von Workloads. Jede Subnetzgrenze ist auch eine Sicherheitsgrenze und darum sollte man hier NSGs verwenden. Diese kontrollieren den Datenverkehr auf Subnetz- oder sogar NIC-Ebene. Besonders hilfreich: Die Standardregeln erlauben beispielsweise grundsätzlich internen Traffic innerhalb des VNets, lassen sich aber leicht granular überschreiben.
Azure Firewall
Für viele Organisationen ist die Azure Firewall das Mittel der Wahl, wenn es um zentrale Sicherheitsregeln, Protokollierung und DNS-Filterung geht. Ein großer Vorteil: Sie lässt sich vollständig über IaC (z. B. mit Terraform) ausrollen, inklusive aller Regeln und Policies.
VPN Gateway & ExpressRoute
Die Verbindung zu bestehenden Standorten kann entweder über ein klassisches VPN Gateway (IPSec/IKEv2) oder über eine dedizierte Leitung via ExpressRoute erfolgen. Während VPNs schnell und flexibel eingerichtet sind, bietet ExpressRoute in produktiven Szenarien deutlich höhere Durchsätze und SLA-Zusagen, allerdings mit etwas mehr Planungsaufwand.
Load Balancer vs. Application Gateway
Azure bietet zwei unterschiedliche Load Balancing Services:
Der Azure Load Balancer arbeitet auf Layer 4 und verteilt TCP/UDP-Verbindungen, ideal für Infrastruktur-Komponenten oder VMs.
Das Application Gateway hingegen arbeitet auf Layer 7 und eignet sich für Webanwendungen. Inklusive URL-basiertem Routing und integriertem Web Application Firewall (WAF).
Best Practices: Erste Leitplanken für gute Netzwerkarchitektur
Zum Ende der Folge liefern Chris und Matthias erste Best Practices, die wir hier um technische Tipps ergänzen möchten:
1. Plane pro Workload ein eigenes VNet – oder mindestens pro Domäne.
Das erleichtert spätere Peering-Konzepte und minimiert den Blast Radius bei Problemen.
2. Adressplanung zuerst, alles andere später.
CIDR-Bereiche lassen sich später nur sehr schwer korrigieren. Eine Staffelung wie /16 → /24 bietet genug Raum.
3. NSG-Regeln mit Application Security Groups kombinieren.
Das vermeidet starre IP-Regeln und vereinfacht Änderungen, wenn sich die Infrastruktur ändert.
4. Automatisiere von Anfang an.
Netzwerkdefinitionen gehören in Bicep oder Terraform. Auch Firewalls und DNS können vollständig in IaC gegossen werden.
Ausblick auf Teil 2
In der kommenden Episode steigen wir tiefer ein, in Richtung Private Endpoints & Service Endpoints oder Hub-and-Spoke-Design.
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
Unsere komplette Reihe „Cloud Foundation“ zum Nachhören:
Share this post