AWS-Subnetze: Das Rückgrat der Cloud-Netzwerkarchitektur
In Amazon Web Services sind Subnetze die grundlegenden Bausteine der Netzwerkisolation und Organisation innerhalb eines Virtual Private Cloud (VPC). Jede AWS-Ressource, die Netzwerkverbindung benötigt — EC2-Instanzen, RDS-Datenbanken, Lambda-Funktionen, Load-Balancer — muss in einem Subnetz platziert werden. Das Verständnis der Funktionsweise von AWS-Subnetzen und ihrer effektiven Planung ist entscheidend für die Gestaltung sicherer, skalierbarer und hochverfügbarer Cloud-Architekturen.
Was ist ein AWS-Subnetz?
Ein AWS-Subnetz ist eine logische Partition einer VPC, die innerhalb einer einzigen Availability Zone existiert. Jedes Subnetz hat seinen eigenen CIDR-Block, einen zusammenhängenden IP-Adressbereich, der aus dem Haupt-CIDR-Bereich der VPC herausgeschnitten wurde. Subnetze sind mit einer Routing-Tabelle verknüpft, die bestimmt, wie Datenverkehr in und aus dem Subnetz fließt. Sie können auch mit einer Netzwerk-ACL (NACL) für zustandslose Firewall-Steuerung an der Subnetzgrenze verknüpft werden. Ressourcen im selben Subnetz können direkt miteinander kommunizieren, während die Kommunikation zwischen Subnetzen über den VPC-Router geroutet wird.
Einer der wichtigsten Aspekte von AWS-Subnetzen ist, dass sie an eine einzige Availability Zone gebunden sind. Dieses Design ermöglicht hohe Verfügbarkeit und Fehlertoleranz. Durch die Bereitstellung identischer Appliance-Stacks in Subnetzen in verschiedenen AZs können Sie einen gesamten Rechenzentrumsausfall ohne Ausfallzeit überstehen. Der AWS-Subnetz-Rechner auf dieser Seite hilft Ihnen bei der Planung Ihrer Subnetz-Zuweisung, indem er automatisch CIDR-Blöcke für jede AZ generiert, die korrekten Subnetzgrenzen berechnet und die 5 reservierten IP-Adressen von AWS pro Subnetz berücksichtigt.
Öffentliche vs. Private Subnetze
AWS-Subnetze werden je nach ihrer Routing-Tabelle-Konfiguration als öffentlich oder privat eingestuft. Ein öffentliches Subnetz hat eine Route zu einem Internet Gateway (IGW), das Ressourcen mit öffentlichen IP-Adressen die direkte Kommunikation mit dem Internet ermöglicht. Öffentliche Subnetze werden typischerweise für Load-Balancer, Bastion-Hosts und NAT-Gateways verwendet. Ein privates Subnetz hat keine direkte Route zum IGW. Ressourcen in privaten Subnetzen können über ein NAT-Gateway (für ausgehenden Datenverkehr) oder über einen VPC-Endpunkt (für den Zugriff auf AWS-Dienste) auf das Internet zugreifen, können aber keinen unerbetenen eingehenden Datenverkehr vom Internet empfangen, was eine zusätzliche Sicherheitsebene bietet.
Die AWS-Standard-Best-Practice ist es, pro Availability Zone mindestens zwei Subnetze bereitzustellen: ein öffentliches und ein privates. Für Produktions-Workloads in drei AZs bedeutet dies mindestens sechs Subnetze. Die öffentlichen Subnetze beherbergen die internetorientierten Komponenten, während die privaten Subnetze Anwendungsserver, Datenbanken und andere sensible Ressourcen beherbergen. Der AWS-Subnetz-Rechner hilft Ihnen bei der Planung dieser Architektur, indem er die CIDR-Blöcke für jeden Subnetztyp in allen ausgewählten Availability Zones mit ordnungsgemäßem Abstand zur Vermeidung von Überlappungen generiert.
AWS-reservierte IPs und CIDR-Planung
AWS reserviert 5 IP-Adressen in jedem Subnetz: die ersten 4 Adressen (Netzwerkadresse, VPC-Router, DNS-Server und eine für zukünftige Verwendung reservierte Adresse) und die letzte Adresse (Broadcast). Für ein /24-Subnetz bedeutet dies, dass nur 251 der 256 Adressen für Ressourcen verfügbar sind, nicht 254 wie im traditionellen Netzwerk. Kleinere Subnetze verlieren einen höheren Prozentsatz von Adressen durch diese Reservierungen. Ein /28-Subnetz hat beispielsweise 16 Gesamtadressen, aber nur 11 nutzbare. Dies ist eine wichtige Überlegung bei der Dimensionierung von Subnetzen für AWS-Bereitstellungen.
Eine ordnungsgemäße CIDR-Planung ist unerlässlich, um sicherzustellen, dass Sie genügend IP-Space für aktuelle und zukünftige Ressourcen haben, ohne Adressen zu verschwenden. AWS empfiehlt die Verwendung des privaten Bereichs 10.0.0.0/8 für VPCs, wobei eine VPC-Größe von /16 für große Bereitstellungen üblich ist. Jedes Subnetz in der VPC sollte mindestens /28 sein, um genügend nutzbare Adressen bereitzustellen. Der AWS-Subnetz-Rechner vereinfacht dies, indem er Ihre VPC-CIDR und gewünschte Subnetz-Größe übernimmt und dann einen vollständigen Plan mit CIDR-Blöcken, Netzwerkadressen und nutzbaren Host-Zählungen für jedes Subnetz generiert.
Warum ordnungsgemäße Subnetz-Planung wichtig ist
Schlechte Subnetz-Planung ist eine der häufigsten Ursachen für Re-Architektur-Arbeiten in AWS. Überlappende CIDR-Blöcke verhindern VPC-Peering und VPN-Verbindungen. Zu kleine Subnetze zwingen die Neunummerierung von Ressourcen. Zu große Subnetze verschwenden IP-Space und können die Verwaltung von Sicherheitsgruppen und NACLs komplexer machen. Eine gut geplante Subnetz-Strategie berücksichtigt Wachstum, Multi-Region-Expansion und Konnektivitätsanforderungen mit lokalen Netzwerken.
Bevor Sie eine VPC erstellen, berücksichtigen Sie Ihre gesamten Adressanforderungen, die Anzahl der pro AZ benötigten Subnetze und die zukünftige Konnektivität zu anderen VPCs oder Rechenzentren. Verwenden Sie einheitliche Namenskonventionen und markieren Sie Subnetze klar für Umgebung (dev, staging, prod) und Schicht (web, app, db). Der AWS-Subnetz-Rechner hilft Ihnen, Ihr Netzwerk-Layout zu visualisieren, bevor Sie sich für einen CIDR-Plan entscheiden, spart Zeit und verhindert kostspielige Fehler.