VPC/Subnetze planen: IPv4-Adressierung in AWS verständlich erklärt

Wer VPC/Subnetze planen möchte, stößt in AWS schnell auf eine zentrale Wahrheit: Eine gute IPv4-Adressierung in AWS ist weniger „Netzwerk-Theorie“ und mehr eine praktische Entscheidung über Skalierung, Verfügbarkeit und Betrieb. In einer Amazon VPC (Virtual Private Cloud) legst du den privaten IPv4-Adressraum fest, aus dem später Subnetze, Workloads und Managed Services ihre IPs beziehen. Wenn dieser Adressraum zu klein gewählt ist, wird Wachstum mühsam (oder teuer); wenn er unstrukturiert ist, werden Routing, Security Groups, NACLs, Peering und VPN-Verbindungen unnötig kompliziert. Hinzu kommt: AWS hat Regeln, die du aus On-Premises-Netzen so nicht kennst – etwa, dass Subnetze immer genau in einer Availability Zone liegen und dass pro Subnetz mehrere IPv4-Adressen nicht nutzbar sind. Genau deshalb lohnt es sich, die Planung von VPC und Subnetzen sauber aufzusetzen: mit einem CIDR-Plan, der Reserven enthält, mit wiederholbaren Mustern pro Availability Zone und mit einer Segmentierung, die Sicherheit und Betriebsfähigkeit unterstützt. Dieser Artikel erklärt die Grundlagen verständlich, zeigt typische Designmuster (Public/Private Subnets, Multi-AZ), erläutert die wichtigsten AWS-spezifischen IPv4-Regeln und gibt dir ein praxistaugliches Vorgehen, um Subnetze so zu schneiden, dass dein Setup langfristig stabil bleibt.

Grundlagen: Was ist eine VPC und wofür sind Subnetze da?

Eine VPC ist dein virtuelles Netzwerk in AWS. Du weist ihr einen IPv4-CIDR-Block zu und definierst darin Subnetze, in denen Ressourcen wie EC2-Instanzen laufen. Subnetze sind dabei nicht nur „Adressbereiche“, sondern auch organisatorische Grenzen für Routing und Architekturentscheidungen: Öffentlich oder privat, pro Availability Zone, pro Anwendungstier oder pro Sicherheitszone. AWS beschreibt Subnetze als IP-Adressbereiche innerhalb deiner VPC, wobei jedes Subnetz vollständig in genau einer Availability Zone liegen muss. Diese Zone-Bindung ist essenziell für High Availability und sollte in der Planung immer mitgedacht werden (Subnets for your VPC; deutschsprachig: Subnetze für Ihre VPC).

• VPC: containerartiger Adressraum und Routing-Domäne in AWS.
• Subnetz: Teilbereich der VPC, immer einer AZ zugeordnet.
• Routing: wird über Route Tables gesteuert (z. B. Internet Gateway, NAT Gateway, Transit Gateway).
• Segmentierung: wird über Subnetze plus Security Groups/NACLs umgesetzt.

CIDR in AWS: Welche IPv4-Blockgrößen sind erlaubt?

Beim Anlegen einer VPC musst du einen IPv4-CIDR-Block wählen. AWS erlaubt dabei einen Block zwischen /16 und /28. Das bedeutet: Die VPC kann mindestens 16 IPv4-Adressen (/28) bis maximal 65.536 IPv4-Adressen (/16) pro CIDR-Block umfassen. Diese Grenze ist eine AWS-Regel und sollte früh in die Kapazitätsplanung einfließen (VPC CIDR blocks; deutsch: VPC-CIDR-Blöcke).

Wichtig: Du kannst später zusätzliche IPv4-CIDR-Blöcke hinzufügen

Wenn der Adressraum knapp wird, musst du nicht zwangsläufig eine neue VPC bauen. AWS erlaubt, nachträglich zusätzliche IPv4-CIDR-Blöcke mit der VPC zu verknüpfen (Secondary CIDR). Damit lässt sich der Adressraum erweitern, ohne bestehende Subnetze umzunummerieren. AWS erklärt diese Möglichkeit direkt in der CIDR-Dokumentation und beschreibt auch, dass die VPC automatisch lokale Routen für die zugeordneten CIDRs in die Routing-Tabellen einträgt, damit Ressourcen zwischen den CIDR-Blöcken kommunizieren können (VPC CIDR blocks; ergänzend: How do I modify the IPv4 CIDR block of my Amazon VPC?).

Subnetz-Sizing in AWS: Warum „/24 überall“ nicht immer optimal ist

Viele Teams wählen reflexartig /24-Subnetze, weil das aus klassischen Netzwerken vertraut ist. In AWS kann ein /24 tatsächlich ein guter Standard sein – aber nicht immer. Du solltest Subnetze nach Kapazitätsbedarf (Workloads pro AZ), Skalierungsverhalten (Auto Scaling, Kubernetes, Serverless-Anbindungen), Serviceanforderungen (Load Balancer, Endpoints) und Reservierungen planen. AWS liefert Hinweise zur Subnetzkonfiguration und betont, dass Subnetze aus dem VPC-Adressraum stammen und pro AZ vollständig enthalten sein müssen (Subnets for your VPC).

AWS reserviert 5 IPv4-Adressen pro Subnetz

Ein AWS-spezifischer Punkt ist entscheidend: In jedem Subnetz sind die ersten vier IPv4-Adressen und die letzte IPv4-Adresse nicht für Ressourcen nutzbar. Das reduziert die tatsächlich verwendbaren IPs pro Subnetz spürbar – besonders bei kleinen Subnetzen. In der Praxis ist das der häufigste Grund, warum sehr kleine Subnetze (z. B. /28 oder /27) schneller „voll“ sind als erwartet. Diese Reservierungsregel ist in der AWS-Subnetz-Dokumentation aufgeführt (deutsch: Subnetz-CIDR-Reservierungen; englisch: Subnet CIDR reservations).

Für eine überschlägige Berechnung der nutzbaren IPv4-Adressen kannst du (unter Berücksichtigung der AWS-Reservierungen) diese Formel verwenden:

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

Dabei ist p die Präfixlänge. Ein /24 hat 256 Adressen; in AWS bleiben typischerweise 251 nutzbar. Ein /26 hat 64 Adressen; davon sind 59 nutzbar. Das kann bei stark skalierenden Tiers oder bei Services mit vielen ENIs schnell relevant werden.

Public vs. Private Subnets: Das Prinzip hinter der Planung

In AWS wird ein Subnetz nicht „automatisch“ öffentlich oder privat – entscheidend ist das Routing. Ein typisches Muster ist: Pro Availability Zone ein Public Subnet (mit Route zum Internet Gateway) und ein Private Subnet (ohne direkte Route zum Internet Gateway). AWS zeigt in seiner Subnetz-Übersicht ein klassisches Multi-AZ-Layout mit öffentlichen und privaten Subnetzen in zwei Availability Zones (Subnets for your VPC).

• Public Subnet: Route Table enthält eine Route zum Internet Gateway (für eingehende/ausgehende Internet-Konnektivität, typischerweise für Load Balancer, Bastion Hosts oder Edge-Komponenten).
• Private Subnet: keine direkte Internet-Gateway-Route; ausgehender Internetzugang erfolgt häufig über NAT (z. B. NAT Gateway in einem Public Subnet).
• Isolated Subnet: weder Internet Gateway noch NAT; geeignet für besonders abgeschirmte Systeme oder Datenebenen.

Praktisches Segmentierungsmodell nach Tiers

Statt „ein großes privates Subnetz“ ist ein tierbasiertes Modell oft übersichtlicher und sicherer. Beispiel: Web-Tier, App-Tier, Data-Tier jeweils in eigenen Subnetzen pro AZ. So werden Security Groups, NACLs und Routing-Policies klarer, und du kannst Ausnahmen gezielt behandeln.

Multi-AZ-Design: Subnetze pro Availability Zone konsistent schneiden

Ein häufiges Ziel ist Hochverfügbarkeit. Dafür sollten Subnetze pro Availability Zone spiegelbildlich geplant werden: gleiche Präfixlänge, gleiche Funktion (Public/Private/Data), gleiche Namens- und Nummerierungslogik. Der Vorteil: Betrieb und Automatisierung werden einfacher, und du reduzierst Fehlkonfigurationen bei Rollouts.

Beispiel für ein nachvollziehbares CIDR-Muster

• VPC: 10.20.0.0/16
• AZ-a Public: 10.20.0.0/24
• AZ-a Private-App: 10.20.10.0/24
• AZ-a Private-Data: 10.20.20.0/24
• AZ-b Public: 10.20.1.0/24
• AZ-b Private-App: 10.20.11.0/24
• AZ-b Private-Data: 10.20.21.0/24

Dieses Muster erleichtert nicht nur das Lesen, sondern auch Summarization und Policy-Definitionen, wenn später Peering, Transit Gateway oder Hybrid-VPN hinzukommen.

Kapazitätsplanung: Wie groß sollte die VPC wirklich sein?

Die VPC-Größe hängt davon ab, ob du nur ein kleines Projekt hostest oder eine Plattform aufbaust, die über Jahre wachsen soll. Ein verbreiteter Planungsfehler ist, die VPC zu klein zu wählen, weil man „sparen“ möchte, und dann später Subnetze in ungünstige Größen zu pressen. Zwar kannst du zusätzliche CIDR-Blöcke assoziieren, aber ein sauberer Initialplan spart später Aufwand und reduziert Fragmentierung.

Praktische Heuristiken für die VPC-Größe

• /16: sinnvoll, wenn du viele Subnetze, mehrere Umgebungen oder starkes Wachstum erwartest (innerhalb einer VPC-Landing-Zone-Architektur).
• /18 bis /20: häufig ein guter Kompromiss für produktive Workloads mit mehreren Tiers und Multi-AZ.
• /22 bis /24: eher für kleinere, klar abgegrenzte Projekte oder isolierte Umgebungen – mit Reserve planen.

Wichtig ist, dass du die AWS-Grenzen für VPC-CIDRs beachtest (zwischen /16 und /28) und dir bewusst machst, dass du die Größe eines bestehenden CIDR-Blocks nicht „vergrößern“ kannst – du ergänzt ihn durch weitere CIDRs (VPC CIDR blocks).

Hybrid, Peering und Multi-Account: Overlaps von Anfang an verhindern

Spätestens wenn du VPC Peering, Transit Gateway, Site-to-Site-VPN oder Direct Connect einsetzt, werden überlappende IPv4-Adressräume zum echten Problem. Dann funktionieren Routen nicht eindeutig, und du landest schnell bei Workarounds wie NAT – die Betrieb und Fehleranalyse deutlich erschweren. Deshalb ist es Best Practice, Cloud-CIDRs als Teil eines unternehmensweiten IP-Plans zu sehen und eine zentrale Vergabe zu etablieren, statt pro Team „irgendwas aus 10.0.0.0/8“ zu verwenden.

IPAM in AWS: Struktur für größere Umgebungen

AWS bietet mit dem VPC IP Address Manager (IPAM) eine Funktion, um IP-Adressen zentral zu planen, zu verfolgen und zu überwachen. Gerade bei mehreren Accounts, mehreren Regionen oder vielen VPCs reduziert IPAM das Risiko von Overlaps und erleichtert standardisierte Zuweisungen. AWS beschreibt IPAM und die IP-Adressierungsgrundlagen in der Dokumentation (IP-Adressierung für Ihre VPCs und Subnetze) und stellt ein Tutorial zur Subnetzplanung mit IPAM bereit (Tutorial: Planen des VPC-IP-Adressraums).

Subnetzgrößen praxisnah wählen: typische Szenarien

Die „richtige“ Subnetzgröße hängt stark vom Workload ab. Entscheidend ist, dass du nicht nur die Anzahl der Instanzen zählst, sondern auch berücksichtigen kannst, dass manche Architekturen zusätzliche IPs pro Ressource benötigen (z. B. durch zusätzliche Netzwerkschnittstellen, Skalierungsgruppen, Container-Plattformen oder Managed Services). Gleichzeitig sollte der Blast Radius eines Subnetzes nicht unnötig groß sein. Hier sind praxisnahe Richtwerte, die in vielen Umgebungen gut funktionieren:

• Public Subnets: häufig /24 oder /25 pro AZ (typisch für Load Balancer, NAT Gateway, Bastion; oft weniger IP-hungrig, aber Reserve einplanen).
• Private App Subnets: häufig /24 bis /21 pro AZ, abhängig von Skalierung und Platform (z. B. Cluster/Auto Scaling).
• Private Data Subnets: häufig /24 bis /26 pro AZ, abhängig von Datenservices und Security-Design; oft weniger dynamisch, aber kritisch.
• Management/Tools: häufig /26 bis /24 pro AZ, je nach Anzahl Agents, Monitoring, Jump-Hosts.

Warum sehr kleine Subnetze in AWS riskant sein können

Ein /28 hat in AWS nur 11 nutzbare IPv4-Adressen (16 minus 5 Reservierungen). Das ist schnell zu wenig, wenn du mehrere Komponenten in einem Subnetz betreiben willst oder wenn Managed Services zusätzliche Adressen benötigen. Kleine Subnetze eignen sich eher für sehr klar abgegrenzte, stabile Zwecke – und selbst dann nur, wenn du die Reservierungsregel und Wachstum realistisch bewertest (siehe AWS-Subnetz-Dokumentation: Subnetz-CIDR-Reservierungen).

Vorgehensmodell: VPC und Subnetze Schritt für Schritt planen

Ein robustes Vorgehen reduziert spätere Umbauten. Bewährt hat sich dieses Schema:

• Schritt 1: Gesamtadressplan festlegen – Welche RFC1918-Bereiche sind im Unternehmen schon belegt? Wo sind VPN/Peering/Partner geplant? Overlaps vermeiden (Grundlage: RFC 1918).
• Schritt 2: VPC-CIDR dimensionieren – Wachstum, Multi-AZ, Anzahl Subnetze, Reserven; AWS-CIDR-Grenzen beachten (VPC CIDR blocks).
• Schritt 3: AZ-Anzahl definieren – mindestens zwei AZs für produktive Hochverfügbarkeit; Subnetze pro AZ spiegeln (Subnets for your VPC).
• Schritt 4: Subnetz-Typen festlegen – Public, Private-App, Private-Data, optional Management/Shared Services.
• Schritt 5: CIDR-Muster pro Subnetztyp schneiden – konsistent nummerieren, Reserven einplanen, AWS-Reservierungen berücksichtigen (Subnetz-CIDR-Reservierungen).
• Schritt 6: Erweiterungsstrategie definieren – sekundäre CIDRs als Wachstumspfad einkalkulieren (AWS re:Post Knowledge Center).
• Schritt 7: Governance – Namensschema, Tags, IPAM/Inventar, damit zukünftige Teams die Struktur nicht „aus Versehen“ zerstören (VPC IP Addressing/IPAM).

Typische Fehler bei der AWS-IPv4-Adressierung und wie du sie vermeidest

• Zu kleiner VPC-CIDR: führt zu Subnetz-Flickwerk oder frühen Secondary-CIDR-Notlösungen; besser initial Reserven einplanen.
• Unstrukturierte Subnetze: unterschiedliche Größen und Muster pro AZ erschweren Betrieb und Automatisierung.
• Reservierungen ignoriert: kleine Subnetze wirken „ausreichend“, sind aber durch die 5 reservierten IPs schnell erschöpft.
• Overlaps mit On-Premises: machen VPN/Peering komplex oder unmöglich; Adressräume zentral verwalten.
• Zu große Blast-Radius-Subnetze: erschweren Segmentierung und erhöhen Risiko, dass zu viele Workloads im selben Bereich landen.
• Keine Wachstumsstrategie: ohne definierte Reserve oder Secondary-CIDR-Plan wird jede Erweiterung zum Projekt.

Outbound-Links für verlässliche AWS-Grundlagen und Standards

• AWS: VPC CIDR blocks (erlaubte Größen, Secondary CIDR)
• AWS: Subnets for your VPC (AZ-Bindung, Architekturüberblick)
• AWS (DE): Subnetze für Ihre VPC inkl. Subnetz-CIDR-Reservierungen
• AWS re:Post: IPv4-Adressbereich einer VPC erweitern (Secondary CIDR)
• AWS (DE): IP-Adressierung & VPC IP Address Manager (IPAM)
• RFC 1918: Private IPv4-Adressbereiche
• RFC 4632: CIDR / Classless Inter-Domain 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.