Azure Virtual Network: Das Fundament deiner Cloud-Architektur

Ein Azure Virtual Network (VNet) ist nicht einfach nur ein technisches Konstrukt, sondern bildet die Grundlage für jede sichere und skalierbare Cloud-Architektur. Dienste können zwar auch ohne VNet betrieben werden, jedoch fehlt dann die Kontrolle über IP-Räume, Zugriffe und die Kommunikation zwischen Ressourcen. Für produktives Arbeiten ist diese Kontrolle unerlässlich. VNets bieten die Möglichkeit zur Segmentierung, zum Zugriffsschutz und zur gezielten Kommunikation. Besonders im Hinblick auf Sicherheit spielt das eine zentrale Rolle: Erlangt ein Angreifer Zugriff auf einen Dienst, ist es entscheidend, die Ausbreitung einzudämmen. Eine durchdachte VNet-Struktur mit klarer Segmentierung verringert das Risiko einer lateralen Ausbreitung von Angriffen. Mehr Segmentierung sorgt somit für mehr Sicherheit und macht den zusätzlichen Aufwand lohnenswert.

Public oder Private – Netzwerkoptionen bei Azure Services

Viele Azure-Dienste bieten beim Einrichten verschiedene Netzwerkoptionen: öffentlich erreichbar, nur privat oder ein Mix aus beidem. Die Standardoption ist in der Regel die öffentliche Erreichbarkeit, was es ermöglich von überall auf den Dienst zuzugreifen. Was erstmal praktisch klingt, birgt jedoch Sicherheitsrisiken. Daher ist es ratsam, diese Option nur für Dienste zu wählen, die wirklich öffentlich zugänglich sein müssen.

Source: Microsoft Learn

Dienste wie Azure SQL, Storage Account oder Key Vault lassen sich über Private Endpoints abschotten. Dadurch sind sie nicht mehr über das öffentliche Internet erreichbar, sondern nur noch über interne IPs innerhalb eines VNets. Was erstmal einfach klingt, erfordert jedoch eine sorgfältige Planung deiner VNet-Struktur. Auch das Thema Kosten sollte nicht außer Acht gelassen werden: Private Endpoints verursachen zusätzliche Gebühren für die Zeit in der sie genutzt werden und auch für den Traffic, der über diesen läuft. Diese Kosten können sich schnell summieren, insbesondere wenn du viele Dienste mit Private Endpoints nutzt.

Wer es nicht direkt komplett privat braucht, aber trotzdem etwas sicherer, kann auch den Service öffentlich erreichbar lassen, aber den Zugriff über die Resource Firewall einschränken. Das bedeutet, dass der Dienst weiterhin über das öffentliche Internet erreichbar ist, aber nur von bestimmten IP-Adressen oder aus bestimmten Azure VNets heraus. Diese Option bietet eine gewisse Sicherheit, da sie den Zugriff auf vertrauenswürdige Quellen beschränkt, ist aber nicht so restriktiv wie Private Endpoints. Neben der Firewall bietet auch die Integration in ein Virtual Network mit Service Endpoints zusätzliche Sicherheit. Dabei wird der Datenverkehr zwischen Azure-Diensten und deinem VNet über das Azure-Backbone statt über das öffentliche Internet geleitet. Die Dienste bleiben zwar grundsätzlich öffentlich erreichbar, aber der Zugriff aus deinem VNet erfolgt geschützt und performant innerhalb des Azure-Netzwerks. So reduzierst du das Risiko, dass sensible Daten das öffentliche Internet durchqueren, und erhöhst die Kontrolle über den Datenfluss zwischen deinen Ressourcen.

Eine weitere Option ist Allow trusted Azure services, die bestimmten Microsoft-Diensten Zugriff gewährt, auch wenn die Ressource privat oder hinter einer Firewall ist. Diese Option ist praktisch, um beispielsweise Azure Monitor oder Azure Backup zu integrieren, ohne dass du zusätzliche Konfigurationen vornehmen musst. Allerdings solltest du diese Option mit Bedacht einsetzen, da sie potenziell Sicherheitsrisiken birgt, wenn du nicht genau weißt, welche Dienste Zugriff erhalten.

Kommunikation zwischen VNets – Hub-Spoke, Mesh und Peering

Für größere Umgebungen ist eine strukturierte Netzwerkarchitektur entscheidend. Zwei Modelle stehen zur Wahl: Hub-Spoke und Mesh. Beim Hub-Spoke-Modell gibt es ein zentrales Hub-VNet, das gemeinsame Dienste wie Gateways oder DNS bereitstellt. Alle anderen VNets – die Spokes – sind mit dem Hub verbunden, aber nicht direkt untereinander. Beim Mesh-Modell sind alle VNets direkt miteinander verbunden. Die Entscheidung hängt von Faktoren wie Skalierbarkeit, Resilienz, Performance und Kosten ab.

Unsere Empfehlung ist das Hub-Spoke-Modell. Es ist einfacher zu erweitern, unterstützt On-Premises-Verbindungen effizient (nur ein Gateway im Hub nötig) und verursacht geringere Peering-Kosten. Ein weiterer Vorteil des Hub-Spoke-Modells ist die klare Trennung von Verantwortlichkeiten: Teams oder Projekte können eigene Spokes nutzen, während zentrale Dienste und Sicherheitsmechanismen im Hub verwaltet werden. Zudem erleichtert die Struktur das Einhalten von Compliance-Vorgaben, da zentrale Überwachung und Protokollierung möglich sind. Auch Migrationen oder Änderungen an einzelnen Spokes lassen sich ohne Auswirkungen auf andere Bereiche durchführen.

Subnetzplanung: Struktur schaffen, Konflikte vermeiden

Subnetze sind essenziell für die logische Trennung innerhalb eines VNets. Sie helfen, Rollen zu trennen, den Zugriff zu steuern und die Sicherheit zu erhöhen. Unsere Empfehlung ist eine einfache Struktur: Für jede Umgebung ein Public und ein Private Subnet. Öffentliche Ressourcen wie Gateways oder Load Balancer werden im Public Subnet platziert, während sensible Dienste wie Datenbanken ins Private Subnet gehören. Eine feinere Aufteilung nach Ressourcentypen, zum Beispiel in App, DB oder Storage, ist ebenfalls möglich, führt aber oft zu unnötiger Komplexität.

Ein kritischer Punkt ist die IP-Adressplanung. Azure reserviert fünf IPs pro Subnetz, und Adresskonflikte über Regionen oder Environments hinweg können später teuer werden. Unsere Empfehlung ist, einen ausreichend großen Adressbereich wie 10.0.0.0/8 zu wählen und diesen in Regionen und Umgebungen zu unterteilen. Zum Beispiel kann 10.1.0.0/16 für DEV in Europa reserviert werden, während 10.7.0.0/16 für PRD genutzt wird. Öffentliche Subnetze beginnen jeweils bei 10.X.0.0, private Subnetze bei 10.X.224.0. Dadurch lassen sie sich bei Bedarf sauber erweitern.

Beispielhafte IP-Adressaufteilung

1. Übersicht: Regionale, Offene und Globale Bereiche

2. Regionale Netzwerke: EU, US, ASIA

3. Beispiel: EU-Adressaufteilung

Subnetz-Erweiterungsempfehlung

• Public Subnets: 10.X.0.0 – 10.X.32.255 (erweiterbar bis 10.X.127.255)
• Private Subnets: 10.X.224.0 – 10.X.255.255 (erweiterbar bis 10.X.128.0)

Diese Struktur sorgt für klare Trennung, einfache Erweiterbarkeit und minimiert Adresskonflikte.

Weitere Best Practices gibt es in der Azure Dokumentation.

Infrastructure as Code: VNets mit Bicep oder Terraform

Die Verwaltung von VNets und Subnetzen sollte idealerweise über Infrastructure as Code (IaC) erfolgen. Dadurch wird die Konfiguration versioniert, automatisiert und ist reproduzierbar. Sowohl Bicep als auch Terraform sind dafür geeignete Werkzeuge. Einmal das Hub-Spoke-Modell definiert, lassen sich neue Services oder Umgebungen schnell hinzufügen und verbinden. Bevor du dir aber alles selbst zusammenbaust, schau dir die Azure Verified Modules an. Hier gibt es sowohl für Bicep als auch für Terraform vorgefertigte Module für Hub-Spoke, die dir viel Arbeit abnehmen. Diese Module sind von Microsoft geprüft und bieten eine solide Grundlage für deine VNet-Architektur.

Sicherheit mit Network Security Groups und Azure Firewall

Network Security Groups (NSGs) bilden die erste Verteidigungslinie im Azure-Netzwerk. Sie ermöglichen es, Regeln für eingehenden und ausgehenden Traffic auf Subnetzebene oder direkt auf Netzwerkinterfaces festzulegen. Dadurch kannst du Zugriffe gezielt steuern und beispielsweise nur bestimmte Ports oder IPs erlauben. NSGs sind flexibel und lassen sich anpassen, um den Zugriff auf Ressourcen zu beschränken. Sie sollten jedoch mit Bedacht eingesetzt werden, da zu viele Regeln die Performance beeinträchtigen können. Eine gute Praxis ist es, NSGs so restriktiv wie möglich zu konfigurieren und nur explizit erlaubte Zugriffe zuzulassen.

Azure Firewall bietet eine umfassendere Sicherheitslösung für Azure-Netzwerke. Sie ermöglicht es, den Datenverkehr zwischen VNets, Subnetzen und dem Internet zu überwachen und zu steuern. Mit Funktionen wie URL-Filterung, Anwendungssicherheit und Protokollierung bietet sie einen erweiterten Schutz vor Bedrohungen. Azure Firewall ist besonders nützlich in Szenarien, in denen komplexe Sicherheitsanforderungen bestehen oder mehrere VNets miteinander kommunizieren müssen.

Zugriff für Entwickler: Jumpserver, Bastion oder VPN Gateway

Nicht alle Ressourcen sind direkt erreichbar, was aus Sicherheitsgründen sinnvoll ist. Entwickler und Admins benötigen dennoch Zugriff, beispielsweise für Debugging oder Wartung. Dafür stehen verschiedene Möglichkeiten zur Verfügung. Ein klassischer Jumpserver ist eine VM mit RDP oder SSH, die als Zugangspunkt genutzt wird. Dieser kann in einem Public Subnet platziert werden, um den Zugriff zu ermöglichen. Allerdings birgt diese Methode Sicherheitsrisiken, da der Jumpserver selbst ein potenzielles Ziel für Angriffe ist und regelmäßig gewartet werden muss. Der Zugriff auf den Jumpserver kann über Azure Bastion erfolgen. Bastion stellt eine moderne Alternative dar und ermöglicht den Zugriff direkt über das Azure-Portal, ganz ohne öffentliche IPs.

Für größere Teams oder hybride Szenarien bietet sich ein VPN Gateway an, das eine sichere Verbindung vom lokalen Netzwerk ins Azure-VNet herstellt. Dies ermöglicht es Entwicklern, auf Ressourcen zuzugreifen, als wären sie im gleichen Netzwerk, ohne dass diese öffentlich erreichbar sein müssen. VPN Gateways bieten eine hohe Sicherheit und Flexibilität, erfordern jedoch eine sorgfältige Konfiguration und Wartung.

Wer keine Private Endpoints nutzt, kann natürlich auch die IP-Adressen der Entwickler in den NSGs der Ressourcen eintragen, um den Zugriff zu ermöglichen. Diese Methode ist einfach und schnell, birgt jedoch das Risiko, dass IP-Adressen sich ändern können oder im Zweifel nicht mehr gelöscht werden. Soll ein Entwickler nicht mehr auf eine Ressource zugreifen können, muss manuell die NSG-Regel angepasst werden. Daher ist es ratsam, stattdessen auf Bastion oder VPN Gateways zu setzen, um den Zugriff zentral zu steuern und zu protokollieren.

Kostenfaktor Netzwerk: Was beim Traffic zwischen VNets zählt

Innerhalb eines VNets fallen keine Kosten für den Datenverkehr an. Sobald jedoch VNet Peering verwendet wird, entstehen Kosten, die sich nach Richtung, Volumen und Region richten. In unserem Beispiel gehen wir von vier Peering-Verbindungen aus. Bei einem mittleren Datenvolumen von 1 TB pro Monat betragen die Kosten etwa 10 €, bei einem höheren Volumen von 5 TB pro Monat etwa 50 €. Die Kostenthematik hier ist sehr flexibel, wird aber in folgendem Microsoft Artikel genauer beleuchtet. Auch Private Endpoints verursachen zusätzliche Ausgaben, zum Beispiel rund 7 € pro Monat zuzüglich der anfallenden Traffic-Kosten. Da Private Endpoints nicht gemeinsam genutzt werden können, kann dies bei vielen Ressourcen schnell teuer werden. Als kostengünstige Alternative bieten sich Service Endpoints in Verbindung mit Firewalls auf Ressourcenseite an, da diese Lösung in den meisten Fällen kostenlos ist und dennoch einen guten Schutz bietet.

Die Kosten für Jumpserver und VPN Gateway unterscheiden sich deutlich. Jumpserver verursachen laufende Gebühren für VM, Bastiom, Storage und Wartung. VPN Gateways kosten abhängig von SKU, Nutzerzahl und Datenvolumen, insbesondere bei vielen Verbindungen.

Fazit

Ein gut geplantes Azure Virtual Network bildet die Basis für eine sichere und flexible Cloud-Architektur. Wer von Anfang an auf klare Segmentierung, durchdachte Subnetzplanung und geeignete Sicherheitsmechanismen wie NSGs und Private Endpoints achtet, legt den Grundstein für nachhaltiges Wachstum und eine einfache Verwaltung. Die zahlreichen Netzwerkoptionen in Azure bieten die Möglichkeit, individuelle Anforderungen optimal umzusetzen, sofern sie gezielt und unter Berücksichtigung von Kosten, Sicherheit und Skalierbarkeit eingesetzt werden. Eine sorgfältige Planung zahlt sich im späteren Betrieb mehrfach aus. Beim Thema Networking gilt oft: Wer zu spät plant, zahlt doppelt. Daher ist es ratsam, sich frühzeitig mit den Möglichkeiten und Best Practices auseinanderzusetzen, um spätere Probleme und Kosten zu vermeiden.

Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.