IPv4-Subnetting in Azure VNets: Beispiele und Stolperfallen

IPv4-Subnetting in Azure VNets ist ein Thema, das in der Praxis schneller relevant wird, als viele erwarten: Spätestens wenn mehrere Workloads, unterschiedliche Sicherheitszonen, Hybrid-Anbindungen (VPN/ExpressRoute) oder VNet-Peering ins Spiel kommen, entscheidet die Subnetzplanung darüber, ob ein Azure-Netzwerk stabil skaliert oder ständig umgebaut werden muss. In Azure ist ein Virtual Network (VNet) der logische Container für einen oder mehrere IPv4-Adressräume (CIDR-Blöcke). Daraus schneidest du Subnetze, in denen VMs, PaaS-Integrationen und Netzwerkdienste betrieben werden. Das klingt vertraut – hat aber Azure-spezifische Stolperfallen: Azure reserviert in jedem Subnetz mehrere IP-Adressen, kleine Subnetze sind dadurch schnell „voll“, und bestimmte Plattformdienste verlangen dedizierte Subnetze mit Mindestgrößen. Zusätzlich wird IPv4-Subnetting in Azure kritisch, sobald du VNets miteinander verbindest: Überlappende Adressräume verhindern Peering oder machen Hybrid-Routing extrem komplex. Wer dagegen von Anfang an sauber segmentiert, ausreichend Reserve einplant und typische Azure-Subnetze (GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet) korrekt dimensioniert, spart sich später teure Migrationsprojekte. Dieser Artikel erklärt die Grundlagen verständlich, zeigt konkrete IPv4-Subnetting-Beispiele und weist auf die häufigsten Fehler hin – inklusive praxistauglicher Gegenmaßnahmen.

Grundlagen: VNet, Address Space und Subnetze in Azure

Ein Azure VNet besteht aus einem oder mehreren Address Spaces (IPv4-CIDR-Blöcken). Innerhalb dieser Address Spaces definierst du Subnetze, die sich nicht überlappen dürfen. Subnetze sind in Azure nicht nur „Adressbereiche“, sondern auch ein zentraler Baustein für Routing und Sicherheitskontrollen:

• Private IPs für Ressourcen werden aus dem Subnetz vergeben (VMs, NICs, interne Load Balancer und viele PaaS-Integrationen).
• Route Tables (UDRs) können pro Subnetz zugewiesen werden, um Traffic gezielt über Firewalls, NVA oder Gateways zu steuern.
• Network Security Groups (NSGs) werden häufig subnetzweise angewandt, um eine Zone (z. B. „App“) konsistent abzusichern.

Für den Überblick über Konzepte und Best Practices ist die Microsoft-Dokumentation zu Azure Virtual Network Concepts and Best Practices eine solide Grundlage.

Die Azure-Regel, die jeder kennen muss: 5 reservierte IPs pro Subnetz

Azure reserviert in jedem Subnetz die ersten vier IP-Adressen und die letzte IP-Adresse. Diese fünf IPs können nicht an Ressourcen vergeben werden. Das ist eine der wichtigsten Besonderheiten beim IPv4-Subnetting in Azure, weil sie den tatsächlich nutzbaren Adressraum reduziert – insbesondere bei kleinen Netzen. Microsoft beschreibt diese Regel unter anderem im Azure Virtual Network FAQ sowie in Private IP addresses in Azure.

Für eine einfache Überschlagsrechnung der nutzbaren IPv4-Adressen gilt daher:

$\mathrm{nutzbar}=2^{32-p}-5$

Hier ist p die Präfixlänge (z. B. 24 für /24). Ein /24 hat 256 Adressen, in Azure bleiben typischerweise 251 nutzbar. Ein /29 hat 8 Adressen – abzüglich 5 Reservierungen bleiben nur 3 nutzbare IPs. Genau deshalb sind sehr kleine Subnetze im Alltag häufig eine Falle.

Subnetting-Beispiele: Von „einfach“ bis „produktionsreif“

Im Folgenden siehst du drei typische Beispiele, die du als Blaupause nutzen kannst. Wichtig ist weniger die konkrete Zahl als die Logik: klare Zonen, Reserve für Wachstum und konsistente Größen.

Beispiel 1: Kleines VNet für ein Testsystem (einfach, aber korrekt)

• VNet: 10.20.0.0/16
• Subnet-Workload: 10.20.1.0/24
• Subnet-Management: 10.20.2.0/26

Das reicht oft für kleine Umgebungen, solange keine Plattformdienste mit Mindestgrößen geplant sind und keine großen Skalierungssprünge erwartet werden. Der Vorteil: /24 ist leicht zu verstehen, NSG-Policies bleiben übersichtlich, und die 5 reservierten IPs fallen kaum ins Gewicht.

Beispiel 2: Standard-Produktionslayout mit Segmentierung (empfohlen)

• VNet: 10.30.0.0/16
• Subnet-Frontend: 10.30.10.0/24
• Subnet-App: 10.30.20.0/24
• Subnet-Data: 10.30.30.0/24
• Subnet-Management: 10.30.40.0/26
• Subnet-Shared: 10.30.50.0/24
• Reserve: 10.30.60.0/22 (nicht sofort belegen)

Dieses Design unterstützt klare Sicherheitszonen (Tiering) und lässt sich gut erweitern. Die Reserve verhindert, dass du bei jeder neuen Komponente „irgendwo“ im /16 ein weiteres Netz suchst – was langfristig Unordnung erzeugt.

Beispiel 3: Hub-and-Spoke mit Firewall und Hybrid-Anbindung (häufig in Unternehmen)

• Hub-VNet: 10.100.0.0/16 (enthält zentrale Netzwerkdienste)
• Spoke-VNet A: 10.110.0.0/16
• Spoke-VNet B: 10.120.0.0/16

Im Hub liegen typischerweise Subnetze für Gateway, Firewall, Bastion und Shared Services. In den Spokes liegen die Workload-Subnetze. Das Modell ist besonders hilfreich, wenn du Routing zentral über eine Firewall oder NVA erzwingen möchtest.

Stolperfalle: Überlappende Adressräume verhindern Peering und machen Hybrid schwierig

Ein häufiger Fehler ist die „spontane“ Wahl eines RFC1918-Bereichs ohne Abgleich mit bestehenden Netzen. Solange VNets isoliert sind, fällt das manchmal nicht auf. Sobald du aber VNet-Peering, VNet-to-VNet VPN, ExpressRoute oder Partneranbindungen nutzt, werden Overlaps zum Problem: Routen sind nicht eindeutig, Peering kann blockiert werden oder es entstehen Notlösungen mit NAT, die Betrieb und Fehlersuche erheblich erschweren. Microsoft weist in mehreren Kontexten darauf hin, dass Adressräume und Subnetze nicht überlappen dürfen, und behandelt auch, wie man Adressräume bei peered VNets sicher aktualisiert: Update the address space for a peered virtual network.

Praxisregel für kollisionsarmes IPv4-Subnetting

• Zentraler IP-Plan: Definiere feste Containerblöcke pro Region/Umgebung (Prod/Dev/Test).
• Spokes strikt trennen: Jeder Spoke bekommt einen eindeutig reservierten Block (z. B. /16 oder /18).
• Keine „Standard-Heimnetze“ in Unternehmen: Bereiche wie 192.168.0.0/24 oder 192.168.1.0/24 erhöhen Kollisionsrisiken bei VPN/Homeoffice.

Stolperfalle: Zu kleine Subnetze – besonders bei Plattformdiensten

Viele Azure-Dienste benötigen ein dediziertes Subnetz oder empfehlen Mindestgrößen. Wenn du zu klein planst, musst du später umschneiden – was in produktiven Umgebungen schnell schwierig wird. Typische Kandidaten sind VPN Gateway (GatewaySubnet), Azure Firewall (AzureFirewallSubnet), Azure Bastion (AzureBastionSubnet), Application Gateway und bestimmte PaaS-Integrationen. Ein häufiger Auslöser: Ein Team schneidet „sparsam“ /28-Subnetze, vergisst aber die 5 reservierten IPs und unterschätzt Skalierung.

Warum die Mindestgröße in Azure oft größer ausfallen sollte als „rein rechnerisch“

• Reservierte IPs: 5 Adressen pro Subnetz sind fix weg.
• Skalierung: Autoscaling, zusätzliche NICs, neue Instanzen oder neue Service-Endpunkte benötigen IPs.
• Wartung und Erweiterung: Ein zu knappes Subnetz verhindert spätere Änderungen ohne Migration.

Spezialsubnetze in Azure: Namen, Zweck und typische Mindestgrößen

Einige Azure-Komponenten erwarten bestimmte Subnetzkonventionen oder dedizierte Subnetze. Das heißt nicht, dass du alles vorab bereitstellen musst – aber du solltest in deinem Address Space genügend „Platz“ lassen, damit du solche Subnetze später sauber ergänzen kannst.

GatewaySubnet: Für VPN Gateway und ExpressRoute Gateway

Für ein Virtual Network Gateway benötigst du ein Subnetz mit dem Namen GatewaySubnet. Microsoft beschreibt die Grundlagen und Konfiguration im Kontext der VPN Gateway Settings, inklusive Empfehlung zur Subnetzgröße: VPN Gateway settings – GatewaySubnet. In der Praxis ist es sinnvoll, dieses Subnetz nicht „zu klein“ zu schneiden, damit spätere Gateway-SKUs oder Erweiterungen möglich sind.

AzureFirewallSubnet und AzureFirewallManagementSubnet

Azure Firewall wird typischerweise in ein dediziertes Subnetz deployt. Für erzwungenes Tunneling und bestimmte Betriebsmodelle kann zusätzlich ein Management-Subnetz erforderlich sein. Die offizielle Einstiegsperspektive und das Setup findest du im Firewall-Tutorial: Deploy and configure Azure Firewall. Plane diese Subnetze im Hub-VNet frühzeitig ein, sonst wird Routing-Design unnötig kompliziert.

AzureBastionSubnet

Azure Bastion nutzt ein eigenes Subnetz mit dem festen Namen AzureBastionSubnet. In der Bastion-Dokumentation werden die Anforderungen beschrieben, inklusive Subnetzgröße: Create Azure Bastion using the Azure portal. Auch hier gilt: zu knappe Subnetze sind eine häufige Ursache für spätere Umbauten.

Subnetting und Routing: Warum UDRs ohne saubere Segmentierung schnell „weh tun“

Subnetting in Azure ist eng mit Routing verknüpft. Viele Unternehmen wollen ausgehenden Traffic zentral über eine Firewall führen oder Ost-West-Traffic zwischen Spokes kontrollieren. Dazu werden pro Subnetz User Defined Routes (UDRs) gesetzt. Das funktioniert am besten, wenn Subnetze klar nach Zweck geschnitten sind:

• Workload-Subnetze erhalten UDRs zur Firewall/NVA.
• Management-Subnetze werden anders behandelt (z. B. direkte Update-Pfade, separate NSGs).
• Gateway- und Firewall-Subnetze haben Sonderregeln und dürfen nicht „vermengt“ werden.

Wenn du hingegen ein einziges großes Subnetz für alles nutzt, werden UDRs und NSGs schnell zu einem monolithischen Regelwerk, das Änderungen erschwert und Fehlersuche verlängert.

Praxisnahe Planung: Ein wiederholbares Schema für VNets und Subnetze

Ein gutes Subnetting-Schema ist wiederholbar. Das heißt: Du kannst für neue Umgebungen oder neue Spokes denselben Zuschnitt verwenden, ohne jedes Mal neu zu erfinden. Ein bewährter Ansatz ist die Kombination aus „Containerblock“ und festen Zonen:

• VNet-Container: z. B. /16 oder /18 pro Spoke
• Tiers: Frontend, App, Data jeweils /24 (oder größer, wenn Skalierung erwartet wird)
• Management: /26 oder /24 je nach Tooling
• Plattform: reservierte Bereiche für Bastion/Firewall/Gateway im Hub
• Reserve: mindestens 20–30% als freier Bereich, nicht sofort belegen

Beispiel: Spoke-VNet als /18 mit klaren Blöcken

• Spoke VNet: 10.110.0.0/18
• Frontend: 10.110.0.0/24
• App: 10.110.1.0/24
• Data: 10.110.2.0/24
• Management: 10.110.3.0/26
• Reserve: 10.110.4.0/22 und darüber hinaus

Durch diese Struktur bleiben NSG-Regeln und UDRs leichter verständlich, und du kannst bei Wachstum weitere /24-Subnetze in der Reserve anlegen, ohne bestehende Bereiche anfassen zu müssen.

Stolperfalle: DNS, Private Endpoints und „unerwarteter“ IP-Verbrauch

IPv4-Subnetting in Azure scheitert nicht nur an VMs. Moderne Azure-Architekturen verwenden häufig Private Endpoints, interne Load Balancer, Container-Plattformen oder integrierte PaaS-Dienste. Diese Komponenten können pro Ressource IPs belegen – und zwar in genau dem Subnetz, in das sie integriert werden. Wenn Subnetze zu knapp geschnitten sind, entsteht ein Problem, das zunächst wie „mysteriöser IP-Verbrauch“ wirkt.

• Private Endpoints: benötigen eine private IP im Zielsubnetz; bei vielen Services summiert sich das.
• Skalierung: neue Instanzen benötigen neue IPs; bei Auto Scaling wird das schnell sichtbar.
• Segmentierung hilft: getrennte Subnetze pro Zweck machen Kapazitätsplanung einfacher.

Als Basis für die IP-Zuweisung in Subnetzen ist die Microsoft-Seite zu Private IP addresses in Azure hilfreich, insbesondere wegen der Reservierungsregel.

Checkliste: IPv4-Subnetting in Azure VNets ohne typische Fehler

• Adressräume vorab abgleichen: On-Premises, andere VNets, Partnernetze – Overlaps verhindern.
• Subnetze nicht zu klein planen: 5 reservierte IPs immer einkalkulieren.
• Tiering verwenden: Frontend/App/Data/Management trennen, statt „alles in ein Subnetz“.
• Hub-Subnetze reservieren: GatewaySubnet, Firewall- und Bastion-Subnetze früh einplanen.
• Reserve lassen: 20–30% ungenutzter Bereich pro VNet/Spoke für Wachstum.
• Peering/Hybrid im Blick: Adressierung so wählen, dass spätere Verbindungen nicht blockieren.
• UDRs und NSGs vereinfachen: klare Subnetzrollen statt überladener Regelwerke.

Outbound-Links für vertiefende, offizielle Informationen

• Azure Virtual Network FAQ (reservierte IPs, Subnetzregeln)
• Private IP addresses in Azure (Zuweisung und Reservierungen)
• Azure Virtual Network Concepts and Best Practices
• Adressraum bei peered VNets aktualisieren (ohne Downtime)
• GatewaySubnet-Anforderungen (VPN Gateway Settings)
• Azure Firewall bereitstellen (Subnetzkonzept und Setup)
• Azure Bastion erstellen (AzureBastionSubnet-Anforderungen)
• RFC 1918: Private IPv4-Adressbereiche
• RFC 4632: CIDR / Classless Routing

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.