Update: Ende Dezember 2015 AWS kündigte ein neues Feature, einen Managed NAT - Gateway für VPC . Dieser optionale Dienst bietet einen alternativen Mechanismus für VPC-Instanzen in einem privaten Subnetz, um auf das Internet zuzugreifen. Bisher war die übliche Lösung eine EC2-Instanz in einem öffentlichen Subnetz innerhalb der VPC, die als "NAT-Instanz" fungiert und die Übersetzung von Netzwerkadressen ermöglicht. technisch port Address Translation) für Fälle , in anderen, privaten Subnetzen, so dass diese Maschinen die NAT - Instanz öffentliche IP - Adresse für ihren Outbound - Internetzugang nutzen.
Der neue verwaltete NAT-Dienst ändert die Anwendbarkeit der folgenden Informationen nicht grundlegend. Diese Option wird jedoch im folgenden Inhalt nicht behandelt. Eine NAT-Instanz kann weiterhin wie beschrieben verwendet werden, oder stattdessen kann der Managed NAT Gateway-Dienst bereitgestellt werden. Eine erweiterte Version dieser Antwort, die weitere Informationen zu NAT Gateway und dessen Vergleich mit einer NAT-Instanz enthält, wird in Kürze verfügbar sein, da beide für das Paradigma des privaten / öffentlichen Subnetzes in VPC relevant sind.
Beachten Sie, dass das Internet-Gateway und das NAT-Gateway zwei verschiedene Funktionen sind. Alle VPC-Konfigurationen mit Internetzugang verfügen über ein virtuelles Internet Gateway-Objekt.
Um die Unterscheidung zwischen "privaten" und "öffentlichen" Subnetzen in Amazon VPC zu verstehen, müssen Sie wissen, wie IP-Routing und NAT (Network Address Translation) im Allgemeinen funktionieren und wie sie speziell in VPC implementiert sind.
Die Kernunterscheidung zwischen einem öffentlichen und einem privaten Subnetz in VPC wird durch die Standardroute dieses Subnetzes in den VPC-Routing-Tabellen definiert.
Diese Konfiguration bestimmt wiederum die Gültigkeit der Verwendung oder Nichtverwendung öffentlicher IP-Adressen für Instanzen in diesem bestimmten Subnetz.
Jedes Subnetz hat genau eine Standardroute, die nur eines von zwei Dingen sein kann:
- das "Internet Gateway" -Objekt der VPC im Fall eines "öffentlichen" Subnetzes oder
- ein NAT-Gerät - das heißt, entweder ein NAT-Gateway oder eine EC2-Instanz, die im Fall eines "privaten" Subnetzes die Rolle "NAT-Instanz" ausführt.
Der Internet - Gateway führt keine Netzwerkadressübersetzung für Instanzen ohne öffentliche IP - Adressen so eine Instanz ohne eine öffentliche IP - Adresse kann keine Verbindung nach außen an dem Internet - Dinge wie Software - Updates herunterladen oder andere AWS - Ressourcen wie S3 Zugriff auf 1 und SQS - Wenn die Standardroute in seinem VPC-Subnetz das Internet Gateway-Objekt ist. Wenn Sie also eine Instanz in einem "öffentlichen" Subnetz sind, benötigen Sie eine öffentliche IP-Adresse, um eine erhebliche Anzahl von Aufgaben ausführen zu können, die Server normalerweise ausführen müssen.
Für Instanzen mit nur einer privaten IP-Adresse gibt es eine alternative Möglichkeit für den ausgehenden Zugriff auf das Internet. Hier kommen Network Address Translation² und eine NAT-Instanz ins Spiel.
Die Computer in einem privaten Subnetz können auf das Internet zugreifen, da die Standardroute in einem privaten Subnetz nicht das VPC-Objekt "Internet Gateway" ist, sondern eine als NAT-Instanz konfigurierte EC2-Instanz.
Eine NAT-Instanz ist eine Instanz in einem öffentlichen Subnetz mit einer öffentlichen IP und einer bestimmten Konfiguration. Es gibt AMIs, die dafür vorgefertigt sind, oder Sie können Ihre eigenen erstellen.
Wenn die privat adressierten Computer Datenverkehr nach außen senden, wird der Datenverkehr per VPC an die NAT-Instanz gesendet, die die Quell-IP-Adresse des Pakets (die private IP-Adresse des privaten Computers) durch ihre eigene öffentliche IP-Adresse ersetzt und den Datenverkehr sendet aus dem Internet, akzeptiert die Antwortpakete und leitet sie an die private Adresse des Ursprungscomputers zurück. (Möglicherweise wird auch der Quellport neu geschrieben, und in jedem Fall werden die Zuordnungen gespeichert, damit bekannt ist, auf welchem internen Computer die Antwortpakete empfangen werden sollen.) Eine NAT-Instanz lässt keinen "unerwarteten" eingehenden Datenverkehr zu den privaten Instanzen gelangen, es sei denn, sie wurde speziell dafür konfiguriert.
Wenn Sie also von einem privaten Subnetz aus auf eine externe Internetressource zugreifen, durchläuft der Datenverkehr die NAT-Instanz und scheint dem Ziel von der öffentlichen IP-Adresse der NAT-Instanz zu stammen. Der Antwortdatenverkehr wird also an die NAT-Instanz zurückgegeben. Weder die der NAT-Instanz zugewiesene Sicherheitsgruppe noch die der privaten Instanz zugewiesene Sicherheitsgruppe müssen so konfiguriert werden, dass dieser Antwortverkehr "zugelassen" wird, da Sicherheitsgruppen statusbehaftet sind. Sie erkennen, dass der Antwortverkehr mit internen Sitzungen korreliert, sodass er automatisch zulässig ist. Unerwarteter Datenverkehr wird natürlich abgelehnt, es sei denn, die Sicherheitsgruppe ist so konfiguriert, dass er dies zulässt.
Im Gegensatz zum herkömmlichen IP-Routing, bei dem sich Ihr Standard-Gateway in demselben Subnetz befindet, funktioniert es in VPC anders: Die NAT-Instanz für ein bestimmtes privates Subnetz befindet sich immer in einem anderen Subnetz, und dieses andere Subnetz ist immer ein öffentliches Subnetz, weil Die NAT-Instanz muss über eine öffentliche externe IP verfügen, und ihr Standardgateway muss das VPC-Objekt "Internet Gateway" sein.
Ebenso ... können Sie keine Instanz mit einer öffentlichen IP in einem privaten Subnetz bereitstellen. Es funktioniert nicht, da die Standardroute in einem privaten Subnetz (per Definition) eine NAT-Instanz (die NAT für den Datenverkehr ausführt) und nicht das Internet Gateway-Objekt (das dies nicht tut) ist. Eingehender Datenverkehr aus dem Internet würde die öffentliche IP der Instanz treffen, aber die Antworten würden versuchen, durch die NAT-Instanz nach außen zu leiten, wodurch entweder der Datenverkehr unterbrochen würde (da er sich aus Antworten auf Verbindungen zusammensetzt, die ihm nicht bekannt sind) würde als ungültig angesehen werden) oder würde den Antwortverkehr neu schreiben, um seine eigene öffentliche IP-Adresse zu verwenden, was nicht funktionieren würde, da der externe Ursprung keine Antworten akzeptieren würde, die von einer anderen IP-Adresse stammen als der, mit der sie die Kommunikation initiieren wollten .
Im Wesentlichen geht es bei den Bezeichnungen "privat" und "öffentlich" also nicht wirklich um Zugänglichkeit oder Unzugänglichkeit aus dem Internet. Hierbei handelt es sich um die Arten von Adressen, die den Instanzen in diesem Subnetz zugewiesen werden. Dies ist relevant, da diese IP-Adressen für Internetinteraktionen übersetzt oder nicht übersetzt werden müssen.
Da VPC implizite Routen von allen VPC-Subnetzen zu allen anderen VPC-Subnetzen hat, spielt die Standardroute im internen VPC-Verkehr keine Rolle. Instanzen mit privaten IP-Adressen stellen eine Verbindung zu anderen privaten IP-Adressen in der VPC "von" ihrer privaten IP-Adresse her her, nicht "von" ihrer öffentlichen IP-Adresse (falls vorhanden) ... solange die Zieladresse eine andere private Adresse ist innerhalb der VPC.
Wenn Ihre Instanzen mit privaten IP-Adressen unter keinen Umständen ausgehenden Internetverkehr erzeugen müssen, können sie technisch in einem "öffentlichen" Subnetz bereitgestellt werden und sind über das Internet immer noch nicht zugänglich ... aber unter einer solchen Konfiguration Es ist für sie unmöglich, ausgehenden Datenverkehr zum Internet zu generieren, der wiederum Verbindungen zu anderen AWS-Infrastrukturdiensten wie S3 1 oder SQS umfasst.
1. Insbesondere in Bezug auf S3 ist die Aussage, dass ein Internetzugang immer erforderlich ist, eine übermäßige Vereinfachung, die im Laufe der Zeit wahrscheinlich an Umfang zunehmen und sich auf andere AWS-Services ausbreiten wird, da die Funktionen von VPC weiter wachsen und sich weiterentwickeln. Es gibt ein relativ neues Konzept, das als VPC-Endpunkt bezeichnet wirdAuf diese Weise können Ihre Instanzen, einschließlich solcher mit nur privaten IP-Adressen, direkt von ausgewählten Subnetzen innerhalb der VPC auf S3 zugreifen, ohne "das Internet" zu berühren und ohne eine NAT-Instanz oder ein NAT-Gateway zu verwenden. Dies erfordert jedoch eine zusätzliche Konfiguration Nur verwendbar, um auf Buckets innerhalb derselben AWS-Region wie Ihre VPC zuzugreifen. Standardmäßig ist S3 - derzeit der einzige Dienst, der die Möglichkeit zum Erstellen von VPC-Endpunkten bietet - nur über das Internet von VPC aus zugänglich. Wenn Sie einen VPC-Endpunkt erstellen, wird eine Präfixliste erstellt (pl-xxxxxxxx ) ist, den Sie in Ihren VPC-Routentabellen verwenden können, um Datenverkehr, der für diesen bestimmten AWS-Dienst gebunden ist, über das virtuelle "VPC-Endpunkt" -Objekt direkt an den Dienst zu senden. Es löst auch das Problem, den ausgehenden Zugriff auf S3 für eine bestimmte Instanz einzuschränken, da die Präfixliste in ausgehenden Sicherheitsgruppen anstelle einer Ziel-IP-Adresse oder eines Zielblockes verwendet werden kann - und ein S3-VPC-Endpunkt zusätzlichen Richtlinienanweisungen unterliegen kann Einschränkung des Eimerzugangs von innen nach Wunsch.
2. Wie in der Dokumentation erwähnt, wird hier tatsächlich die Übersetzung von Port- und Netzwerkadressen erörtert. Es ist üblich, wenn auch technisch etwas ungenau, die kombinierte Operation als "NAT" zu bezeichnen. Dies ähnelt in gewisser Weise der Art und Weise, wie viele von uns "SSL" sagen, wenn wir tatsächlich "TLS" meinen. Wir wissen, wovon wir sprechen, aber wir verwenden nicht das richtigste Wort, um es zu beschreiben. "Hinweis Wir verwenden den Begriff NAT in dieser Dokumentation, um der gängigen IT-Praxis zu folgen, obwohl die eigentliche Rolle eines NAT-Geräts sowohl die Adressübersetzung als auch die Portadressübersetzung (PAT) ist."