Azure

Azure Virtual Network (VNet)

Allgemeine Infos

Ein Azure Virtual Network (VNet) ist die Netzwerkgrundlage für fast alle Azure-Workloads. Es gehört zu genau einer Region und einer Subscription, hat einen oder mehrere private Adressräume (zum Beispiel 10.20.0.0/16) und wird in Subnetze aufgeteilt. Ressourcen im selben VNet kommunizieren standardmäßig miteinander, NSGs und benutzerdefinierte Routen (UDR) steuern den Verkehr.

VNets lassen sich per Peering untereinander und per VPN Gateway oder ExpressRoute mit lokalen Netzen verbinden. Private Endpoints und Service Endpoints binden PaaS-Dienste an.

Wichtige Änderung beim ausgehenden Internetzugriff: Mit der nach dem 31. März 2026 veröffentlichten API-Version sind Subnetze in neu erstellten VNets standardmäßig privat (defaultOutboundAccess = false), das Portal setzt das schon länger so. VMs dort brauchen eine explizite Ausgangsmethode. Bestehende VNets ändert Microsoft nicht.

Funktionsweise & Details

Aufbau und Verhalten eines VNets:

  1. Adressraum festlegen, überlappungsfrei zu lokalen Netzen und anderen VNets.
  2. Subnetze anlegen. Azure reserviert in jedem Subnetz fünf Adressen, manche Dienste wie VPN Gateway, Azure Firewall oder Bastion brauchen eigene, fest benannte Subnetze.
  3. Verkehr filtern mit NSGs an Subnetz oder Netzwerkkarte und lenken mit Routentabellen, etwa über eine zentrale Firewall.
  4. Namensauflösung über Azure DNS, private DNS-Zonen oder eigene DNS-Server.
  5. Ausgehender Internetzugang: In privaten Subnetzen über NAT Gateway (für die meisten Szenarien empfohlen), Standard Load Balancer mit Outbound-Regeln, Standard-Public-IP an der Netzwerkkarte oder Firewall/NVA mit UDR. Um vorhandene Standard-Ausgangs-IPs zu entfernen, muss das Subnetz privat gesetzt und die VMs neu zugeordnet (deallocated) werden.

Vorteile & Nutzen

  • Isolation und Segmentierung von Workloads nach Sicherheitszonen
  • Freie Wahl des privaten Adressraums, passend zum bestehenden IP-Konzept
  • Anbindung an lokale Standorte über VPN oder ExpressRoute
  • Kontrollierter Internetzugang durch explizite Ausgangsmethoden statt impliziter Standard-IPs

Praxisbeispiel

Ein Hersteller von Prüfständen baut seine erste produktive Azure-Umgebung. Das Netzwerkteam plant 10.50.0.0/16 für Azure, abgestimmt mit den Standortnetzen, und legt ein Hub-VNet mit VPN Gateway und Firewall sowie zwei Spoke-VNets für ERP und Testsysteme an. Alle Subnetze sind privat, ausgehender Verkehr läuft über die Firewall im Hub. Als ein Lieferant später eine Software-Aktivierung über das Internet braucht, wird gezielt eine Firewall-Regel freigegeben statt einer öffentlichen IP an der VM.

Worauf sollte man achten?

  • Adressräume überlappungsfrei und mit Reserve planen, nachträgliche Änderungen in gepeerten Netzen sind möglich, aber aufwendig
  • Ausgehenden Internetzugang bewusst festlegen, in neuen VNets ist er standardmäßig nicht mehr vorhanden
  • Subnetze nicht zu klein schneiden, einige Dienste verlangen Mindestgrößen und eigene Subnetze
  • NSGs, Routentabellen und DNS-Einstellungen als Code dokumentieren
  • Namenskonvention für VNets und Subnetze einführen, die Region und Zweck erkennen lässt

Lizenz & Verfügbarkeit

VNets und Subnetze sind kostenlos. Kosten entstehen für Peering-Datenverkehr, Gateways, öffentliche IP-Adressen, NAT Gateway, Firewall und ausgehenden Datenverkehr. Neue VNets mit der API-Version nach dem 31. März 2026 haben standardmäßig private Subnetze. Stand: Oktober 2026.

Fazit

Das VNet ist die Netzwerkbasis jeder Azure-Umgebung. Ein sauberer IP-Plan und eine bewusst gewählte Ausgangsmethode ersparen später teure Umbauten.

Weiterführende Links

Verwandte Artikel