Amazon Virtual Private Cloud (VPC): Funktionsweise und Limitierungen

Amazon Virtual Private Cloud (VPC) heißt das von den Amazon Web Services angebotene Software-Defined-Networking. Damit kann jeder Kunde einen logisch isolierten Bereich in der AWS-Cloud einrichten. Nutzer führen ihre AWS-Ressourcen dann in einem solchen selbst­definierten virtuellen Netzwerk aus.

Der Anwender hat mit VPC die vollständige Kontrolle über seine virtuelle Netzwerk­umgebung, etwa bei der Auswahl der gewünschten IP-Adress­bereiche, dem Erstellen von Subnetzen, der Konfiguration von Routing-Tabellen und dem Erstellen von Gateway-Geräten.

Zusätzlich kann er eine sichere Hardware-basierte Virtual Private Network (VPN)-Verbindung zwischen seinem Unter­nehmens­rechen­zentrum und der VPC einrichten und die AWS Cloud als Erweiterung seines internen Datacenters verwenden.

Service-Limits und Adressbereiche

Es gibt nur wenige Einschränkungen, die wie bei jedem AWS-Dienst in den jeweiligen Service-Limits beschrieben sind. Für VPC heißt das zum Beispiel, dass jeder Kunde kann pro Konto maximal 5 VPCs pro Region, 200 Subnetze pro VPC, 5 Internet-Gateways pro Region, 5 Virtual Private Gateways pro Region oder 200 Routing-Tabellen pro Region anlegen kann.

Außerdem gibt es einige Limitierungen hinsichtlich der Adress­bereiche, die stets in CIDR-Notation anzugeben sind. Zurzeit unterstützt AWS fünf IP-Adressbereiche, einen primären und vier sekundäre für IPv4.

Jeder dieser Bereiche kann eine Größe zwischen /28 (in CIDR-Notation) und /16 haben. Die IP-Adress­bereiche der VPC dürfen sich nicht mit jenen eventuell vorhandener Netzwerke überschneiden.

Dabei weist AWS der so genannten Default-VPC, die mit jeder neuen VPC stets automatisch erstellt wird, immer den CIDR-Bereich 172.31.0.0/16 zu, und unterteilt diesen standard­mäßig in drei öffentliche Standard­subnetze im CIDR-Bereich /20  mit 4091 (=4095-4) nutzbaren Adressen, wie folgende Abbildung der Subnets-Ansicht in der VPC-Konsole zeigt.

Subnetze konfigurieren

Die Bezeichnung in der Spalte Name ist ein sogenanntes Tag und wurde von uns hinzugefügt, um etwa bei mehreren hundert Subnetzen pro Konto nach diesen Netzen filtern zu können. Analog zeigt die VPC-Ansicht alle VPCs pro Konto (maximal 5), wobei die Default-VPC durch den Eintrag Yes in der Spalte Default-VPC zu erkennen ist.

Die gewünschte Region Frankfurt wurde zuvor oben rechts in der AWS-Management-Konsole ausgewählt. Subnetz­bereiche dürfen sich innerhalb des VPC-Adress­bereiches nicht überlappen.

Man kann zwar durchaus mehrere VPCs mit überlappenden IP-Adress­bereichen erstellen, allerdings würde ein solches Vorgehen eine Verbindung dieser VPCs zu einem gemeinsamen Firmen­netzwerk über das Hardware-VPN verhindern.

Jeder Nutzer kann die Größe seiner vorhandenen VPCs nachträglich erweitern, indem er der VPC einen der vier sekundären IPv4-IP-Bereiche hinzufügt. Die Mindestgröße eines Subnetzes beträgt /28, was  14 verwendbare IP-Adressen erlaubt. IPv4-Subnetze können nicht größer sein als die VPC, in der sie erstellt wurden.

Reservierte Adressen

Was die verwend­baren Host-Adressen betrifft, fallen bei AWS nicht wie üblich 2 Adressen weg (die erste für die Netzwerk­adresse und die letzte für die Broadcast-Adresse), sondern deren 5. Hier ein Beispiel für ein privates Subnetz mit der Adresse 10.10.0.0. In diesem Fall gilt:

• 10.10.0.0: Netzwerk-Adresse
• 10.10.0.1: Reserviert durch AWS für den VPC-Router
• 10.10.0.2: Reserviert durch AWS für das Mapping auf von Amazon bereitgestellten DNS
• 10.10.0.3: Reserviert von AWS für künftige Nutzung
• 10.10.0.255: Network Broadcast Adresse

Genau genommen gilt für Letztere, dass diese als reserviert betrachtet werden muss, da AWS Broadcasts in einer VPC nicht unterstützt. Mit diesen Kenntnissen versehen, ist das Erstellen eines kleinen Unter­nehmens­netzwerkes ganz einfach.

Das Verwenden der Default-VPC für produktive Zwecke ist nicht zu empfehlen. Die Default-VPC dient allein dem Zweck, dass beispiels­weise Nutzer ohne tiefergehende Kennt­nisse problemlos EC2-Maschinen erstellen können.

Das gilt vorzugs­weise für Web-Server, die öffentlich erreichbar sein sollen, oder als Default-Location für die ver­schiedenen vorlagen­basierten Automa­tisierungs-Workflows mit Beanstalk, CloudFormation oder OpsWorks.