Virtuelle Netzwerke und Subnetze

Ein Azure Virtual Network (VNet) ist ein logisch isoliertes Netzwerk in der Azure-Cloud, das Sie definieren und steuern. Es ist der grundlegende Baustein der Azure-Netzwerkfunktionen und ermöglicht es Azure-Ressourcen wie virtuellen Computern, Datenbanken und App Services, sicher miteinander, mit dem Internet und mit lokalen Netzwerken zu kommunizieren. Ein VNet ist auf eine einzelne Azure-Region und einen bestimmten IPv4-Adressraum (optional auch IPv6) im CIDR-Format beschränkt, den Sie bei der Erstellung festlegen.

Beim Erstellen eines VNets weisen Sie mithilfe der CIDR-Notation einen Adressraum zu. Die CIDR-Notation (Classless Inter-Domain Routing) gibt sowohl die Netzwerkadresse als auch die Anzahl der für das Netzwerkpräfix verwendeten Bits an. Beispielsweise stellt 10.0.0.0/16 65.536 IP-Adressen bereit (10.0.0.0 bis 10.0.255.255). Der Adressraum muss ein privater IP-Bereich sein (10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 gemäß RFC 1918). Wählen Sie einen ausreichend großen Adressraum, der alle geplanten Subnetze mit Wachstumsreserven aufnehmen kann. Vermeiden Sie jedoch Überschneidungen mit lokalen Netzwerken, wenn Sie eine hybride Verbindung planen.

Ein Subnetz unterteilt den VNet-Adressraum in kleinere Netzwerksegmente. Jedes Subnetz verfügt über einen eigenen IP-Bereich (eine Teilmenge des VNet-Adressraums) und kann Ressourcen verschiedener Typen enthalten. Subnetze dienen zwei Zwecken: der Organisation (Gruppierung zusammengehöriger Ressourcen) und der Isolierung (Anwendung unterschiedlicher Sicherheitsregeln auf verschiedene Ressourcengruppen). Beispielsweise können Sie ein web-tier-Subnetz (10.0.1.0/24) für Webserver, ein app-tier-Subnetz (10.0.2.0/24) für Anwendungsserver und ein data-tier-Subnetz (10.0.3.0/24) für Datenbanken einrichten.

Innerhalb jedes Subnetzes reserviert Azure die ersten vier IP-Adressen und die letzte IP-Adresse für eigene Zwecke. Bei einem Subnetz 10.0.1.0/24 sind dies: 10.0.1.0 (Netzwerkadresse), 10.0.1.1 (Standardgateway), 10.0.1.2 und 10.0.1.3 (für Azure DNS reserviert) sowie 10.0.1.255 (Broadcastadresse). Damit bleiben in einem /24-Subnetz 251 nutzbare IP-Adressen. Berücksichtigen Sie diese Reservierung bei der Dimensionierung von Subnetzen – ein /28-Subnetz hat nur 11 nutzbare Adressen (16 abzüglich 5 reservierter Adressen).

Standardmäßig können Ressourcen innerhalb desselben VNets über ihre privaten IP-Adressen miteinander kommunizieren, auch wenn sie sich in unterschiedlichen Subnetzen befinden. Für die Kommunikation innerhalb eines VNets ist keine zusätzliche Konfiguration erforderlich. Ressourcen in unterschiedlichen VNets können standardmäßig nicht miteinander kommunizieren – Sie müssen sie explizit mithilfe von VNet Peering verbinden. Ressourcen im selben Subnetz teilen sich dasselbe Netzwerksegment. Dadurch erfolgt die Kommunikation zwischen ihnen innerhalb der softwaredefinierten Netzwerkschicht von Azure auf dem direktesten möglichen Weg.

VMs in einem VNet können standardmäßig ausgehende Verbindungen mit dem Internet herstellen – Azure stellt den ausgehenden Internetzugriff automatisch über einen verwalteten NAT-Dienst bereit. Für den eingehenden Internetzugriff benötigt eine Ressource eine Public IP address, die ihrer Netzwerkschnittstelle oder ihrem Load Balancer zugewiesen ist. Anschließend steuern Sie den eingehenden Zugriff mithilfe von Regeln der Network Security Group (NSG), um genau festzulegen, welche Ports und Protokolle zulässig sind. Eine verbreitete Architektur platziert Webserver in einem öffentlichen Subnetz mit öffentlichen IP-Adressen und Anwendungsserver in einem privaten Subnetz, auf das nur von der Webschicht aus zugegriffen werden kann.

Standardmäßig übernimmt Azure das Routing automatisch: Datenverkehr zwischen Subnetzen bleibt innerhalb des VNets, ausgehender Internetdatenverkehr wird per NAT umgesetzt und Datenverkehr zu Azure-Diensten verwendet das Azure-Backbone. Sie können dieses Verhalten mithilfe von User-Defined Routes (UDRs) in einer Routingtabelle überschreiben. Ein häufiger Anwendungsfall besteht darin, den gesamten ausgehenden Internetdatenverkehr zur zentralen Überprüfung über eine Network Virtual Appliance (NVA) oder eine Azure Firewall in einem Hub-VNet zu leiten. Dazu erstellen Sie eine Routingtabelle, fügen Routeneinträge hinzu und verknüpfen die Tabelle mit einem oder mehreren Subnetzen.

Einige Azure-Dienste – etwa Azure App Service (VNet Integration), Azure Kubernetes Service, Azure SQL Managed Instance und Azure Databricks – benötigen ein dediziertes Subnetz, das an diesen Dienst delegiert ist. Ein delegiertes Subnetz bedeutet, dass Azure in Ihrem Auftrag dienstspezifische Ressourcen (Netzwerkschnittstellen, interne IP-Adressen) in dieses Subnetz einfügen kann. Sie können keine anderen Ressourcentypen in einem delegierten Subnetz bereitstellen – es ist ausschließlich für diesen Azure-Dienst reserviert. Planen Sie immer ein dediziertes Subnetz mit ausreichend IP-Adressraum ein, wenn Sie Dienste verwenden möchten, die eine Delegierung erfordern.

Wichtige bewährte Methoden für das VNet-Design: Planen Sie den Adressraum, bevor Sie das VNet erstellen – Sie können ihn nicht ändern, ohne Ressourcen neu zu erstellen. Verwenden Sie separate Subnetze für jede Anwendungsebene, um unterschiedliche Sicherheitsrichtlinien anzuwenden. Vermeiden Sie überlappende Adressräume mit lokalen Netzwerken, wenn Sie eine Verbindung über VPN oder ExpressRoute planen. Reservieren Sie größere Subnetze für Dienste, die eine Skalierung benötigen (z. B. AKS-Nodepools). Benennen Sie Ressourcen eindeutig (z. B. vnet-prod-eastus-001), um die Verwaltung in großem Maßstab zu erleichtern. Ein gut geplantes VNet lässt sich wesentlich einfacher absichern und bei Problemen beheben als eines, das ohne klare Planung erstellt wurde.

Azure-VNets können über zwei Mechanismen mit lokalen Netzwerken verbunden werden: VPN Gateway – ein verschlüsselter IPsec/IKE-Tunnel über das öffentliche Internet; kostengünstig für moderate Bandbreitenanforderungen. Azure ExpressRoute – eine private, dedizierte Glasfaserverbindung über einen Partner für Netzwerkverbindungen; bietet höhere Bandbreite, geringere Latenz und eine besser vorhersehbare Leistung als ein VPN. Für vertrauliche Workloads oder Szenarien mit garantierter Bandbreite ist ExpressRoute die bevorzugte Option, allerdings sind die Kosten deutlich höher und die Bereitstellungszeiten länger.

Für die Größenplanung des Adressraums eines VNets müssen aktuelle und zukünftige Anforderungen berücksichtigt werden. Ein verbreitetes Muster in Unternehmen ist: VNet-Adressraum: /16 (65.536 Adressen). Subnetze: /24 pro Workload-Ebene (jeweils 251 nutzbare Adressen). Ein VNet mit /16 kann 256 Subnetze mit /24 enthalten – mehr als genug für die meisten Umgebungen. Verwenden Sie für sehr große Umgebungen /8 oder fordern Sie mehrere nicht überlappende Bereiche an. Lassen Sie immer Raum für Wachstum: Wenn Sie heute ein /24 zuweisen, aber im nächsten Jahr möglicherweise ein /22 benötigen, führt dies später zu aufwendiger Neuadressierung.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion zu Microsoft Azure Fundamentals (AZ-900).

In dieser Lektion haben Sie gelernt: Ein Azure-VNet ist ein logisch isoliertes Netzwerk mit einem definierten CIDR-Adressraum, der auf eine einzelne Region beschränkt ist, Subnetze unterteilen das VNet in Segmente zur Organisation und Isolierung von Sicherheitsrichtlinien und Azure reserviert 5 IP-Adressen pro Subnetz, während Ressourcen innerhalb desselben VNets standardmäßig privat und ohne zusätzliche Konfiguration miteinander kommunizieren. Als Nächstes beschäftigen wir uns mit Network Security Groups und Application Security Groups zur Filterung des Datenverkehrs.