IP-Bereich und Subnets planen¶
Wenn du einen Spoke anfragst, gibst du an, wie groß dein Netzwerk sein muss. Das Plattform-Team weist den tatsächlichen Bereich aus dem zentralen IP-Plan zu, damit sich Bereiche nie überlappen, was für das Hub-Routing erforderlich ist. Die Bereiche sind privat: Sie sind aus dem Internet nicht erreichbar.
Größen¶
Azure reserviert 5 Adressen pro Subnet (die ersten vier und die letzte). Die nutzbare Anzahl ist daher die Summe minus 5.
| CIDR | Adressen gesamt | Nutzbar in einem Subnet |
|---|---|---|
/28 |
16 | 11 |
/27 |
32 | 27 |
/26 |
64 | 59 |
/25 |
128 | 123 |
/24 |
256 | 251 |
Viele Azure-Dienste belegen mehrere Adressen für Verfügbarkeit und Skalierung (App Service Integration, AKS-Nodes, private endpoints, Application Gateway). Prüfe auf der Microsoft-Learn-Seite des jeweiligen Dienstes die minimale Subnet-Größe und die Delegation, und plane etwas Spielraum für Wachstum ein.
Mit Spielraum starten
Ein /24 ist ein üblicher Standard für einen Spoke. Wenn du mehr brauchst, gib das in deiner Anfrage an: Ein größerer Bereich lässt
sich zu Beginn leichter zuweisen, als später etwas hinzuzufügen. Nutze innerhalb des Bereichs nicht alle Adressen auf einmal. Lass Platz für neue
Subnets, denn ein Subnet, das Ressourcen enthält, kann nicht in der Größe geändert werden.
Subnets¶
Du kannst dein VNet in Subnets aufteilen, um getrennte NSGs und Routen anzuwenden, zum Beispiel eines für Datenbanken und eines für Web. Im MCP-Spoke-JSON gilt:
- Jedes Netzwerk braucht mindestens ein Private-Link-Subnet (
isprivatelinksubnet: true) für private endpoints. Das Key Vault und das Storage Account des Spokes nutzen das erste. - Füge Delegationen und Service Endpoints pro Subnet hinzu (Spoke JSON).
- Subnets, die bereits Ressourcen enthalten, können nicht in der Größe geändert werden. Lege stattdessen ein neues Subnet an.
Standardwerte unterscheiden sich je Plattform
Manche Plattformen erstellen immer zwei Standard-Subnets (zum Beispiel ein default- und ein private-endpoints-Subnet). MCP erstellt die in deiner Anfrage aufgeführten Subnets. Benenne sie so, wie dein Plattform-Team es vorgibt.
Beispiel¶
Ein /26-VNet (10.97.0.0 bis 10.97.0.63), aufgeteilt in vier /28-Subnets:
| Subnet | CIDR | Adressen |
|---|---|---|
snet-default |
/28 |
10.97.0.0 bis 10.97.0.15 |
snet-privatelink |
/28 |
10.97.0.16 bis 10.97.0.31 |
snet-app |
/28 |
10.97.0.32 bis 10.97.0.47 |
snet-data |
/28 |
10.97.0.48 bis 10.97.0.63 |
Subnets mit besonderen Anforderungen¶
Manche Dienste brauchen ein eigenes Subnet mit einer Mindestgröße und einer Delegation. Prüfe die Microsoft-Learn-Seite des
Dienstes, bevor du den Bereich planst. Ein Beispiel von einer Kundenplattform: Die v2-Tiers von API Management mit Virtual-Network-Integration
brauchen ein dediziertes Subnet, das sich keine andere Ressource teilt, mindestens ein /27 (mit einem /24 bleibt Platz zum
Skalieren), delegiert an Microsoft.Web/serverFarms, mit angehängter NSG. Frag dein Plattform-Team, ob das für den
Service-Tier gilt, den du nutzt.
Network Security Groups auf deinen Subnets¶
Jedes Subnet bekommt eine NSG. Wenn du NSG-Änderungen anfragst, ändere nicht die Priorität einer bestehenden Regel. Frage stattdessen eine neue Regel mit einem neuen Namen an. Siehe So änderst du etwas.
Später wachsen¶
Wenn du später mehr Adressen brauchst, kann das Plattform-Team dir einen zusätzlichen Adressraum oder ein neues VNet geben, weil der angrenzende Bereich möglicherweise schon belegt ist. Das funktioniert problemlos, aber die Bereiche sind dann nicht mehr zusammenhängend.
Tools¶
- Azure virtual network best practices
- Ein beliebiger Subnet-Rechner, zum Beispiel CIDR.xyz oder IPcalc.
Was mit dem Bereich passiert, wenn ein Spoke gelöscht wird¶
Der Bereich bleibt im zentralen IP-Plan reserviert, bis das Plattform-Team ihn freigibt. Wenn du einen Spoke löschst, gibt das Plattform-Team auch den Bereich frei, sodass er wieder genutzt werden kann. Siehe Spoke löschen.
Siehe auch: So fragst du einen neuen Spoke an, So änderst du einen Spoke.