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)

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.

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. 

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

Netzwerkschnittstellen können nur an Instances in VPCs im selben Konto angehängt werden.

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.

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.

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.

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.

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.