Mit VPC kann jeder Kunde der Amazon Web Services einen logisch isolierten Bereich in der AWS-Cloud ein­richten. Dabei darf er die IP-Adress­bereiche, die Sub­netze, Routing-Tabellen und Gateway-Geräte selbst konfigurieren. Amazon unter­stützt Admini­stratoren bei dieser Auf­gabe mit einem grafischen Assistenten.

Grundsätzlich sollte man immer mit 4 Subnetzen in einer VPC starten, also je einen privaten und einem öffentlichen Subnetz in jeder Availability-Zone. Dies erlaubt später das hoch­verfügbare Bereit­stellen von öffentlichen (Web-Server, Load-Balancer) oder privaten (Applikations-Server, Datenbanken) EC2-Ressourcen. Ob ein Subnetz öffentlich oder privat ist, bestimmt keine Eigenschaft des Subnetzes, sondern ist eine Frage der Routing-Tabellen. Ein in einem privaten Subnetz bereit­gestellter Server ist ohne weitere vom Nutzer veranlasste Maßnahmen (Bastion-Host, Jump-Host) unter keinen Umständen von außerhalb der VPC sicht- und erreichbar.

VPC-Wizard

Neben einer Default-Route-Table für jede neue VPC kann der Nutzer jederzeit weitere Routing-Tabellen mit individuellen Routen konfigurieren und nach Belieben mit VPCs assoziieren. Der Vorgang der VPC-Erstellung kann Assistenten-gestützt oder manuell erfolgen.

In diesem Teil verwenden wir den Assistenten, weisen aber darauf hin, dass dieser automatisch auch Internet Gateways, sowie bei Bedarf auch NAT-Gateways und VPN-Gateways nebst zugehörige Routen und Subnet-Assoziierungen erstellt, was man beim manuellen Vor­gehen selbst erledigen muss. Um den VPC-Wizard zu erreichen, muss man in der VPC-Konsole explizit auf den Button Launch VPC Wizard klicken. Ist man bereits im Submenü Subnets, dann steht nämlich nur der Knopf Create Subnet für das manuelle Vorgehen bereit.

Der VPC-Assistent sieht vier vorge­fertigte Szenarien vor:

• VPC with a Single Public Subnet
• VPC witch Public and Private Subnets
• VPC with Public and Private Subnets and Hardware VPN Access
• VPC with a Private Subnet Only and Hardware VPN Access

Wir entscheiden und für die zweite Variante. Das Ausfüllen des Dialoges sollte erfahrene IT-Administratoren mit Netzwerk­kenntnissen vor keine großen Probleme stellen.

Zuerst gibt man den CIDR-Range der VPC an. In unserem Beispiel überschreiben wir den Default-Vorschlag 10.0.0.0/16 mit 192.168.0.0/16, um nicht in Konflikt mit vorhandenen VPCs zu kommen. Entscheidend ist nur, private IP-Bereiche zu verwenden. Allerdings prüft der Assistent ohnehin die Plausibilität der Angaben. Das Erstellen eines IPv6-CIDR deaktivieren wir.

Danach folgt der VPC-Name, zum Beispiel MyVPC.  Nun kann man zwei IP-Adress­bereiche für je ein öffentliches und ein privates Subnetz angeben. Für das öffentliche Subnetz über­schreiben wir den Default-Vorschlag 10.0.0.0/20 mit 192.168.0.0/24. Wir verwenden ein 24er Netz, weil wir 251 Host-Adressen im öffent­lichen Subnetz vorhalten möchten.

Dies erleichtert die Berechnung der nächsten freien Netzwerk­adresse. In der Praxis wird man eher kleinere öffentliche Subnetze (25, 26, 27) und eher größere private Subnetze (23, 21, 20) nutzen. Für das private Subnetz nehmen wir der einfacheren Berechnung wegen 192.168.1.0/24. In beiden Fällen wählen wir als Availability-Zone eu-central-1a.

NAT, DNS und Service-Endpoints

Im unteren Drittel des Dialoges kann man den Assistenten noch zum Erstellen von Service-Endpoints für S3 oder DynamoDB innerhalb der VPC, zum Anlegen von NAT-Routern und das Einschalten der DNS-Auflösung für die beiden Subnetze verwenden.

Ein NAT-Gateway oder eine NAT-Instanz kann man sich wie eine FritzBox im privaten Heimnetz vorstellen, die Arbeits­stationen hinter dem DSL-Router mittels SourceNAT (Masquerading) eine Verbindung ins Internet erlaubt. So sollen sich auch Server in privaten Subnetzen der VPC ggf. mit Updates aus dem Internet versorgen können, ohne von außen erreichbar zu sein (DestinationNAT). Letztes verhindert zuverlässig die Routing-Tabelle eines privaten Subnetzes, in der im Gegensatz zur Routing-Tabelle des öffentlichen Subnetzes keine Route zu einem Internet-Gateway existiert, sondern lediglich zum NAT-Gerät. AWS stellt zwei NAT-Varianten zur Verfügung, einmal das NAT-Gateway als verwalteten Dienst in AWS, das auch explizit nur SourceNAT erlaubt. Zum anderen gibt es ein NAT-Device auf Basis einer EC2-Linux-Instanz mit entsprechend vorbereiteter iptables-Kernel-Tabelle. Die Unterschiede erläutert AWS in der VPC-Dokumentation.

Festzuhalten bleibt, dass der VPC-Assistent nicht nur die angegebenen Subnetze, sondern auch die Routing-Tabellen, das Internet-Gateway und das NAT-Gateway oder die NAT-Instanz automatisch generiert. Möchte man das NAT-Gateway verwenden, muss man allerdings zuvor eine so genannte elastische IP-Adresse generieren. Da der Assistent explizit für das NAT-Szenario konzipiert ist, muss man sich für eine Variante entscheiden.

Die Geschichte mit den Service-Endpoints ist schnell erklärt. Dienste wie S3 oder DynamoDB, eine verwaltete NoSQL-Datenbank, werden normaler­weise ausschließlich über ihre REST-API über das Internet via HTTP/HTTPS angesprochen, auch wenn sich die Kommunikations­partner in der gleichen VPC befinden. Das ist etwa bei Web-Servern und Backend-Datenbanken oder Web-Servern mit ihrem Datenspeicher (S3) sehr häufig der Fall. Über das Internet gerouteter Traffic verursacht aber in jedem Fall Kosten und Latenzen, die sich vermeiden lassen, wenn man an dieser Stelle im Assistenten einen Service-Endpoint einrichtet.

Ferner kann man den Assistenten dazu verwenden, dass Hosts, die später in den generierten Subnetzen provisioniert werden, neben einer privaten oder öffentlichen IP-Adresse auch einen DNS-Namen von Route 53 erhalten.

Die Geschichte mit den Service-Endpoints ist schnell erklärt. Dienste wie S3 oder DynamoDB, eine verwaltete NoSQL-Datenbank, werden normaler­weise ausschließlich über ihre REST-API über das Internet via HTTP/HTTPS angesprochen, auch wenn sich die Kommunikations­partner in der gleichen VPC befinden. Das ist etwa bei Web-Servern und Backend-Datenbanken oder Web-Servern mit ihrem Datenspeicher (S3) sehr häufig der Fall.

Über das Internet gerouteter Traffic verursacht aber in jedem Fall Kosten und Latenzen, die sich vermeiden lassen, wenn man an dieser Stelle im Assistenten einen Service-Endpoint einrichtet. Ferner kann man den Assistenten dazu verwenden, dass Hosts, die später in den generierten Subnetzen provisioniert werden, neben einer privaten oder öffentlichen IP-Adresse auch einen DNS-Namen von Route 53 erhalten.