VPC-Architektur und CIDR-Blöcke

Eine Amazon Virtual Private Cloud (VPC) ist ein logisch isoliertes privates Netzwerk innerhalb einer AWS-Region, das Sie definieren und kontrollieren. Jedes AWS-Konto verfügt in jeder Region über eine Standard-VPC (CIDR 172.31.0.0/16), in Produktionsarchitekturen werden jedoch immer benutzerdefinierte VPCs verwendet. Eine VPC erstreckt sich über alle Availability Zones ihrer Region und gibt Ihnen vollständige Kontrolle über IP-Adressierung, Subnetze, Routing-Tabellen, Internet-Gateways und Sicherheit. Ressourcen innerhalb einer VPC sind von anderen VPCs und vom Internet isoliert, sofern Sie nicht ausdrücklich eine Verbindung konfigurieren.

Ein CIDR (Classless Inter-Domain Routing)-Block definiert den IP-Adressbereich einer VPC oder eines Subnetzes im Format x.x.x.x/prefix. Die Präfixlänge bestimmt, wie viele IP-Adressen der Bereich umfasst: /16 = 65.536 Adressen, /24 = 256 Adressen, /28 = 16 Adressen (kleinste Subnetzgröße in AWS). Für VPCs erlaubt AWS CIDR-Blöcke von /16 (größter) bis /28 (kleinster). Wählen Sie einen VPC-CIDR-Block, der (1) keine Überschneidungen mit lokalen Netzwerken aufweist (für zukünftige VPN-/Direct-Connect-Verbindungen), (2) groß genug für Ihre geplanten Subnetze ist und (3) den privaten RFC-1918-Adressraum verwendet (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Ein Subnetz ist ein Segment des IP-Adressbereichs einer VPC, das sich in einer einzelnen Availability Zone befindet. Subnetze werden als öffentlich (mit einer Route zu einem Internet-Gateway) oder privat (ohne direkte Internet-Route) klassifiziert. Als Best Practice für eine typische 3-Tier-Architektur erstellen Sie mindestens drei Subnetzebenen: public (Load Balancer, Bastion Hosts), private-app (EC2-Instances, ECS-Tasks) und private-data (RDS, ElastiCache). Replizieren Sie jede Ebene für hohe Verfügbarkeit über mindestens zwei AZs.

Ein gängiger CIDR-Entwurf für eine VPC mit dem CIDR 10.0.0.0/16, zwei AZs und drei Ebenen sieht so aus: Public AZ-a: 10.0.1.0/24; Public AZ-b: 10.0.2.0/24; Private-App AZ-a: 10.0.10.0/24; Private-App AZ-b: 10.0.11.0/24; Private-Data AZ-a: 10.0.20.0/24; Private-Data AZ-b: 10.0.21.0/24. Dieses Layout lässt Raum für zusätzliche Subnetze in AZ-c (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24), ohne das gesamte CIDR-Schema neu planen zu müssen. Planen Sie immer mit Blick auf zukünftiges Wachstum.

AWS reserviert in jedem Subnetz die ersten vier und die letzte IP-Adresse. Für ein 10.0.1.0/24-Subnetz sind dies: 10.0.1.0 (Netzwerk), 10.0.1.1 (VPC-Router), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (für zukünftige Verwendung) und 10.0.1.255 (Broadcast). Ein /24-Subnetz umfasst insgesamt 256 IPs; abzüglich der 5 reservierten IPs bleiben 251 nutzbare IPs. Ein /28-Subnetz (das Minimum) umfasst 16 IPs; abzüglich 5 bleiben 11 nutzbare IPs. Das ist wichtig, wenn Sie Subnetze anhand der Anzahl der Ressourcen dimensionieren, die Sie bereitstellen möchten (EC2-Instances, Lambda-Funktionen mit VPC usw.).

Sie können einem vorhandenen VPC bis zu vier sekundäre CIDR-Blöcke hinzufügen, ohne es neu erstellen zu müssen. Das ist hilfreich, wenn der primäre CIDR-Block ausgeschöpft ist (alle Subnetze sind voll) oder wenn Sie für einen bestimmten Anwendungsfall wie die Pod-Vernetzung in Kubernetes Adressraum aus einem anderen RFC-1918-Bereich hinzufügen müssen. Für sekundäre CIDR-Blöcke gelten bestimmte Einschränkungen – beispielsweise können Sie keinen überlappenden CIDR-Block hinzufügen, und bestimmte öffentliche Bereiche außerhalb von RFC 1918 dürfen nicht verwendet werden. Planen Sie die Größe des VPC-CIDR-Blocks von Anfang an sorgfältig, um den Bedarf an sekundären CIDR-Blöcken möglichst gering zu halten.

VPC-Peering stellt eine private Netzwerkverbindung zwischen zwei VPCs her, sodass deren Ressourcen über private IP-Adressen miteinander kommunizieren können. Die per Peering verbundenen VPCs können sich in demselben Konto, in verschiedenen Konten oder sogar in verschiedenen Regionen befinden (Inter-Region-Peering). Voraussetzung: Die CIDR-Blöcke der beiden VPCs dürfen sich nicht überschneiden. Einschränkung: Peering ist nicht transitiv – wenn VPC-A per Peering mit VPC-B und VPC-B per Peering mit VPC-C verbunden ist, kann VPC-A nicht über VPC-B mit VPC-C kommunizieren. Für eine vollständige Mesh-Konnektivität zwischen vielen VPCs verwenden Sie stattdessen AWS Transit Gateway.

AWS Transit Gateway (TGW) fungiert als zentraler Netzwerk-Hub – ein Cloud-Router, der mehrere VPCs, VPNs und Direct-Connect-Verbindungen miteinander verbindet. Statt für ein vollständiges Mesh aus N VPCs N*(N-1)/2 VPC-Peering-Verbindungen zu erstellen, verbinden Sie jede VPC und jede Verbindung mit dem Transit Gateway, das den Datenverkehr zwischen ihnen weiterleitet. TGW unterstützt Routing-Tabellen, mit denen Sie steuern können, welche Verbindungen miteinander kommunizieren dürfen. Dadurch lässt sich eine Netzwerksegmentierung umsetzen (beispielsweise können Produktions-VPCs von Entwicklungs-VPCs auf demselben TGW isoliert werden).

Zwei DNS-Einstellungen steuern die Namensauflösung in einem VPC. enableDnsSupport: Wenn der Wert true ist (Standard), verwendet das VPC den von AWS bereitgestellten DNS-Resolver unter 169.254.169.253 oder die zweite IP-Adresse des VPC-CIDR-Blocks (z. B. 10.0.0.2 für 10.0.0.0/16). enableDnsHostnames: Wenn der Wert true ist (muss für benutzerdefinierte VPCs aktiviert werden, im Standard-VPC standardmäßig aktiviert), erhalten EC2-Instances im VPC DNS-Hostnamen wie ip-10-0-1-15.ec2.internal. Beide Einstellungen müssen aktiviert sein, damit Route 53 Private Hosted Zones innerhalb des VPCs funktionieren.

VPC-Flow-Logs erfassen Metadaten zum Netzwerkverkehr, der durch Ihr VPC fließt – Quell- und Ziel-IP-Adresse, Port, Protokoll, übertragene Bytes sowie die Information, ob der Datenverkehr akzeptiert oder abgelehnt wurde. Flow-Logs können in CloudWatch Logs (zur Abfrage mit Logs Insights) oder in S3 (zur Analyse mit Athena) veröffentlicht werden. Sie sind für Sicherheitsforensik (wer hat womit eine Verbindung hergestellt?), Verkehrsanalyse (Erkennen von Datenströmen mit hoher Bandbreite) und die Fehlerbehebung (warum wurde eine Verbindung abgelehnt?) äußerst wertvoll. Flow-Logs können auf VPC-, Subnetz- oder einzelner-ENI-Ebene aktiviert werden.

Planen Sie vor der Erstellung eines VPCs alle zukünftigen Anforderungen an die Konnektivität: Konnektivität mit lokalen Netzwerken (VPN oder Direct Connect) – stellen Sie sicher, dass sich der VPC-CIDR-Block nicht mit den Subnetzen des lokalen Netzwerks überschneidet; Konnektivität zwischen VPCs (Peering oder Transit Gateway) – planen Sie nicht überlappende CIDR-Blöcke für alle VPCs in Ihrer Organisation; Zugriff auf AWS-Services (VPC-Endpunkte für S3, DynamoDB und SSM, damit der Datenverkehr nicht über das Internet geleitet wird); sowie Subnetzgröße – lassen Sie in jedem Subnetz ausreichend Reserven für den IP-Adressverbrauch durch EKS-Pods, Lambda-Funktionen und Elastic Network Interfaces.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: Ein VPC ist ein logisch isoliertes Netzwerk in einer Region, das durch einen CIDR-Block definiert und über AZs hinweg in öffentliche und private Subnetze unterteilt wird; AWS reserviert in jedem Subnetz 5 IP-Adressen, daher müssen Sie diese Reduzierung bei der Subnetzgröße stets berücksichtigen; und VPC-Peering und Transit Gateway verbinden VPCs privat, die CIDR-Bereiche dürfen sich jedoch nicht überschneiden. Als Nächstes sehen wir uns Internet Gateways und Routing-Tabellen an.