Site icon bintorosoft.com

IPv4-Adressierung in der Cloud: AWS, Azure, GCP Grundlagen

Red Snapper

IPv4-Adressierung in der Cloud wirkt auf den ersten Blick vertraut: Subnetze, Gateways, private und öffentliche IPs – das kennen viele aus On-Premises-Netzen. In AWS, Azure und Google Cloud (GCP) gelten jedoch einige Besonderheiten, die in der Praxis über stabile Konnektivität und sauberes Routing entscheiden. Wer in der Cloud „einfach irgendein 10er-Netz“ auswählt, läuft schnell in typische Probleme: überlappende Adressräume mit On-Premises oder anderen Cloud-Umgebungen, zu kleine Subnetze ohne Wachstumspuffer, nicht einkalkulierte reservierte IPs, ungünstige Zonen- und Regionszuschnitte oder komplizierte Routen- und NAT-Konstrukte. Gleichzeitig ist IPv4 in der Cloud immer auch eine Kosten- und Designfrage: Öffentliche IPv4-Adressen sind knapp, oft nicht unbegrenzt verfügbar und werden je nach Plattform und Nutzung gesondert bepreist oder limitiert. Deshalb ist es wichtig, die Grundlagen der Cloud-Netzwerke zu verstehen – insbesondere, wie AWS VPC, Azure Virtual Network und GCP VPC mit CIDR-Blöcken, Subnetzen und Routing umgehen. Dieser Artikel gibt dir einen strukturierten Überblick über die wichtigsten Konzepte und Unterschiede und zeigt, worauf du bei der IPv4-Adressplanung in AWS, Azure und GCP achten solltest, damit Hybrid-VPNs, Peering und spätere Skalierung nicht an Adresskollisionen oder suboptimalen Subnetzgrößen scheitern.

Grundbegriffe: CIDR, Subnetze, private und öffentliche IPv4

Die meisten Cloud-Netzwerke basieren auf denselben Bausteinen: Ein virtuelles Netzwerk enthält einen oder mehrere IPv4-Adressbereiche (CIDR-Blöcke), daraus werden Subnetze gebildet, und über Routingtabellen wird entschieden, wohin Traffic fließt. Private IPv4-Bereiche sind standardisiert und werden in der Praxis fast immer genutzt, um interne Kommunikation abzubilden. Die maßgebliche Grundlage dafür ist RFC 1918. Für die CIDR-Notation (z. B. /24, /20) ist RFC 4632 eine hilfreiche Referenz.

Warum Cloud-IPv4-Planung anders ist als im Rechenzentrum

Im klassischen LAN ist ein /24 meist „einfach ein /24“. In der Cloud spielen zusätzliche Faktoren eine Rolle:

Besonders relevant ist dabei das Thema „nicht überlappende Adressräume“ – ein Kernprinzip, das Cloud-Anbieter ausdrücklich empfehlen, damit Peering und Hybrid-Konnektivität stabil bleiben.

AWS-Grundlagen: VPC, Subnetze und IPv4-Reservierungen

In AWS ist die zentrale Einheit die Virtual Private Cloud (VPC). Eine VPC erhält einen oder mehrere IPv4-CIDR-Blöcke, aus denen du Subnetze bildest. AWS erwartet dabei nicht überlappende Subnetze innerhalb einer VPC und unterstützt zusätzliche CIDR-Blöcke, wenn du später wachsen musst. Für die Regeln und Größenbereiche von VPC-CIDRs ist die AWS-Dokumentation zu VPC CIDR blocks eine solide Basis.

VPC-CIDR-Größen und Erweiterung

Bei AWS gilt: Ein VPC-IPv4-CIDR muss in einem bestimmten Bereich liegen und darf nicht mit bestehenden CIDRs der VPC überlappen. Typisch ist, initial mit einem ausreichend großen Block (z. B. /16 bis /20) zu starten und Subnetze pro Availability Zone zu schneiden. Später lässt sich ein zusätzlicher CIDR-Block ergänzen, wenn die Planung Reserve braucht. Details dazu findest du in der AWS-Dokumentation zu VPC-CIDR-Regeln.

Wichtig: AWS reserviert 5 IPs pro Subnetz

AWS stellt in jedem Subnetz nicht alle Adressen für Workloads zur Verfügung. Die ersten vier IPs und die letzte IP eines Subnetzes sind reserviert und können nicht an Ressourcen vergeben werden. Das ist entscheidend, wenn du sehr kleine Subnetze planst. Die Details und ein Beispiel listet AWS in der Dokumentation zu Subnet CIDR blocks.

Wenn du die nutzbaren IPv4-Adressen eines Subnetzes grob berechnen möchtest, hilft folgende Formel (unter Berücksichtigung der Reservierungen):

nutzbar = 2 32 − p − 5

Hier ist p die Präfixlänge (z. B. 24 für /24). Ein /24 enthält 256 Adressen, in AWS bleiben davon typischerweise 251 nutzbar.

Azure-Grundlagen: Virtual Network, Subnetze und Adressraum-Disziplin

In Microsoft Azure ist die zentrale Einheit das Virtual Network (VNet). Ein VNet erhält eine oder mehrere Address Spaces (CIDR-Blöcke), innerhalb derer Subnetze angelegt werden. Azure betont dabei ausdrücklich, dass sich Adressräume nicht überlappen dürfen – weder innerhalb des VNets (Subnetze) noch im Gesamtverbund (On-Premises, Peering, weitere VNets). Eine gut verständliche Grundlage liefert Microsoft in Azure Virtual Network Concepts and Best Practices sowie in der Planungsübersicht Plan Azure virtual networks.

Azure reserviert 5 IPs pro Subnetz

Auch Azure reserviert in jedem Subnetz IPv4-Adressen: die ersten vier und die letzte Adresse sind nicht nutzbar. Das ist besonders relevant bei kleinen Subnetzen, weil die „Verlustquote“ dort prozentual stark steigt. Microsoft dokumentiert diese Regel unter anderem im Azure Virtual Network FAQ sowie in Private IP addresses in Azure.

Für eine einfache Überschlagsrechnung (Azure-Subnetz, 5 reservierte IPs) gilt analog:

nutzbar = 2 32 − p − 5

Das erklärt, warum sehr kleine Netze (z. B. /29) in Azure schnell „zu eng“ sind, sobald du mehrere Ressourcen oder Skalierung einplanst.

Adressüberlappungen aktiv verhindern

In größeren Azure-Umgebungen ist nicht nur die Empfehlung wichtig, sondern auch die Umsetzung: Microsoft beschreibt, wie man über Governance-Mechanismen und IPAM-Pools Überlappungen verhindern kann, etwa mit Azure Virtual Network Manager und Policies. Ein Einstieg dazu ist Prevent overlapping virtual network address spaces with Azure Policy.

GCP-Grundlagen: VPC ist global, Subnetze sind regional

Google Cloud VPC unterscheidet sich konzeptionell deutlich von vielen Erwartungen aus klassischen Netzwerken: Eine VPC ist bei GCP eine globale Ressource, Subnetze sind hingegen regional. Das beeinflusst Planung, Segmentierung und die Art, wie du Adressbereiche über Regionen verteilst. Einen guten Überblick liefert die Dokumentation zu VPC networks sowie zu Subnets.

Unterschied zu AWS/Azure: GCP reserviert 4 IPs im primären Subnetzbereich

GCP behandelt reservierte IPv4-Adressen im primären Subnetzbereich anders: Google Cloud nutzt die ersten zwei und die letzten zwei IPv4-Adressen des primären IPv4-Adressbereichs eines Subnetzes für Systemzwecke (Netzadresse, Gateway, zweiteletzte für potenzielle Zukunftsnutzung, Broadcast). Diese Regel ist in der GCP-Subnetz-Dokumentation unter „Unusable addresses in IPv4 subnet ranges“ beschrieben: Subnets (Google Cloud).

Für die nutzbaren IPv4-Adressen (primärer Bereich in GCP) kannst du daher oft so rechnen:

nutzbar = 2 32 − p − 4

Das ist in der Praxis relevant, wenn du sehr viele kleine Subnetze für Microservices, getrennte Tiers oder Projektumgebungen planst.

Auto mode vs. custom mode: Warum das für IPv4-Konnektivität zählt

GCP bietet „auto mode“ VPCs mit vordefinierten IPv4-Ranges, die automatisch pro Region Subnetze anlegen. Das ist für Experimente bequem, kann aber bei Hybrid-Konnektivität und sauberer Adressplanung zum Problem werden, weil die vorgegebenen Bereiche häufig mit anderen Umgebungen kollidieren oder spätere Planung einschränken. Google weist darauf hin, dass auto mode Subnetze in einem vordefinierten Bereich liegen und empfiehlt für Produktion meist „custom mode“, um Adressräume bewusst festzulegen. Siehe dazu VPC networks (Considerations for auto mode) und den Hinweis in Subnets, der insbesondere bei Peering oder Cloud VPN relevant wird.

Subnetzgrößen in der Cloud: Häufige Fehler und praktische Richtwerte

Cloud-Subnetze werden oft entweder zu klein (weil man „sparen“ möchte) oder zu groß (weil man „auf Nummer sicher“ geht) geschnitten. Beides ist ungünstig: zu kleine Subnetze kollidieren mit Reservierungen, Scaling und Managed Services; zu große Subnetze erschweren Segmentierung, Security Policies und Übersicht.

In AWS und Azure sind bei kleinen Netzen die 5 reservierten Adressen besonders spürbar; in GCP sind im primären Bereich 4 Adressen nicht nutzbar. Diese Unterschiede sollten in Kapazitätsplanung und IPAM berücksichtigt werden.

Adressräume in Hybrid- und Multi-Cloud: Overlaps vermeiden, sonst wird es teuer

Die häufigste Ursache für Cloud-Netzprobleme ist nicht ein fehlerhafter Tunnel oder eine „mysteriöse Firewall“, sondern ein überlappender IPv4-Adressraum. Sobald du Cloud VPN, Peering oder Verbindungen zu Partnernetzen etablierst, ist Eindeutigkeit zwingend. Azure formuliert das Prinzip ausdrücklich als Best Practice: Adressräume sollen nicht überlappen, und Subnetze sollen nicht die gesamte VNet-Address Space aufbrauchen, damit Reserven für die Zukunft bleiben. Das ist in Azure Virtual Network Concepts and Best Practices klar beschrieben.

Praxis-Pattern für kollisionsarme Planung

Öffentliche IPv4 in der Cloud: Verstehen, wann du sie wirklich brauchst

Viele Architekturen kommen mit deutlich weniger öffentlichen IPv4-Adressen aus, als man anfangs vermutet. Häufig genügt es, ausgehenden Traffic zentral über NAT zu führen und eingehende Services über Load Balancer, Reverse Proxies oder Gateways zu veröffentlichen. In GCP ist die Unterscheidung von „internal“ und „external“ IPs zentral dokumentiert, inklusive BYOIP-Optionen für externe Adressbereiche: IP addresses (Google Cloud). In AWS ist die VPC als isolierte Netzwerkumgebung beschrieben, in der Ressourcen je nach Design private und/oder öffentliche Erreichbarkeit erhalten: How Amazon VPC works.

Routen, Subnetze und Segmentierung: Unterschiede, die du kennen solltest

Unabhängig vom Anbieter gilt: IPv4-Adressierung ist nur dann „gut“, wenn sie mit Routing und Segmentierung harmoniert. In der Cloud ist Segmentierung häufig ein Mix aus Subnetzen, Security-Gruppen/NSGs, Firewall-Regeln und Routingtabellen. Wichtig ist vor allem, dass Subnetze einen klaren Zweck haben und nicht als „Sammelbecken“ dienen.

Praktische Checkliste für den Start: AWS, Azure, GCP ohne typische IPv4-Fehler

Outbound-Links zu offiziellen Grundlagen und Dokumentation

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:

Lieferumfang:

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.

 

Exit mobile version