Cloud-Subnetze dimensionieren: CIDR nach nutzbaren IP-Adressen wählen

Ein /26-Block enthält 64 IPv4-Adressen. Daraus folgt weder, dass 64 Adressen an Cloud-Ressourcen vergeben werden können, noch ist die übliche Angabe von 62 nutzbaren Hosts in jeder Cloud richtig.

Nehmen wir ein hypothetisches System, das heute 50 Adressen für Netzwerkschnittstellen benötigt. Das Team setzt für die Planung eine Reserve von 20 Prozent an und kommt damit auf 60 Adressen. Nach der klassischen Subnetzrechnung scheint ein /26 mit 62 nutzbaren Hosts zu reichen. In AWS und Azure sind jedoch jeweils fünf Adressen nicht verfügbar. Es bleiben 59 – eine Adresse zu wenig.

Die richtige Entscheidung entsteht deshalb in zwei Schritten: zuerst die mathematische Blockgröße bestimmen, dann die Regeln des konkreten Providers und Dienstes anwenden. Die 20 Prozent in diesem Beispiel sind keine allgemeine Empfehlung, sondern eine offengelegte Annahme für die Beispielrechnung.

Was sich direkt aus dem CIDR-Präfix berechnen lässt

Eine IPv4-Adresse hat 32 Bit. Bei einer Präfixlänge p enthält der Block:

Gesamtzahl = 2^(32 - p)

RFC 4632 beschreibt die CIDR-Präfixnotation und führt für /26 64 sowie für /25 128 Adressen auf. Das Präfix beschreibt die Größe eines Blocks. Reservierungen eines Cloud-Providers oder Kapazitätsregeln eines verwalteten Dienstes sind darin nicht enthalten.

Geben Sie im Calquio CIDR-Rechner den Wert 26 ein. Das Ergebnis lautet:

Die 62 entstehen, weil bei einem herkömmlichen IPv4-Subnetz Netzwerk- und Broadcastadresse abgezogen werden. Für die Cloud-Planung folgt ein weiterer Schritt:

Zuweisbare Provider-Kapazität = Gesamtzahl - vom Provider reservierte Adressen

Der Rechner weiß nicht, ob der Block für ein AWS-VPC-Subnetz, ein Azure-VNet-Subnetz, einen primären oder sekundären Google-Cloud-Bereich oder ein spezielles Dienst-Subnetz gedacht ist. Die Anzeige „nutzbare Hosts“ ist daher ein technischer Ausgangswert, keine Kapazitätszusage des Providers.

Reservierungen von AWS, Azure und Google Cloud

Die aktuell dokumentierten Regeln ergeben für denselben Block unterschiedliche Werte:

AWS dokumentiert die ersten vier und die letzte IPv4-Adresse als nicht verfügbar. Azure reserviert ebenfalls die ersten vier und die letzte Adresse. Google Cloud verwendet in einem primären IPv4-Bereich die ersten zwei und die letzten zwei Adressen.

Diese Werte dürfen nicht pauschal auf jeden Bereich übertragen werden. Laut Google-Dokumentation sind in sekundären IPv4-Bereichen alle Adressen nutzbar. AWS nennt eine Ausnahme für BYOIP. Verwaltete Firewalls, Gateways oder Kubernetes-Dienste können außerdem ein Mindestpräfix verlangen oder beim Skalieren zusätzliche Adressen belegen. Maßgeblich ist deshalb die Dokumentation für den genauen Bereichs- und Diensttyp.

Beispielrechnung für 50 heutige Adressen

Der hypothetische Bestand von 50 Adressen könnte so aufgeteilt sein:

• 36 Netzwerkschnittstellen für Anwendungen
• 8 Schnittstellen für Worker oder Build-Systeme
• 4 interne Endpunkte
• 2 Adressen für den Betrieb

Diese Aufteilung ist keine Architektur-Empfehlung. Sie macht lediglich die Rechnung reproduzierbar. In einem echten Inventar muss jede Komponente mit eigener IP genau einmal erfasst werden.

Mit der angenommenen Reserve:

Planungsziel = ceil(50 × 1,20) = 60

Nun lassen sich die Präfixe vergleichen:

Für AWS und Azure scheitert /26, weil 64 - 5 = 59 kleiner als 60 ist. /25 liefert mit 128 - 5 = 123 genügend Kapazität.

Im primären Google-Cloud-Bereich erreicht /26 mit 64 - 4 = 60 das Ziel exakt. „Exakt“ bedeutet jedoch, dass beim Erreichen des Ziels keine Reserve mehr bleibt. Eine vergessene Load-Balancer-Schnittstelle oder die kurzzeitige Parallelbelegung während eines Rolling Updates kann dann eine Zuweisung verhindern. Wenn der übergeordnete Adressplan genügend Raum hat, kann /25 daher trotzdem die belastbarere Entscheidung sein.

Auch die Gegenrichtung ist problematisch: Wer ohne Rechnung immer /24 wählt, reserviert vor Abzügen 256 Adressen. Über viele Umgebungen und Sicherheitsebenen hinweg kann das den privaten Adressraum zerstückeln und spätere überschneidungsfreie Peerings oder VPN-Verbindungen erschweren. Gesucht ist der kleinste providerkonforme Block, der den dokumentierten Bedarf und eine begründete Reserve abdeckt.

Sensitivität an den Präfixgrenzen prüfen

Einige Zielwerte zeigen, wie stark eine einzige zusätzliche Adresse wirken kann:

Bei Google Cloud führt der Schritt von 60 auf 61 benötigte Adressen von /26 zu /25; der gesamte Block verdoppelt sich von 64 auf 128. Das ist kein Rundungsfehler, sondern eine Folge der Zweierpotenzen bei CIDR. Im Architekturprotokoll sollte daher stehen, welcher Spitzenbedarf und welche Reserve die größere Zuteilung begründen.

Planen Sie nicht nur den stationären Zustand. Bei einem Rolling Replacement können alte und neue Schnittstellen vorübergehend gleichzeitig existieren. Autoscaling, Private Endpoints, Load Balancer und Steuerkomponenten verwalteter Dienste können weitere Adressen beanspruchen. Die aktuelle Dienstdokumentation sollte für jedes dieser Elemente in eine konkrete Inventarzeile übersetzt werden.

Checkliste für eine providerbewusste Entscheidung

Vor dem Anlegen des Subnetzes sollten folgende Punkte dokumentiert sein:

1. Bereichstyp: Provider, IPv4-Typ sowie primär, sekundär, BYOIP oder dienstexklusiv.
2. Dauerbedarf: Schnittstellen, Endpunkte, Knoten und Dienstadressen im Normalbetrieb.
3. Spitzenbedarf: Überlappung bei Deployments, Failover und maximale Skalierung.
4. Reserve: Prozentwert oder feste Anzahl samt Begründung.
5. Provider-Abzug: Gesamtzahl minus der Reservierungen für genau diesen Bereichstyp.
6. Dienstvorgaben: Mindestpräfixe und Anforderungen an dedizierte Subnetze.
7. Adressplan: Überschneidungen mit lokalen Netzen, anderen VPCs/VNets, Peers und VPN-Zielen.

Prüfen Sie danach im CIDR-Rechner nochmals Gesamtzahl und Subnetzmaske. Schreiben Sie den Provider-Abzug direkt neben das Ergebnis. So wird aus der technischen Basis „62 nutzbar“ nicht versehentlich eine AWS- oder Azure-Kapazitätsangabe.

Grenzen der Rechnung

Die Rechnung dimensioniert IPv4-Adresskapazität. Sie entwirft weder Routing und Sicherheitszonen noch Availability-Zone-Verteilung, IPv6 oder Kubernetes-Pod-Bereiche. Ein größeres Subnetz ist nicht automatisch sicherer oder ausfallsicherer.

Der Bestand von 50 Adressen und die Reserve von 20 Prozent sind hypothetisch. Ersetzen Sie beides durch Messwerte, dokumentiertes Skalierungsverhalten und die Wiederanlaufanforderungen Ihrer Organisation. Providerregeln und Dienstvorgaben können sich ändern; vor der Bereitstellung ist die aktuelle offizielle Dokumentation erneut zu prüfen.

Quellen

• RFC 4632: Classless Inter-domain Routing (CIDR) — IETF Best Current Practice, August 2006; abgerufen am 29. Juli 2026.
• AWS: Subnet CIDR blocks — aktuelle Dokumentation zu VPC-Reservierungen und Subnetzgrößen; die Seite nennt kein Revisionsdatum; abgerufen am 29. Juli 2026.
• Microsoft Azure: Virtual networks and subnets — aktualisiert am 22. Juni 2026; abgerufen am 29. Juli 2026.
• Google Cloud: Subnets — aktualisiert am 27. Juli 2026 UTC; abgerufen am 29. Juli 2026.