Häufig gestellt Fragen zu Amazon VPC

Für das Erstellen und Verwenden der VPC selbst fallen keine zusätzlichen Gebühren an. Nutzungsgebühren für andere Amazon Web Services, einschließlich Amazon EC2, entsprechen den für diese Ressourcen veröffentlichten Tarifen, einschließlich Datenübertragungsgebühren. Wenn Sie Ihre VPC über die optionale Hardware-VPN-Verbindung mit Ihrem Unternehmensrechenzentrum verbinden, gelten die Preise pro VPN-Verbindungsstunde (die Zeit, in der die VPN-Verbindung den Status "Verfügbar" hat). Angefangene Stunden werden als volle Stunden abgerechnet. Über VPN-Verbindungen übertragene Daten werden zu den Standardtarifen für die AWS-Datenübertragung berechnet. Informationen zu den VPC-VPN-Preisen finden Sie im Abschnitt mit den Preisen auf der Produktseite von Amazon VPC.

Nutzungsgebühren für andere Amazon Web Services, zum Beispiel Amazon EC2, entsprechen den für diese Ressourcen veröffentlichten Tarifen. Für den Zugriff auf AWS-Services, z. B. auf Amazon S3, über den Internetrouter Ihres VPC fallen keine Datenübertragungsgebühren an.

Wenn Sie über Ihre VPN-Verbindung auf AWS-Ressourcen zugreifen, fallen Internetgebühren für die Übertragung von Daten an.

Folgende Amazon VPC-Verbindungen sind möglich:

• mit dem Internet (über ein Internet-Gateway)
• mit dem Rechenzentrum des Unternehmens mithilfe einer AWS Site-to-Site VPN-Verbindung (über das virtuelle private Gateway)
• mit dem Internet und mit dem Rechenzentrum Ihres Unternehmens (mithilfe eines Internet-Gateways und virtuellen privaten Gateways)
• Andere AWS-Services (über Internet-Gateway, NAT, Virtual Private Gateway oder VPC-Endpunkte)
• Andere Amazon VPCs (über VPC-Peering-Verbindungen)

Amazon VPC unterstützt die Einrichtung eines Internet-Gateways. Über diesen Router können Amazon EC2-Instanzen in der VPC direkt auf das Internet zugreifen. Sie können auch ein Egress-Only-Internet-Gateway verwenden, bei dem es sich um ein Stateful-Gateway handelt, das nur Egress-Zugang für IPv6-Verkehr vom VPC zum Internet bietet.

Nein. Ein Internet-Gateway ist horizontal skaliert, redundant und hochverfügbar. Es gibt dazu keine Bandbreiten-Begrenzungen.

Sie können öffentliche IP-Adressen, einschließlich Elastic IP-Adressen (EIPs) und IPv6-Global-Unique-Adressen (GUA), verwenden, um Instances in der VPC die Möglichkeit zu geben, sowohl direkt nach außen mit dem Internet zu kommunizieren als auch unaufgefordert eingehenden Datenverkehr aus dem Internet zu empfangen (z. B. Webserver). Sie können auch die Lösungen in der nächsten Frage verwenden.

Jede IP-Adresse, die einer Instance oder einem in einer VPC gehosteten Dienst zugewiesen wird und auf die über das Internet zugegriffen werden kann, gilt als öffentliche IP-Adresse. Nur öffentliche IPv4-Adressen, einschließlich Elastic-IP-Adressen (EIPs) und IPv6 GUA, können im Internet geroutet werden. Zu diesem Zweck müssen Sie die VPC zunächst mit dem Internet verbinden und dann die Routentabelle aktualisieren, damit sie vom / zum Internet erreichbar sind.

Instances ohne öffentliche IP-Adressen können auf eine von zwei Arten auf das Internet zugreifen:

1. Instances ohne öffentliche IP-Adressen können den Datenverkehr über ein NAT-Gateway oder eine NAT-Instance umleiten, um auf das Internet zuzugreifen. Diese Instances verwenden für den Internetzugriff die öffentliche IP-Adresse des NAT-Gateways oder der NAT-Instance. Das NAT-Gateway oder die NAT-Instance ermöglicht die ausgehende Kommunikation, aber nicht, dass Computer im Internet eine Verbindung zu Instances mit privaten Adressen herstellen.
2. Bei VPCs mit einer Hardware-VPN- oder Direct Connect-Verbindung können Instances ihren Internetdatenverkehr über das virtuelle private Gateway zu Ihrem vorhandenen Rechenzentrum leiten. Von hier kann sie über die vorhandenen Austrittspunkte und Netzwerksicherheits-/-überwachungsgeräte auf das Internet zugreifen.

Ja. Sie können die VPN-Software eines anderen Anbieters verwenden, um eine VPN-Verbindung zwischen Standorten oder eine Fernverbindung zu Ihrer VPC über das Internet-Gateway herzustellen.

Nein. Bei Verwendung des öffentlichen Adressraums verwendet die gesamte Kommunikation zwischen Instances und in AWS gehosteten Services das private Netzwerk von AWS. Pakete, die aus dem AWS-Netzwerk stammen und ein Ziel im AWS-Netzwerk haben, bleiben im globalen AWS-Netzwerk, mit Ausnahme des Datenverkehrs zu oder von AWS-China-Regionen.

Darüber hinaus werden alle Daten, die über das AWS Global Network fließen, das unsere Rechenzentren und Regionen verbindet, automatisch auf der physischen Ebene verschlüsselt, bevor sie unsere abgesicherten Standorte verlassen. Es gibt noch weitere Verschlüsselungsebenen wie zum Beispiel für den gesamten regionsübergreifenden VPC-Peering-Traffic und für sämtliche Customer- oder Service-to-Service-Transport-Layer-Security (TLS)-Verbindungen. 

Eine AWS Site-to-Site VPN-Verbindung verbindet Ihre VPC mit Ihrem Rechenzentrum. Amazon unterstützt IPsec (Internet Protocol Security)-VPN-Verbindungen. Zwischen Ihrer VPC und dem Rechenzentrum übertragene Daten werden über eine verschlüsselte VPN-Verbindung geleitet, wodurch die Vertraulichkeit und Integrität der übertragenen Daten gewährleistet wird. Zum Einrichten einer AWS Site-to-Site VPN-Verbindung wird kein Internetrouter benötigt.

Für den primären CIDR-Block können Sie jeden IPv4-Adressbereich, einschließlich RFC 1918 oder öffentlich routingfähige IP-Bereiche verwenden. Für den sekundären CIDR-Block gelten bestimmte Einschränkungen. Öffentliche routingfähige IP-Blöcke können nur über das virtuelle private Gateway erreicht werden. Der Zugriff über das Internet durch das Internet-Gateway ist nicht möglich. AWS verbreitet keine im Besitz von Kunden befindliche IP-Adressblöcke im Internet. Sie können bis zu 5 von Amazon bereitgestellte oder BYOIP-IPv6-GUA-CIDR-Blöcke für eine VPC bereitstellen, indem Sie die relevante API aufrufen oder die AWS-Managementkonsole verwenden.

Bei der Erstellung einer VPC weisen Sie einen einzelnen Classless Internet Domain Routing (CIDR)-IP-Adressbereich als primären CIDR-Block zu und können nach der Erstellung der VPC bis zu vier (4) sekundäre CIDR-Blöcke hinzufügen. Subnetze innerhalb einer VPC erhalten von Ihnen die Adressen aus diesen CIDR-Bereichen. Bitte beachten Sie, dass Sie zwar mehrere VPCs mit überlappenden IP-Adressbereichen erstellen können, dass dies jedoch eine Verbindung dieser VPCs zu einem gemeinsamen Heimnetzwerk über die Hardware-VPN-Verbindung verhindert. Wir empfehlen deshalb, nicht überlappende IP-Adressbereiche zu verwenden. Sie können Ihrer VPC bis zu 5 von Amazon bereitgestellte oder BYOIP-IPv6-CIDR-Blöcke zuweisen.

Standard-VPCs wird der CIDR-Bereich 172.31.0.0/16 zugewiesen. Standardsubnetzen in einer Standard-VPC werden im CIDR-Bereich der VPC Netzblöcke aus dem Bereich "/20" zugewiesen. 

Ja, Sie können Ihre öffentlichen IPv4-Adressen und IPv6-GUA-Adressen in die AWS VPC bringen und sie Subnetzen und EC2-Instances statisch zuweisen. Um auf diese Adressen über das Internet zuzugreifen, müssen Sie sie im Internet von Ihrem lokalen Netzwerk aus bekannt machen. Sie müssen auch den Verkehr über diese Adressen zwischen Ihrer VPC und dem lokalen Netzwerk über eine AWS DX- oder AWS VPN-Verbindung leiten. Sie können den Datenverkehr von Ihrer VPC über das virtuelle private Gateway weiterleiten. Ebenso können Sie den Datenverkehr von Ihrem lokalen Netzwerk über Ihre Router zurück zu Ihrer VPC leiten.

Derzeit unterstützt Amazon VPC fünf (5) IP-Adressbereiche, eine (1) primäre und vier (4) sekundäre für IPv4. Jeder dieser Bereiche kann eine Größe zwischen /28 (in CIDR-Notation) und /16 haben. Die IP-Adressbereiche Ihrer VPC dürfen sich nicht mit den IP-Adressbereichen Ihres vorhandenen Netzwerks überschneiden.

Für IPv6 hat die VPC eine feste Größe von /56 (in CIDR-Notation). Einer VPC können IPv4- und IPv6-CIDR-Blöcke zugeordnet sein.

Ja. Sie können Ihre vorhandene VPC erweitern, indem Sie dieser vier (4) sekundäre IPv4-IP-Bereiche (CIDRs) hinzufügen. Ihre VPC können Sie auch verkleinern, indem Sie die sekundären CIDR-Blöcke entfernen, die Sie Ihrer VPC hinzugefügt haben.   Ebenso können Sie Ihrer VPC bis zu fünf (5) zusätzliche IPv6-IP-Bereiche (CIDRs) hinzufügen.  Durch Löschen dieser zusätzlichen Bereiche können Sie Ihre VPC verkleinern.

Derzeit können Sie 200 Subnetze pro VPC erstellen. Falls Sie noch mehr einrichten möchten, übermitteln Sie einen Fall an das Supportcenter.

Die Mindestgröße eines Subnetzes beträgt /28 (oder 14 IP-Adressen) für IPv4. Subnetze können nicht größer sein, als die VPC, in der sie erstellt wurden.

Für IPv6 ist die Subnetzgröße fest (/64). Nur ein IPv6-CIDR-Block kann einem Subnetz zugeordnet werden.

Amazon reserviert die ersten vier (4) IP-Adressen sowie die letzte (1) IP-Adresse jedes Subnetzes zum Zwecke der IP-Netzwerkerstellung.

Wenn Sie eine Amazon-EC2-Instance innerhalb einer Subnetz starten, die nicht nur IPv6 ist, können Sie optional die primäre private IPv4-Adresse für die Instance festlegen. Wenn Sie keine primäre private IPv4-Adresse festlegen, weist AWS automatisch eine aus dem IPv4-Adressbereich zu, den Sie dem jeweiligen Subnetz zugeordnet haben. Sie können eine sekundäre private IPv4-Adresse zuweisen, wenn Sie eine Instance starten oder eine elastische Netzwerkschnittstelle erstellen. Dies ist auch nach dem Starten der Instance oder Erstellen der Schnittstelle jederzeit möglich. Wenn Sie eine Amazon-EC2-Instance in einem reinen IPv6-Subnetz starten, adressiert AWS sie automatisch über die von Amazon bereitgestellte IPv6-GUA-CIDR dieses Subnetzes. Die IPv6-GUA der Instance bleibt privat, es sei denn, Sie machen sie mit der richtigen Sicherheitsgruppe, NACL und Routentabellenkonfiguration für das Internet erreichbar.

Bei einer Instance, die in einem IPv4- oder Dual-Stack-Subnetz gestartet wird, bleibt die primäre private IPv4-Adresse für die gesamte Lebensdauer der Instance oder Schnittstelle erhalten. Bei sekundären privaten IPv4-Adressen kann jederzeit eine Zuweisung, Aufhebung der Zuweisung oder Verschiebung zwischen Schnittstellen oder Instances erfolgen. Für eine Instance, die in einem reinen IPv6-Subnetz gestartet wurde, kann die zugewiesene IPv6-GUA, die auch die erste IP-Adresse auf der primären Netzwerkschnittstelle der Instance ist, jederzeit geändert werden, indem eine neue IPv6-GUA zugeordnet und die vorhandene IPv6-GUA entfernt wird.

Nein. Eine IPv4-Adresse, die einer laufenden Instance zugewiesen wurde, kann erst dann wieder von einer anderen Instance verwendet werden, wenn sich die ursprüngliche laufende Instance in einem "beendeten" Zustand befindet. Allerdings kann die einer laufenden Instance zugewiesene IPv6-GUA von einer anderen Instance wieder verwendet werden, nachdem sie von der ersten Instance entfernt wurde.

Nein. Beim Starten einer Instance können Sie immer nur eine IP-Adresse für die Instance zuweisen.

Sie können der Instance eine beliebige IP-Adresse zuweisen, sofern diese:

• Teil des IP-Adressbereichs des zugeordneten Subnetzes ist
• nicht von Amazon für IP-Netzwerkzwecke reserviert ist
• derzeit nicht einer anderen Schnittstelle zugewiesen ist

Ja. Sie können einer elastischen Netzwerkschnittstelle oder EC2-Instance in Amazon VPC eine oder mehrere sekundäre private IP-Adressen zuweisen. Die Anzahl der sekundären privaten IP-Adressen, die Sie zuweisen können, hängt vom Instance-Typ ab. Im EC2-Benutzerhandbuch finden Sie weitere Informationen zur Anzahl der sekundären privaten IP-Adressen, die pro Instance-Typ zugewiesen werden können.

Ja, die Elastic IP-Adressen sind aber nur über das Internet (nicht über die VPN-Verbindung) erreichbar. Jede EIP-Adresse muss einer eindeutigen privaten IP-Adresse für die Instance zugeordnet sein. EIP-Adressen sollten nur für Instances in Subnetzen verwendet werden, die konfiguriert sind, ihren Datenverkehr direkt zum Internetrouter zu leiten. EIP können nicht für Instanzen in Subnetzes verwendet werden, die für die Verwendung eines NAT Gateways oder einer NAT-Instanz zum Zugriff auf das Internet konfiguriert sind. Dies gilt nur für IPv4. Amazon VPCs unterstützen aktuell keine EIPs für IPv6.

"Verwendung der eigenen IP (BYOIP)" bedeutet, dass Kunden ihren öffentlich routingfähigen IPv4- oder IPv6-Adressbereich ganz oder teilweise in AWS verlagern und für ihre AWS-Ressourcen verwenden können. Kunden verwenden weiterhin ihren IP-Bereich. Kunden können aus dem IPv4-Bereich Elastic IP-Adressen erstellen und in AWS verlagern, um sie für EC2-Instances, NAT-Gateways und Network Load Balancers zu verwenden. Kunden können einer VPC außerdem bis zu 5 CIDRs aus dem von ihnen in AWS eingebrachten IPv6-Bereich zuordnen. Kunden haben weiterhin Zugriff auf von Amazon bereitgestellte IP-Adressen und können wahlweise eigene, von Amazon bereitgestellte IP-Adressen oder beide verwenden.

Die Verwendung der eigenen IP-Adresse (Bring Your Own IP, BYOIP) in AWS kann folgende Gründe haben:
Ruf der IP-Adresse: Viele Kunden erachten den Ruf ihrer IP-Adressen als strategischen Vorteil und möchten diese daher in AWS für ihre Ressourcen verwenden. Kunden, die beispielsweise Services wie MTAs für ausgehende E-Mail-Nachrichten nutzen und IP-Adressen mit einem guten Ruf haben, können ihren IP-Bereich jetzt in AWS nutzen, um ihre hohe Erfolgsrate bei E-Mail-Sendungen aufrechtzuerhalten.

Kunden-Whitelisting: Mit BYOIP können Kunden auch Workloads, die auf einer Whitelist von IP-Adressen basieren, zu AWS verschieben, ohne die Whitelists mit neuen IP-Adressen neu erstellen zu müssen.

Hartcodierte Abhängigkeiten: Einige Kunden verwenden in Geräten hartcodierte IP-Adressen oder haben architektonische Abhängigkeiten zu ihren IP-Adressen erstellt. Die Verwendung der eigenen IP-Adresse ermöglicht diesen Kunden eine reibungslose Migration zu AWS.

Einhaltung von Verordnungen: Viele Kunden müssen aus regulatorischen Gründen bestimmte IP-Adressen verwenden. Auch sie können durch die Verwendung der eigenen IP-Adresse entsperrt werden.

Lokale IPv6-Netzwerkrichtlinie: Viele Kunden können nur ihre eigene IPv6 in ihrem lokalen Netzwerk verwenden. Diese Kunden werden durch die Verwendung der eigenen IP-Adresse entsperrt, da sie Ihrer VPC einen eigenen IPv6-Bereich zuweisen und ihr eigenes lokales Netzwerk per Internet oder Direct Connect verwenden können.

Wenn Sie eine BYOIP Elastic IP freigeben, kehrt diese in den BYOIP-IP-Pool zurück, aus dem sie zugewiesen wurde.

Details zur BYOIP-Verfügbarkeit finden Sie in unserer .

Ja. Sie können das BYOIP-Präfix mit einer beliebigen Anzahl von VPCs im selben Konto nutzen.

Sie können in Ihrem Konto bis zu fünf IP-Bereiche angeben.

Das spezifischste IPv4-Präfix, das Sie über BYOIP verwenden können, ist das ein IPv4-Präfix /24 und ein IPv6-Präfix /56. Wenn Sie Ihr IPv6-Präfix im Internet bewerben möchten, lautet das spezifischste IPv6-Präfix /48.

Sie können ARIN-, RIPE- und APNIC-registrierte Präfixe verwenden.

Neu zugewiesene oder zugeordnete Präfixe werden derzeit nicht akzeptiert. Die IP-Bereiche sollten direkt zugewiesen oder zugeordnet sein.

Ja. Sie können dies tun, indem Sie das BYOIP-Präfix aus der aktuellen Region entfernen und es dann für die neue Region bereitstellen.

Amazon VPC IP Address Manager (IPAM) ist ein verwalteter Service, der es Ihnen erleichtert, IP-Adressen für Ihre AWS-Workloads zu planen, zu verfolgen und zu überwachen. Mit IPAM ermöglicht können Sie die einfache Organisation von IP-Adressen basierend auf Ihren Routing- und Sicherheitsanforderungen und das Festlegen einfacher Geschäftsregeln zur Steuerung der IP-Adresszuweisungen gewährleisten. Sie können auch die IP-Adresszuweisung an VPCs automatisieren, sodass Sie keine kalkulationstabellenbasierten oder selbst erstellten Anwendungen für die IP-Adressplanung verwenden müssen, die schwer zu warten und zeitaufwendig sein können. IPAM bietet eine einheitliche Betriebsansicht, die als zentrale Informationsquelle verwendet werden kann. Dadurch können Sie routinemäßige IP-Adressverwaltungsaktivitäten wie das Verfolgen der IP-Nutzung, Fehlerbehebung und Prüfungen schnell und effiziente durchzuführen.

Sie sollten IPAM verwenden, um die Verwaltung der IP-Adresse effizienter zu gestalten. Bestehende Mechanismen, die die Kalkulationstabellen oder selbst entwickelte Tools nutzen, erfordern manuelle Arbeit und sind fehleranfällig. Beispielsweise können Sie mit IPAM Anwendungen schneller einführen, da Ihre Entwickler nicht mehr auf das Team für die zentrale Verwaltung der IP-Adresse warten müssen, um die IP-Adressen zuzuweisen. Sie können auch sich überschneidende IP-Adressen erkennen und sie beheben, bevor ein Netzwerkausfall auftritt. Außerdem können Sie Alarme für IPAM erstellen, die Ihnen Bescheid sagen, wenn die Adresspools fast ausgelastet sind oder wenn die Ressourcen mit den für ein Pool festgelegten Zuweisungsregeln nicht übereinstimmen. Dies sind einige der vielen Gründe, warum Sie IPAM verwenden sollten.

AWS IPAM bietet folgende Funktionen:
 

• Zuweisung von IP-Adressen für skalierbare Netzwerke: IPAM kann die Zuweisung von IP-Adressen bei Hunderten von Konten und VPCs basierend auf konfigurierbaren Geschäftsregeln automatisieren.
   
• Überwachung der IP-Nutzung in Ihrem gesamten Netzwerk: IPAM kann IP-Adressen überwachen und ermöglicht es Ihnen, Alarme zu erhalten, wenn IPAM potenzielle Probleme erkennt, wie verbrauchte IP-Adressen, die das Wachstum des Netzwerks zum Stillstand bringen, oder sich überlappende IP-Adressen, die zum fehlerhaften Routing führen können.
   
• Fehlerbehebung in Ihrem Netzwerk: IPAM kann Ihnen dabei helfen, schnell festzustellen, ob die Ursache der Probleme mit der Konnektivität in Fehlkonfigurationen oder in anderen Problemen liegt.
   
• Prüfung der IP-Adressen: IPAM behält automatisch Ihre IP-Adressüberwachungsdaten bei (bis zu maximal drei Jahre). Sie können diese historischen Daten verwenden, um retrospektive Analysen und Prüfungen für Ihre Netzwerk durchzuführen.

Die folgenden sind die wichtigsten Komponenten von IPAM:

• Ein Umfang ist der höchste Container innerhalb von IPAM. Ein IPAM enthält zwei Standard-Umfänge. Jeder Umfang stellt den IP-Raum für ein einzelnes Netzwerk dar. Der private Umfang ist für den gesamten privaten Raum vorgesehen. Der öffentliche Umfang ist für den gesamten öffentlichen Raum vorgesehen. Mit den Umfängen können Sie die IP-Adressen bei mehreren nicht verbundenen Netzwerken erneut verwenden, ohne eine Überschneidung oder einen Konflikt bei den IP-Adressen zu verursachen. Mit einem Umfang erstellen Sie IPAM-Pools.
   
• Ein Pool ist eine Sammlung von fortlaufenden IP-Adressbereichen (oder CIDRs). IPAM-Pools ermöglichen es Ihnen Ihre IP-Adressen gemäß Ihrer Routing- und Sicherheitsbedürfnissen zu organisieren. Sie können mehrere Pools in einem Pool der höchsten Stufe haben. Beispiel: Wenn Sie separate Routing- und Sicherheitsbedürfnisse für die Entwicklungs- und Produktionsanwendungen haben, können Sie einen Pool für jede einzelne erstellen. Sie weisen innerhalb IPAM-Pools CIDRs den AWS-Ressourcen zu.
• Eine Zuweisung ist eine CIDR-Zuweisung von einem IPAM-Pool zu einer anderen Ressource oder einem anderen IPAM-Pool. Wenn Sie eine VPC erstellen und ein IPAM-Pool für die CIDR der VPC wählen, wird die CIDR von der bereitgestellten CIDR zum IPAM-Pool zugewiesen. Sie können die Zuweisung mit IPAM überwachen und verwalten.

Ja. IPAM unterstützt sowohl BYOIPv4- als auch BYOIPv6-Adressen. BYOIP ist eine EC2-Funktion, die es Ihnen ermöglicht, die IP-Adressen in Ihrem Besitz zu AWS zu bringen. Mit IPAM können Sie ihre IP-Adressblöcke direkt bei Konten und Unternehmen bereitstellen und freigeben. Bestehende BYOIP-Kunden, die IPv4 verwenden, können ihre Pools zu IPAM migrieren, um das IP-Management zu vereinfachen.

Ja. Amazon bietet fortlaufende IPv6-Blöcke für die VPC-Zuweisung. Fortlaufende CIDR-Blöcke ermöglichen es Ihnen, CIDRs in einem einzigen Eintrag bei Netzwerk- und Sicherheitskonstrukten wie Zugriffsteuerungslisten, Routing-Tabellen, Sicherheitsgruppen und Firewalls zu aggregieren. Sie können Amazon-IPv6-CIDRs in einem Pool mit öffentlichem Umfang bereitstellen und sämtliche IPAM-Funktionen verwenden, um die IP-Nutzung zu verwalten und zu überwachen. Die Zuweisung dieser CIDR-Blöcke startet in Inkrementen von /52 und größere Blöcke stehen auf Anfrage zur Verfügung. Beispiel: Sie können einen /52-CIDR von Amazon zuweisen und IPAM zur Freigabe bei Konten verwenden und VPCs in diesen Konten zu erstellen.

Nein. Von Amazon bereitgestellte fortlaufende IPv6-Blöcke werden aktuell nur in IPAM unterstützt.

Sie können IPAM-Pools bei anderen Konten in Ihrem AWS-Unternehmen mit AWS Ressource Access Manager (RAM) freigeben. Sie können auch IPAM-Pools bei Konten freigeben, die nicht Teil Ihres primären AWS-Unternehmens sind. Beispiel: Diese Konten können ein anderes Geschäftsfeld in Ihrem Unternehmen oder einen verwalteten Service darstellen, der von einem Partner in Ihrem Namen in einem anderen AWS-Unternehmen gehostet wird.

Ja. Sie können für jedes Subnetz eine standardmäßige Route vorgeben. Die Standardroute kann den Datenverkehr aus der VPC über das Internet-Gateway, das virtuelle private Gateway oder das NAT Gateway leiten.

Sie können Amazon EC2-Sicherheitsgruppen verwenden, um Instances innerhalb einer Amazon VPC zu schützen. Mittels Sicherheitsgruppen in der VPC können Sie den eingehenden und ausgehenden Netzwerkverkehr bestimmen, der von bzw. zu den einzelnen Amazon EC2-Instances zugelassen ist. Datenverkehr von und zu Instanzen, der nicht explizit erlaubt ist, wird automatisch gesperrt.

Zusätzlich zu den Sicherheitsgruppen kann eingehender oder ausgehender Netzwerkverkehr der Subnetze über Netzwerk-Zugriffskontrolllisten (ACLs) zugelassen oder gesperrt werden.

Sicherheitsgruppen in einer VPC geben an, welcher Datenverkehr von bzw. zu einer Amazon EC2-Instance zugelassen ist. Netzwerk-ACLs operieren auf der Subnetzebene und werten den ein- und ausgehenden Subnetzverkehr aus. Mit Netzwerk-ACLs können Regeln eingerichtet werden, um Datenverkehr sowohl zuzulassen als auch zu sperren. Netzwerk-ACLs filtern den Datenverkehr zwischen Instances im selben Subnetz nicht. Darüber hinaus filtern Netzwerk-ACLs zustandslos, Sicherheitsgruppen filtern hingegen zustandsbehaftet.

Zustandsbehaftete Filterung überwacht den Ursprung einer Anforderung und kann automatisch eine Antwort auf die Anforderung zum ursprünglichen Rechner zulassen. Beispielsweise lässt eine zustandsbehaftete Filterung des eingehenden Datenverkehrs zum TCP-Port 80 zu, dass der Rückkehrverkehr, der normalerweise auf einem höher nummerierten Port (z. B. Ziel-TCP-Port 63, 912) erfolgt, durch den zustandsbehafteten Filter zwischen dem Client und dem Webserver geleitet wird. Die Filtereinrichtung unterhält eine Statustabelle, die die Ursprungs- und Ziel-Portnummern und IP-Adressen überwacht. Die Filtereinrichtung erfordert nur eine Regel: eingehenden Datenverkehr zum Webserver auf TCP-Port 80 zulassen.

Zustandslose Filterung untersucht hingegen nur die IP-Quell- oder -Zieladresse und den Ziel-Port. Ob der Datenverkehr durch eine neue Anforderung oder eine Antwort auf eine Anforderung erzeugt wird, wird nicht überprüft. Im vorangegangenen Beispiel müssten zwei Regeln auf der Filtereinrichtung implementiert werden: eine Regel, die eingehenden Datenverkehr zum Webserver auf dem TCP-Port 80 zulässt und eine zweite Regel, die ausgehenden Datenverkehr vom Webserver (TCP-Portbereich 49, 152 bis 65, 535) zulässt.

Ja. Wenn ein Internetrouter konfiguriert wurde, durchläuft Datenverkehr für Amazon EC2-Instances, die sich nicht in einer VPC befinden, den Internetrouter und wird dann durch das öffentliche AWS-Netzwerk zur EC2-Instance geleitet. Wenn kein Internet-Gateway konfiguriert wurde oder sich die Instance in einem Subnetz befindet, das den Datenverkehr durch das virtuelle private Gateway leitet, durchläuft der Datenverkehr die VPN-Verbindung aus dem Rechenzentrum kommend und gelangt erneut in das öffentliche AWS-Netzwerk.

Ja. Instances in einer Region können untereinander über die folgenden Verbindungen kommunizieren: Inter-Region VPC Peering, öffentliche IP-Adressen, NAT-Gateway, NAT-Instances, VPN- und Direct Connect-Verbindungen.

Ja. Es gibt zahlreiche Optionen für die Kommunikation Ihrer Ressourcen in einem VPC mit Amazon S3. Sie können VPC Endpoint for S3 verwenden, um sicherzustellen, dass der gesamte Datenverkehr im Amazon-Netzwerk bleibt, sodass Sie auf Ihren Amazon S3-Datenverkehr zusätzliche Zugriffsrichtlinien anwenden können. Mit einem Internet-Gateway können Sie den Internetzugriff aus Ihrer VPC ermöglichen. Instances in der VPC können zudem mit Amazon S3 kommunizieren. Sie können die Konfiguration auch so einrichten, dass der gesamte Datenverkehr nach Amazon S3 durch die Direct Connect- oder VPN-Verbindung, aus Ihrem Rechenzentrum herauskommt und dann in das öffentliche AWS-Netzwerk geht.

Ja. Sie können die Amazon-VPC-Datenverkehrsspiegelung und die Amazon-VPC-Flow-Logs verwenden, um den Netzwerkverkehr in Ihren Amazon-VPC zu überwachen.

VPC-Flow-Protokolle sind eine Funktion, mit der Sie Informationen zum IP-Datenverkehr zu und von Netzwerkschnittstellen in Ihrer VPC erfassen können. Die Flow-Protokolldaten können entweder in Amazon CloudWatch Logs oder Amazon S3 veröffentlicht werden. Sie können Ihre VPC-Flow-Protokolle überwachen, um einen betrieblichen Einblick in Ihre Netzwerkabhängigkeiten und Verkehrsmuster zu erhalten, Anomalien zu erkennen und Datenlecks zu verhindern oder Probleme mit der Netzwerkkonnektivität und Konfiguration zu beheben. Die angereicherten Metadaten in den Flow-Protokollen helfen Ihnen, zusätzliche Erkenntnisse darüber zu gewinnen, wer Ihre TCP-Verbindungen initiiert hat, sowie die tatsächliche Quelle und das Ziel auf Paketebene für den Verkehr, der durch Zwischenschichten wie das NAT-Gateway fließt. Sie können Ihre Flow-Protokolle auch archivieren, um Compliance-Anforderungen zu erfüllen. Weitere Informationen zu Amazon VPC Flow Logs entnehmen Sie bitte der Dokumentation.

Sie können ein Flow-Protokoll für eine VPC, ein Subnetz oder eine Netzwerkschnittstelle erstellen. Wenn Sie ein Flow-Protokoll für ein Subnetz oder eine VPC erstellen, wird jede Netzwerkschnittstelle in diesem Subnetz oder VPC überwacht. Beim Erstellen eines Flow-Protokoll-Abonnements können Sie die zu erfassenden Metadatenfelder, das maximale Aggregationsintervall und Ihr bevorzugtes Protokollziel auswählen. Sie können auch wählen, ob Sie den gesamten Verkehr oder nur den angenommenen oder abgelehnten Verkehr erfassen möchten. Sie können Tools wie CloudWatch Log Insights oder CloudWatch Contributor Insights verwenden, um Ihre VPC-Flow-Protokolle, die in CloudWatch Logs bereitgestellt werden, zu analysieren. Sie können Tools wie Amazon Athena oder AWS QuickSight verwenden, um Ihre VPC-Flow-Protokolle, die in Amazon S3 bereitgestellt werden, abzufragen und zu visualisieren. Sie können auch eine benutzerdefinierte Downstream-Anwendung zur Analyse Ihrer Protokolle erstellen oder Partnerlösungen wie Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic usw. verwenden.

Ja, Sie können ein VPC-Flow-Protokoll für einen Transit Gateway oder für eine einzelne Transit Gateway-Anlage erstellen. Mit dieser Funktion kann Transit Gateway detaillierte Informationen wie Quell-/Ziel-IPs, Ports, Protokolle, Datenverkehrszähler, Zeitstempel und verschiedene Metadaten für seine Netzwerk-Datenflüsse exportieren, die über den Transit Gateway laufen. Um mehr über die Unterstützung von Amazon-VPC-Flow-Protokollen für Transit Gateway zu erfahren, lesen Sie bitte die Dokumentation.

Flow-Protokolldaten werden außerhalb des Pfades Ihres Netzwerkverkehrs erfasst und haben daher keinen Einfluss auf den Netzwerkdurchsatz oder die Latenzzeit. Sie können Flow-Protokolle erstellen oder löschen, ohne eine Beeinträchtigung der Netzwerkleistung zu riskieren.

Die Gebühren für die Datenaufnahme und Archivierung von verkauften Protokollen fallen an, wenn Sie Flow-Protokolle in CloudWatch Logs oder in Amazon S3 veröffentlichen. Weitere Informationen und Beispiele finden Sie in der Preisübersicht zu Amazon CloudWatch. Sie können auch Gebühren aus der Veröffentlichung von Flow-Protokollen mit Hilfe von Kostenzuordnungskennzeichen verfolgen.

Mithilfe der Amazon VPC-Datenverkehrsspiegelung können Kunden den Netzwerkverkehr von und zu einer Amazon EC2-Instance auf einfache Weise replizieren, sowie ihn an bandexterne Sicherheits- und Überwachungs-Appliances für Anwendungsfälle wie Inhaltsprüfung, Bedrohungsüberwachung und Fehlerbehebung weiterleiten. Diese Appliances können auf einer einzelnen EC2-Instance oder einer Flotte von Instances hinter einem Network Load Balancer (NLB) mit einem User Datagram Protocol (UDP) Listener bereitgestellt werden.

Die Datenverkehrsspiegelung unterstützt die Erfassung von Netzwerkpaketen auf Elastic Network-Schnittstelle (ENI)-Ebene für EC2-Instances. In der Dokumentation zu Traffic Mirroring finden Sie die EC2-Instances, die Amazon VPC Traffic Mirroring unterstützen.

Kunden können entweder Open Source-Tools verwenden oder aus einer breiten Palette von Überwachungslösungen wählen, die auf dem AWS Marketplace verfügbar sind. Durch die Datenverkehrsspiegelung können Kunden replizierten Verkehr an jeden Sammler/Broker von Netzwerkpaketen oder an jedes Analysetool streamen, ohne dass sie herstellerspezifische Agenten installieren müssen.

Anhand von Amazon VPC Flow Logs können Kunden Netzwerk-Flow-Protokolle sammeln, speichern und analysieren. Die in Flow-Protokollen erfassten Informationen schließen Informationen zu zulässigem und verweigertem Datenverkehr, Quell- und Ziel-IP-Adressen, Ports, Protokollnummern, Paket- und Byte-Anzahl sowie einer Aktion (akzeptieren oder ablehnen) ein. Mit dieser Funktion können Sie Konnektivitäts- und Sicherheitsprobleme beheben und sicherstellen, dass die Netzwerkzugriffsregeln wie erwartet funktionieren.

Die Amazon VPC-Datenverkehrsspiegelung bietet einen tieferen Einblick in den Netzwerkverkehr, indem Sie den tatsächlichen Verkehrsinhalt einschließlich der Nutzlast analysieren können. Sie ist auf Anwendungsfälle ausgerichtet, in denen Sie beispielsweise die tatsächlichen Pakete analysieren müssen, um die Ursache eines Leistungsproblems zu ermitteln, einen ausgeklügelten Netzwerkangriff rückentwickeln müssen oder Insiderdelikte und gefährdete Workloads erkennen und stoppen müssen.

Amazon VPC ist derzeit in mehreren Availability Zones in allen Amazon-EC2-Regionen verfügbar.

Ja. 

Nein. Ein Subnetz muss sich innerhalb einer einzigen Availability Zone befinden.

Wenn Sie eine Amazon EC2-Instance starten, müssen Sie das Subnetz angeben, in dem die Instance gestartet werden soll. Die Instance wird in der Availability Zone gestartet, die dem angegebenen Subnetz zugeordnet ist.

Wenn Sie ein Subnetz erstellen, müssen Sie die Availability Zone angeben, in der das Subnetz platziert wird. Bei Verwendung des VPC-Assistenten können Sie die Availability Zone des Subnetzes im Bestätigungsbildschirm des Assistenten auswählen. Bei Verwendung der API oder Befehlszeilen-Schnittstelle können Sie die Availability Zone für das Subnetz angeben, während Sie das Subnetz erstellen. Wenn Sie keine Availability Zone angeben, wird standardmäßig die Option "No Preference" ausgewählt und das Subnetz wird in einer verfügbaren Availability Zone in der Region erstellt.

Wenn sich die Instances in Subnetzen verschiedener Availability Zones befinden, werden Ihnen 0,01 USD pro GB für die Datenübertragung in Rechnung gestellt.

Ja. DescribeInstances() gibt alle laufenden Amazon EC2-Instances aus. Durch einen Eintrag im Feld "Subnet" können Sie EC2-Classic-Instances von EC2-VPC-Instances unterscheiden. Wenn eine Subnetz-ID angegeben ist, befindet sich die Instance in einer VPC.

Ja. DescribeVolumes() gibt alle Ihre EBS-Datenträger aus.

Für Instances, die IPv4-Adressierung benötigen, können Sie eine beliebige Anzahl an Amazon-EC2-Instances in einer VPC ausführen, solange Ihre VPC entsprechend dimensioniert ist, damit jeder Instance eine IPv4-Adresse zugeordnet ist. Anfänglich gilt ein Grenzwert von gleichzeitig 20 Amazon-EC2-Instances mit einer maximalen VPC-Größe von /16 (65 536 IP-Adressen). Wenn Sie über diese Limits hinausgehen möchten, füllen Sie bitte das folgende Formular aus. Bei reinen IPv6-Instances bietet Ihnen die VPC-Größe von /56 die Möglichkeit, eine praktisch unbegrenzte Anzahl von Amazon-EC2-Instances zu starten.

Sie können AMIs in Amazon VPC verwenden, die in derselben Region wie Ihre VPC registriert sind. Beispielsweise können AMIs, die in us-east-1 registriert sind, mit einer VPC in us-east-1 verwendet werden. Weitere Informationen finden Sie in den häufig gestellten Fragen zu Regionen und Availability Zones von Amazon EC2.

Ja, Sie können Amazon EBS-Snapshots verwenden, wenn sich diese in derselben Region wie Ihre VPC befinden. Weitere Informationen finden Sie in den häufig gestellten Fragen zu Regionen und Availability Zones von Amazon EC2

Ja. Eine in einer VPC gestartete Instance, die eine von Amazon EBS unterstützte AMI verwendet, behält jedoch dieselbe IP-Adresse bei, wenn sie gestoppt und gestartet wird. Dies geschieht im Gegensatz zu anderen Instances, die außerhalb einer VPC gestartet werden und eine neue IP-Adresse erhalten. Die IP-Adressen von gestoppten Instanzen in einem Subnetz werden als nicht verfügbar behandelt.

Ja.

Ja. 

Ja. Cluster-Instances werden in Amazon VPC unterstützt, allerdings sind nicht alle Instance-Typen in allen Regionen und Availability Zones verfügbar.

Wenn Sie eine Instance starten, wird ihr ein Hostname zugewiesen. Es gibt zwei Optionen, einen IP-basierten Namen oder einen ressourcenbasierten Namen. Dieser Parameter ist beim Start der Instance konfigurierbar. Der IP-basierte Name verwendet eine Form der privaten IPv4-Adresse, während der ressourcenbasierte Name eine Form der Instance-ID verwendet.

Ja, Sie können den Hostnamen einer Instance von IP-basiert auf ressourcenbasiert und umgekehrt ändern, indem Sie die Instance stoppen und dann die ressourcenbasierten Benennungsoptionen ändern.

Ja, der Hostname der Instance kann als DNS-Hostname verwendet werden. Für Instances, die in einem reinen IPv4- oder Dual-Stack-Subnetz gestartet werden, wird der IP-basierte Name immer in die private IPv4-Adresse an der primären Netzwerkschnittstelle der Instance aufgelöst und dies kann nicht ausgeschaltet werden. Zusätzlich kann der ressourcenbasierte Name so konfiguriert werden, dass dieser entweder in die private IPv4-Adresse der primären Netzwerkschnittstelle oder in die erste IPv6-GUA der primären Netzwerkschnittstelle oder in beide aufgelöst wird. Bei Instances, die in einem reinen IPv6-Subnetz gestartet werden, wird der ressourcenbasierte Name so konfiguriert, dass er zur ersten IPv6-GUA auf der primären Netzwerkschnittstelle aufgelöst wird. 

Eine Standard-VPC ist ein logisch isoliertes virtuelles Netzwerk in der AWS-Cloud, das automatisch für Ihr AWS-Konto erstellt wird, wenn Sie erstmals Amazon EC2-Ressourcen bereitstellen. Wenn Sie eine Instance starten, ohne eine Subnetz-ID anzugeben, wird Ihre Instance in Ihrer Standard-VPC gestartet.

Wenn Sie Ressourcen in einer Standard-VPC in Betrieb nehmen, können Sie von den erweiterten Netzwerkfunktionen von Amazon VPC (EC2-VPC) und der Benutzerfreundlichkeit von Amazon EC2 (EC2-Classic) profitieren. Geboten werden Ihren Funktionen wie das Ändern der Mitgliedschaft von Sicherheitsgruppen bei laufendem Betrieb, die Filterung für ausgehenden Datenverkehr für Sicherheitsgruppen, mehrere IP-Adressen und mehrere Netzwerkschnittstellen, ohne explizit eine VPC erstellen und Instances in der VPC starten zu müssen.

Wenn Ihr AWS-Konto nach dem 18.03.2013 erstellt wurde, können Sie ggf. Ressourcen in einer Standard-VPC starten. Lesen Sie diese Ankündigung im Forum, um zu prüfen, in welchen Regionen das Standard-VPC-Feature unterstützt wird. Darüber hinaus können Konten, die vor den aufgeführten Terminen angelegt wurden, Standard-VPCs in allen für Standard-VPCs aktivierten Regionen nutzen, in denen Sie zuvor keine EC2-Instances gestartet oder Amazon Elastic Load Balancing-, Amazon RDS-, Amazon ElastiCache- oder Amazon Redshift-Ressourcen bereitgestellt haben.

Sie können über die AWS Management Console, AWS EC2 CLI oder Amazon EC2-API EC2-Instances und andere AWS-Ressourcen in einer Standard-VPC starten und verwalten. AWS erstellt für Sie automatisch eine Standard-VPC und ein Standard-Subnetz in allen Availability Zones der AWS-Region. Ihre Standard-VPC wird mit einem Internet-Gateway verbunden und Ihre Instances erhalten wie bei EC2-Classic automatisch öffentliche IP-Adressen.

Lesen Sie im EC2-Benutzerhandbuch den Abschnitt Unterschiede zwischen EC2-Classic und EC2-VPC.

Standard-VPCs sind mit dem Internet verbunden und alle in Standardsubnetzen gestarteten Instances in der Standard-VPC erhalten automatisch öffentliche IP-Adressen. Sie können Ihrer Standard-VPC nach Wunsch eine VPN-Verbindung hinzufügen.

Ja. Zum Starten einer Instance in Nicht-Standard-VPCs müssen Sie beim Starten der Instance eine Subnetz-ID angeben.

Ja. Für einen Start in Nicht-Standardsubnetzen können Sie das Ziel für Ihre Startvorgänge mithilfe der Konsole oder über die CLI-, API- oder SDK-Option "--subnet" angeben.

Sie können in jeder AWS-Region, für die das Attribut "Supported Platforms" auf "EC2-VPC" festgelegt ist, über eine Standard-VPC verfügen.

Ein Standardsubnetz wird in Ihrer Standard-VPC für jede Availability Zone erstellt.

Nein, derzeit nicht.

Nein, derzeit nicht.

Ja. Eine Standard-VPC kann gelöscht werden. Nach dem Löschen der Standard-VPC können Sie über die VPC-Konsole oder die CLI eine neue Standard-VPC erstellen. Dadurch entsteht für die Region eine neue Standard-VPC. Die gelöschte VPC wird dadurch nicht wiederhergestellt.

Ja, ein Standardsubnetz kann gelöscht werden. Nach dem Löschen können Sie mit der Befehlszeilenschnittstelle oder dem SDK ein neues Standardsubnetz in der Availability Zone erstellen. Dadurch wird ein neues Standardsubnetz in der angegebenen Availability Zone erstellt. Das gelöschte Subnetz wird dadurch nicht wiederhergestellt.

Die einfachste Möglichkeit, eine Standard-VPC zu erhalten, ist das Anlegen eines neuen Kontos in einer Region, die für Standard-VPCs aktiviert ist. Sie können auch ein vorhandenes Konto in einer Region nutzen, die Sie nicht zuvor verwendet haben, solange das Attribut "Supported Platforms" für dieses Konto in dieser Region auf "EC2-VPC" festgelegt ist.

Ja, wir können jedoch ein vorhandenes Konto nur dann für eine Standard-VPC aktivieren, wenn Sie für dieses Konto noch nicht über EC2-Classic-Ressourcen in der jeweiligen Region verfügen. Darüber hinaus müssen Sie alle nicht per VPC bereitgestellten Elastic Load Balancer-, Amazon RDS-, Amazon ElastiCache- und Amazon Redshift-Ressourcen in der jeweiligen Region kündigen. Nachdem Ihr Konto für eine Standard-VPC konfiguriert wurde, werden alle künftig gestarteten Ressourcen, so auch per Auto Scaling gestartete Instances, Ihrer Standard-VPC zugeordnet. Um eine Standard-VPC für Ihr bestehendes Konto anzufordern, navigieren Sie bitte zu Account and Billing -> Service: Account -> Category: Convert EC2 Classic to VPC und reichen Sie eine Anfrage ein. Wir werden Ihre Anfrage, Ihre bestehenden AWS-Services und Ihre EC2-Classic-Präsenz überprüfen und Sie durch die weiteren Schritte führen.

Wenn Ihr AWS-Konto über eine Standard-VPC verfügt, verwenden IAM-Konten, die Ihrem AWS-Konto zugeordnet sind, dieselbe Standard-VPC wie Ihr AWS-Konto.

EC2-Classic ist ein flaches Netzwerk, das wir zusammen mit EC2 im Sommer 2006 eingeführt haben. Mit EC2-Classic laufen Ihre Instanzen in einem einzigen, flachen Netzwerk, das Sie mit anderen Kunden teilen. Im Laufe der Zeit haben wir, inspiriert durch die sich entwickelnden Anforderungen unserer Kunden, im Jahr 2009 Amazon Virtual Private Cloud (VPC) eingeführt, um Ihnen die Ausführung von Instances in einer virtuellen privaten Cloud zu ermöglichen, die logisch von Ihrem AWS-Konto isoliert ist. Während die meisten unserer Kunden heute Amazon VPC nutzen, haben wir einige Kunden, die immer noch EC2-Classic verwenden.

Wir werden Amazon EC2-Classic am 15. August 2022 in den Ruhestand versetzen und Sie müssen alle EC2-Instanzen und andere AWS-Ressourcen, die auf EC2-Classic laufen, vor diesem Datum auf Amazon VPC migrieren. Im folgenden Abschnitt finden Sie weitere Informationen über die Ausmusterung der EC2-Klasse sowie Tools und Ressourcen, die Sie bei der Migration unterstützen.

Sie sind von dieser Änderung nur betroffen, wenn Sie EC2-Classic in Ihrem Konto in einer der AWS-Regionen aktiviert haben. Sie können die Konsole oder den Befehl describe-account-attributes verwenden, um zu überprüfen, ob Sie EC2-Classic für eine AWS-Region aktiviert haben. Weitere Details finden Sie in diesem Dokument.

Wenn Sie in einer Region keine aktiven AWS-Ressourcen auf EC2-Classic laufen haben, bitten wir Sie, EC2-Classic in Ihrem Konto für diese Region zu deaktivieren. Wenn Sie EC2-Classic in einer Region deaktivieren, können Sie dort eine Standard-VPC starten. Rufen Sie dazu das AWS Support Center unter console.aws.amazon.com/support auf, wählen Sie „Fall erstellen“ und dann „Konten- und Rechnungsunterstützung“; für „Typ“ wählen Sie „Konto“, für „Kategorie“ wählen Sie „Konvertieren von EC2-Classic zu VPC“. Geben Sie die weiteren erforderlichen Angaben ein und wählen Sie „Übertragen“.

Wir werden EC2-Classic automatisch am 30. Oktober 2021 für alle AWS-Regionen abschalten, in denen Sie seit dem 1. Januar 2021 keine AWS-Ressourcen (EC2-Instances, Amazon Relational Database, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks) auf EC2-Classic haben.

Wenn Sie hingegen AWS-Ressourcen auf EC2-Classic laufen haben, bitten wir Sie, deren Migration zu Amazon VPC so bald wie möglich zu planen. Nach dem 15. August 2022 können Sie keine Instanzen oder AWS-Services auf der EC2-Classic-Plattform mehr starten. Alle laufenden Arbeitslasten oder Services werden ab dem 16. August 2022 nach und nach den Zugriff auf alle AWS-Services auf EC2-Classic verlieren, wenn wir sie außer Betrieb nehmen.

Die Migrationsleitfäden für Ihre AWS-Ressourcen finden Sie in der nachfolgenden Frage.

Amazon VPC gibt Ihnen die vollständige Kontrolle über Ihre virtuelle Netzwerkumgebung auf AWS, logisch isoliert von Ihrem AWS-Konto. In der EC2-Classic-Umgebung teilen sich Ihre Workloads ein einziges flaches Netzwerk mit anderen Kunden. Die Amazon VPC-Umgebung bietet viele weitere Vorteile gegenüber der EC2-Classic-Umgebung, darunter die Möglichkeit, einen eigenen IP-Adressraum auszuwählen, öffentliche und private Subnetze zu konfigurieren sowie Routentabellen und Netzwerk-Gateways zu verwalten. Für alle derzeit in EC2-Classic verfügbaren Services und Instances sind vergleichbare Services in der Amazon VPC-Umgebung verfügbar. Amazon VPC bietet auch eine viel breitere und neuere Generation von Instanzen als EC2-Classic. Weitere Informationen zu Amazon VPC finden Sie unter diesem Link.

Um Sie bei der Migration Ihrer Ressourcen zu unterstützen, haben wir Playbooks veröffentlicht und Lösungen entwickelt, die Sie unten finden. Um zu migrieren, müssen Sie Ihre EC2-Classic-Ressourcen in Ihrer VPC neu erstellen. Zunächst können Sie dieses Skript verwenden, um alle in EC2-Classic bereitgestellten Ressourcen in allen Regionen eines Kontos zu identifizieren. Sie können dann den Migrationsleitfaden für die entsprechenden AWS-Ressourcen verwenden:

• Instances und Sicherheitsgruppen
• Classic Load Balancer
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift für die Migration von DC1-Clustern und für andere Knotentypen
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

Neben den oben genannten Migrationsleitfäden bieten wir auch eine hochautomatisierte Lift-and-Shift-Lösung (Rehosting) an, den AWS Application Migration Service (AWS MGN), der die Migration von Anwendungen vereinfacht, beschleunigt und die Kosten reduziert. Hier finden Sie relevante Ressourcen über AWS MGN:

• Erste Schritte mit AWS Application Migration Service. 
• AWS Application Migration Service - technisches Training auf Anfrage
• Dokumentation für einen tieferen Einblick in die Merkmale und Funktionen des AWS Application Migration Service
• Service-Architektiur und Netzwerk-Architektur Video

Für einfache Migrationen einzelner EC2-Instances von EC2-Classic zu VPC können Sie neben AWS MGN oder dem Migrationsleitfaden für Instances auch das Runbook „AWSSupport-MigrateEC2 ClassicToVPC“ aus „AWS Systems Manager > Automation“ verwenden. Dieses Runbook automatisiert die Schritte, die erforderlich sind, um eine Instanz von EC2-Classic nach VPC zu migrieren, indem es ein AMI der Instanz in EC2-Classic erstellt, eine neue Instanz aus dem AMI in VPC erstellt und optional die EC2-Classic-Instanz terminiert.

Wenn Sie Fragen oder Bedenken haben, können Sie sich über AWS Premium Support an das AWS-Support-Team wenden.

Hinweis: Wenn Sie AWS-Ressourcen auf EC2-Classic in mehreren AWS-Regionen betreiben, empfehlen wir Ihnen, EC2-Classic für jede dieser Regionen zu deaktivieren, sobald Sie alle Ihre Ressourcen auf VPC in diesen Regionen migriert haben.

Wir werden die folgenden beiden Maßnahmen vor dem 15. August 2022, dem Datum der Außerdienststellung, ergreifen:

• Wir werden am 30. Oktober 2021 keine reservierten Instanzen (RI) mit einer Laufzeit von 3 Jahren und keine RI mit einer Laufzeit von 1 Jahr für die EC2-Classic-Umgebung mehr ausstellen. RIs, die bereits in der EC2-Classic-Umgebung vorhanden sind, sind zu diesem Zeitpunkt nicht betroffen. RIs, die nach dem 15.8.2022 auslaufen, müssen so geändert werden, dass sie die Amazon-VPC-Umgebung für die verbleibende Laufzeit des Leasingvertrags nutzen. Wie Sie Ihre RIs ändern können, erfahren Sie in diesem Dokument.
• Am 15. August 2022 werden wir die Erstellung neuer Instances (Spot oder On-Demand) oder anderer AWS-Services in der EC2-Classic-Umgebung nicht mehr zulassen. Alle laufenden Arbeitslasten oder Services werden ab dem 16. August 2022 nach und nach den Zugriff auf alle AWS-Services auf EC2-Classic verlieren, wenn wir sie außer Betrieb nehmen.

Ja.

Netzwerkschnittstellen können nur mit Instances in derselben Availability Zone verknüpft werden.

Netzwerkschnittstellen können nur mit Instances verknüpft werden, die sich in der gleichen VPC wie die Schnittstelle befinden.

Ja. Dies ist jedoch kein optimaler Anwendungsfall für mehrere Schnittstellen. Weisen Sie stattdessen der Instance weitere private IP-Adressen zu, und ordnen Sie anschließend nach Bedarf den privaten IP-Adressen Elastic IP-Adressen zu.

Sie können die sekundären Schnittstellen (eth1-eth) einer EC2-Instance zuordnen bzw. sie von dieser trennen. Die Schnittstelle eth0 kann jedoch nicht getrennt werden.

Ja. Peering-Verbindungen können mit VPCs für unterschiedliche Regionen erstellt werden. Regionsübergreifendes VPC Peering ist global in allen Wirtschaftsregionen (außer China) verfügbar.

Ja, vorausgesetzt, der Besitzer des anderen VPC akzeptiert Ihre Peering-Verbindungsanforderung.

Für das Erstellen von VPC-Peering-Verbindungen fallen keine Kosten an, die Datenübertragung über Peering-Verbindungen wird jedoch berechnet. Informationen zu den Datentransferraten finden Sie im Abschnitt Datentransfer auf der Seite mit den Preise für Amazon EC2.

Nein. Für VPC-Peering-Verbindungen ist kein Internet-Gateway erforderlich.

Der Datenverkehr zwischen Instances in über Peering verbundenen VPCs bleibt privat und isoliert – ähnlich wie Datenverkehr zwischen zwei Instances in derselben VPC.

Nein. Beide Seiten der Peering-Verbindung können die Peering-Verbindung jederzeit beenden. Beenden einer Peering-Verbindung bedeutet, dass kein Datenverkehr mehr zwischen den VPCs fließt.

Nein. Transitive Peering-Beziehungen werden nicht unterstützt.

AWS verwendet die vorhandene Infrastruktur einer VPC zum Erstellen einer VPC-Peering-Verbindung. Es handelt sich weder um ein Gateway noch eine VPN-Verbindung und die Verbindung basiert nicht auf spezieller physischer Hardware. Es gibt keine einzelne Fehlerstelle für die Kommunikation und keinen Bandbreiten-Engpass.

Das regionenübergreifende VPC Peering basiert auf derselben horizontal skalierten, redundanten und hochverfügbaren Technologie, von der moderne VPCs profitieren. Der Traffic beim regionenübergreifenden VPC Peering wird über das Basisnetz von AWS geleitet, das über eine integrierte Redundanz und dynamische Bandbreitenzuweisung verfügt. Es gibt für die Kommunikation keinen Single Point of Failure.

Wenn eine regionenübergreifende Peering-Verbindung ausfällt, wird der Traffic nicht über das Internet geleitet.

Die Bandbreite zwischen Instances in über Peering verbundenen VPCs unterscheidet sich nicht von der Bandbreite zwischen Instances in derselben VPC. Hinweis: Eine Platzierungsgruppe kann mehrere über Peering verbundene VPCs umfassen. Sie erhalten jedoch nicht die vollständige Bisektionsbandbreite zwischen Instances in über Peering verbundenen VPCs. Lesen Sie mehr über Platzierungsgruppen.

Der Traffic ist mittels moderner AEAD-Algorithmen (Authenticated Encryption with Associated Data) verschlüsselt. Die Schlüsselvereinbarung und die Schlüsselverwaltung übernimmt AWS.

Standardmäßig wird eine Abfrage für den öffentlichen Hostnamen einer Instance in einer gekoppelten VPC in eine öffentliche IP-Adresse aufgelöst. Das private DNS Route 53 kann beim regionenübergreifenden VPC Peering zur Auflösung in eine private IP-Adresse verwendet werden.

Nein. Verweise für Sicherheitsgruppen können bei regionenübergreifenden VPC Peering-Verbindungen nicht angebracht werden.

Ja. Das regionenübergreifende VPC Peering unterstützt IPv6.

Nein. Regionenübergreifendes VPC-Peering kann nicht mit EC2-ClassicLink verwendet werden.

Amazon Virtual Private Cloud (VPC) ClassicLink ermöglicht EC2-Instances auf der EC2-Classic-Plattform die Kommunikation mit Instances in einer VPC unter Verwendung von privaten IP-Adressen. Um ClassicLink zu verwenden, aktivieren Sie es für eine VPC in Ihrem Konto und verknüpfen Sie eine Sicherheitsgruppe aus dieser VPC mit einer Instance in EC2-Classic. Alle Regeln Ihrer VPC-Sicherheitsgruppe werden auf Kommunikationen zwischen Instanzen in EC2-Classic und Instanzen in der VPC angewendet. 

Es entstehen keine zusätzlichen Kosten für die Nutzung von ClassicLink, allerdings fallen Datenübertragungskosten zwischen den Availability Zones an. Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für EC2.

Um ClassicLink nutzen zu können, müssen Sie zunächst mindestens eine VPC in Ihrem Konto für ClassicLink aktivieren. Dann verknüpfen Sie eine Sicherheitsgruppe aus der VPC mit der gewünschten EC2-Classic-Instance. Die EC2-Classic-Instanz ist jetzt mit der VPC verknüpft und ist ein Mitglied der ausgewählten Sicherheitsgruppe in der VPC. Ihre EC2-Classic-Instanz kann nicht mit mehr als einer VPC gleichzeitig verknüpft werden.

Die EC2-Classic-Instance wird kein Mitglied der VPC. Sie wird ein Mitglied der VPC-Sicherheitsgruppe, die mit der Instance verknüpft war. Alle Regeln und Referenzen zur VPC-Sicherheitsgruppe werden auf Kommunikationen zwischen Instanzen in EC2-Classic und Ressourcen in der VPC angewendet.

Der öffentliche EC2-DNS-Hostname wird nicht in die private IP-Adresse der EC2-VPC-Instance aufgelöst, wenn eine Abfrage von einer EC2-Classic-Instance erfolgt, und umgekehrt.

Ja. ClassicLink kann nicht für eine VPC aktiviert werden, die ein Classless Inter-Domain Routing (CIDR) im Bereich 10.0.0.0/8 hat, mit Ausnahme von 10.0.0.0/16 und 10.1.0.0/16. Zusätzlich kann ClassicLink für eine VPC, die einen Routing-Tabellen-Eintrag hat, der auf den 10.0.0.0/8 CIDR-Raum zeigt, nur für das Ziel "local" aktiviert werden.

Der Datenverkehr von einer EC2-Classic-Instance kann nur zu privaten IP-Adressen in der VPC geleitet werden. Er wird nicht an Ziele außerhalb der VPC geleitet, einschließlich Internet-Gateway, virtuelles privates Gateway oder Peer-VPC-Ziele.

ClassicLink ändert die Zugriffskontrolle nicht, die für eine EC2-Classic-Instanz durch ihre bestehenden Sicherheitsgruppen aus der EC2-Classic-Plattform definiert ist.

Die ClassicLink-Verbindung bleibt über Stopp-/Start-Zyklen der EC2-Classic-Instance nicht erhalten. Die EC2-Classic-Instance muss mit einer VPC verknüpft werden, nachdem sie gestoppt und gestartet wurde. Die ClassicLink-Verbindung bleibt hingegen über Neustartzyklen der Instanz erhalten.

ClassicLink erlaubt den EC2-Classic-Sicherheitsgruppenregeln nicht das Referenzieren von VPC-Sicherheitsgruppen oder umgekehrt.

Mit AWS PrivateLink können Kunden Services, die auf AWS gehostet werden, auf hochverfügbare und skalierbare Weise aufrufen und dabei sicherstellen, dass der Netzwerkdatenverkehr ausschließlich über das AWS-Netzwerk abgewickelt wird. Auf diese Weise können Servicebenutzer privat ohne öffentliche IPs über ihre Amazon Virtual Private Cloud (VPC) oder ihr eigenes Rechenzentrum auf Services zugreifen, die durch PrivateLink unterstützt werden, ohne den Datenverkehr durch das Internet zu leiten. Serviceeigentümer können Ihre Network Load Balancer bei PrivateLink-Services registrieren und die Services anderen AWS-Kunden zur Verfügung stellen.

Als Servicebenutzer müssen Sie VPC-Schnittstellenendpunkte für Services erstellen, die durch PrivateLink unterstützt werden. Diese Service-Endpunkte erscheinen dann als Elastic Network-Schnittstellen (Elastic Network Interfaces – ENIs) mit privaten IPs in Ihren VPCs. Nach der Erstellung dieser Endpunkte wird jeder Datenverkehr an diese IP-Adressen privat an die entsprechenden AWS-Services geleitet.

Als Serviceeigentümer können Sie Ihren Service bei AWS PrivateLink registrieren, indem Sie einen Network Load Balancer (NLB) vor Ihren Service schalten und einen PrivateLink-Service erstellen, den Sie beim NLB registrieren. Ihre Kunden werden dann dazu in der Lage sein, Endpunkte in Ihrer VPC zu erstellen, um sich mit Ihrem Service zu verbinden, nachdem Sie ihre Konten und IAM-Rollen auf eine Positivliste gesetzt haben.

Die folgenden AWS-Services unterstützen diese Funktion: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager, Amazon SNS und AWS DataSync. Viele SaaS-Lösungen unterstützen diese Funktion ebenfalls. Besuchen Sie den AWS Marketplace, um mehr SaaS-Produkte zu finden, die von AWS PrivateLink unterstützt werden.

Ja. Die Anwendung in Ihren Räumlichkeiten kann sich über AWS Direct Connect mit den Service-Endpunkten in der Amazon VPC verbinden. Die Service-Endpunkte leiten den Datenverkehr automatisch an durch AWS PrivateLink bereitgestellte AWS-Services.

Ja. Sie können die AWS Management Console nutzen, um Amazon VPC-Objekte wie VPCs, Subnetze, Routing-Tabellen, Internetroutern und IPSec-VPN-Verbindungen zu verwalten. Darüber hinaus können Sie mithilfe eines benutzerfreundlichen Assistenten eine VPC herstellen.

Weitere Informationen zu VPC-Limits finden Sie im Amazon-VPC-Benutzerhandbuch.

Ja. Klicken Sie hier, um weitere Informationen über den AWS Support zu erhalten.

ElasticFox wird offiziell nicht mehr für die Verwaltung Ihrer Amazon VPC unterstützt. Amazon VPC-Unterstützung ist über AWS APIs, Befehlszeilen-Tools und die AWS Management Console sowie verschiedene Drittpartei-Dienstprogramme verfügbar.