Die Virtual Private Cloud erlaubt es Kunden, einen logisch iso­lierten Bereich in der Amazon-Cloud einzurichten. Sie bildet die Grund­lage für die Bereit­stellung der meisten von inzwischen weit über 150 AWS-Diensten. Ihre Konfi­guration erfor­dert das Einrichten von Sub­netzen, Routing-Tabellen und Gateways.

Für einen schnellen Einstieg bietet Amazon einen Wizard, der das Erstellen eines VPC vereinfacht und mehrere Kompo­nenten automatisch erzeugt. Mehr Kontrolle erlaubt jedoch die manuelle Konfi­guration einer Virtual Private Cloud.

Komponenten und Dienste einer VPC

Eine VPC umfasst eine ganze Reihe von Geräten und Diensten, mit denen man sich vor der AWS-Nutzung beschäftigen sollte. Zu fast allen Objekten gibt es eine passende Entsprechung in traditio­nellen physischen Netz­werken.

Die Virtual Private Cloud selbst ist ein logisch isoliertes virtuelles Netzwerk in der AWS Cloud. Der Kunde definiert den gewünschten IP-Adressraum für seine VPC selbst. Ein Subnetz ist ein Segment eines VPC-IP-Adressbereichs, in dem der Nutzer Gruppen aus isolierten AWS-Ressourcen bereit­stellen kann.

Ein Internet-Gateway repräsentiert die Amazon-VPC-Seite einer Verbindung mit dem öffentlichen Internet. Ein NAT-Gateway ist ein verwalteter, hochver­fügbarer Service für die Network Address Translation (NAT) von Ressourcen in einem privaten Subnetz für den Zugang zum Internet.

Eine Hardware-VPN-Verbindung verbindet ein Amazon VPC und dem eigenen Rechen­zentrum eines Kunden oder einem Heim­netzwerk. Ein Virtual Private Gateway (VPG) repräsentiert die Amazon-VPC-Seite einer VPN-Verbindung. Ein Customer Gateway (CGW) steht für die Kunden-Seite einer Hardware-VPN-Verbindung.

Der implizite Router jeder VPC verbindet Subnetze miteinander und leitet den Datenverkehr zwischen Internet-Gateways, virtuellen privaten Gateways, NAT-Gateways und Subnetzen anhand von Routing-Tabellen weiter.

Peering-Verbindung ermög­lichen es dem Kunden, den Datenverkehr zwischen zwei mittels Peering verbun­denen VPCs über private IP-Adressen zu leiten, also ohne dazu den Internet-Backbone benutzen zu müssen.

VPC-Endpunkte erlauben eine private Verbindung zu Services, die auf AWS gehostet werden, über die VPC des Kunden, ohne dass dieser  ein Internet-Gateway, ein VPN, Network Address Translation (NAT) oder Firewall-Proxys verwenden muss.

Ein Egress-Only-Internet-Gateway (nur IPv6) ist ein zustands­behaftetes Gateway für den ausgehenden Zugriff des IPv6-Datenverkehrs von der VPC auf das Internet.

VPC und Subnetze erstellen

Voraus­setzung für die folgenden Aufgaben ist, dass man als IAM-User mit passenden Berechtigungen für VPC an der AWS Management Console angemeldet  ist. Startpunkt für das Erstellen von VPCs ist die VPC-Konsole, zu finden im Menü Services (links oben in der Management Console) im Bereich Networking & Content Delivery. Im Submenü Your VPCs klickt man dann auf Create VPC, legt den gewün­schten Namen sowie die CIDR-Range fest und klickt auf Yes, Create.

Danach legt man im Untermenü Internet Gateways mit Create internet gateway ein neues IGW an. Hier bedarf es nicht mehr als der Vergabe eines Namens. Anschließend markiert man das Gerät in der Gateway-Liste und verbindet es über den Menüeintrag Actions / Attach to VPC mit der eben erstellten VPC.

Ist die VPC erstellt, dann kann man im Menü Subnets seine Subnetze definieren, was ähnlich einfach ist wie das Definieren der VPC. Hier gibt man einen Namen für das Subnet und die VPC an, in der es erstellt werden soll, sowie die gewünschte Availability Zone. Die Plausibilität der Adress­bereiche prüft AWS.

Zur Erinnerung: Ein Subnet wird nicht einfach durch die entsprechende Benennung zu einem privaten oder öffentlichen Subnetz, sondern durch die assoziierten Route-Tables.

Routing-Tabellen

Durch das Anlegen der VPC ist für sie eine Main-Route-Table entstanden, zu finden im Submenü  Route Tables. In der Abbildung haben wir lediglich diese Route-Tabelle im Feld Name mit Default RT MyVPC manuell gekenn­zeichnet, um besser filtern zu können.

Wer mit einem neuen AWS-Konto startet, sollte hier maximal zwei Route-Tables sehen, nämlich die der Default-VPC und die von MyVPC. Dass es sich um Haupt-Routing-Tabellen handelt, ist in der Spalte Main mit dem Eintrag Yeszu erkennen. Main-Route-Tables haben die besondere Eigenschaft, dass Sie von allen Subnetzen verwendet werden, die nicht explizit mit anderen Routing-Tabellen assoziiert sind.

Wie ein Klick auf den Reiter Routes offenbart, enthält die Default-Route-Table nur eine einzige Route. Diese hat als Destination (also dort, wo „hin“ geroutet wird) lediglich den CIDR-Range der VPC verzeichnet und als Target (das Gerät, über das geroutet wird) den vordefinierten Eintrag  local. Dadurch wird jeglicher Traffic-Flow auf das Innere der VPC beschränkt.

Dies lässt Raum für verschiedene Verwendungs­strategien. Man könnte zum Beispiel die Main-Route-Table sozusagen per Definition als Private-Route-Table betrachten und zu diesem Zweck im Reiter Subnet Associations mit einem Klick auf Edit explizit mit dem gewünschten privaten Subnetzen in der zugehörigen VPC assoziieren.

In der Praxis hat sich aber eher die Strategie bewährt, die Main-Route-Table unan­getastet zu lassen und zwei neue Routing-Tabellen für private und öffentliche Netze zu erstellen. Dies geschieht mit Create Route Table im Menü Route Table. Bei der privaten Routing-Tabelle übernehmen wir zunächst nur die oben beschriebene Default-Route und assoziieren lediglich das private Subnetz. Später könnte noch ein zweites privates Subnetz sowie eine zweite Route zu einem NAT-Gateway hinzu­kommen. Mit einer neu erstellen Public Route Table hingegen verknüpfen wir nicht nur das öffentliche Subnetz, sondern fügen im Reiter Routes mit Edit durch einen Klick auf Add another Route  eine zusätzliche Route hinzu. Diese erlaubt als Destination ein- und ausgehenden Traffic von/zu „0.0.0.0/0“ (Internet) über das Gerät IGW. Hierzu genügt es, in das Target-Feld zu klicken. Die Management Console bietet dann alle in der gewählten VPC verfügbaren Gateway-Geräte anhand ihrer Ressource-ID zur Auswahl an.

Wir haben damit im Bespiel drei Route-Tables, von denen zwei (Public und Private) mit je einem Subnetz assoziiert sind und eine Haupt-Route-Table (Main=Yes), ohne explizite Subnetz-Assoziierung. Damit wäre die Basis gelegt, um erste Web-Server im öffentlichen Subnetz bereitzustellen.