Überspringen zum Hauptinhalt

Häufig gestellte Fragen zu Amazon VPC

Themen der Seite

Allgemeine Fragen

Alles öffnen

Amazon VPC ermöglicht die Bereitstellung eines logisch isolierten Bereichs der Amazon Web Services (AWS)-Cloud, in dem Sie AWS-Ressourcen in einem von Ihnen definierten virtuellen Netzwerk ausführen können. Sie haben die vollständige Kontrolle über Ihre virtuelle Netzwerkumgebung, u. a. bei der Auswahl Ihrer eigenen IP-Adressbereiche, dem Erstellen von Subnetzen und der Konfiguration von Routing-Tabellen und Netzwerk-Gateways. Darüber hinaus können Sie eine sichere hardwarebasierte Virtual Private Network(VPN)-Verbindung zwischen Ihrem Unternehmensrechenzentrum und Ihrer VPC einrichten und die AWS Cloud als Erweiterung Ihres Unternehmensrechenzentrums einsetzen.

Die Netzwerkkonfiguration für Ihre Amazon VPC kann auf einfache Weise angepasst werden. Sie können beispielsweise ein öffentlich zugängliches Subnetz für Ihre Webserver einrichten, das Zugriff auf das Internet hat, und Ihre Backend-Systeme, wie Datenbanken oder Anwendungsserver in einem privaten Subnetz ohne Internetzugang betreiben. Sie können mehrere Sicherheitsebenen einrichten, darunter Sicherheitsgruppen und Netzwerk-Zugriffskontrolllisten, die den Zugriff auf Amazon-EC2-Instances in den einzelnen Subnetzen steuern.

Amazon VPC besteht aus verschiedenen Objekten, die Kunden mit einem bestehenden Netzwerk bereits bekannt sind:

  • Virtual Private Cloud: Ein logisch isoliertes virtuelles Netzwerk in der AWS Cloud. Sie definieren einen IP-Adressraum für eine VPC aus von Ihnen ausgewählten Bereichen.
  • Subnetz: Ein Segment eines VPC-IP-Adressbereichs, in dem Sie Gruppen von isolierten Ressourcen ablegen können.
  • Internet-Gateway: Die Amazon-VPC-Seite einer Verbindung mit dem öffentlichen Internet.
  • NAT-Gateway: Ein verwalteter Service mit hoher Verfügbarkeit für die Network Address Translation (NAT) für Ihre Ressourcen in einem privaten Subnetz für den Zugang zum Internet.
  • Virtuelles privates Gateway: Die Amazon-VPC-Seite einer VPN-Verbindung.
  • Peering-Verbindung: Eine Peering-Verbindung ermöglicht Ihnen, Datenverkehr zwischen zwei über Peering verbundenen VPCs über private IP-Adressen zu leiten.
  • VPC-Endpunkte: Ermöglichen eine private Verbindung zu Services, die in AWS gehostet werden, über Ihre VPC, ohne dass Sie ein Internet-Gateway, ein VPN, Network Address Translation (NAT)-Geräte oder Firewall-Proxys verwenden müssen.
  • Egress-Only-Internet-Gateway: Ein zustandsbehaftetes Gateway, das nur ausgehenden Zugriff für IPv6-Datenverkehr von der VPC zum Internet bietet.

Amazon VPC ermöglicht Ihnen den Aufbau eines virtuellen Netzwerks in der AWS-Cloud, ohne dass VPNs, Hardwaregeräte oder physische Rechenzentren erforderlich sind. Sie können eine eigene Netzwerkumgebung erstellen und kontrollieren, wie der Zugriff auf Ihr Netzwerk und die in ihm enthaltenen Amazon EC2-Ressourcen erfolgt. Sie können auch die erweiterten Sicherheitsoptionen in Amazon VPC nutzen, um Zugriffe auf und von Amazon-EC2-Instances im virtuellen Netzwerk fein abzustufen.

Ihre AWS-Ressourcen werden automatisch in einer sofort einsatzbereiten Standard-VPC bereitgestellt. Sie können weitere VPCs erstellen, indem Sie in der AWS Management Console die Seite "Amazon VPC" öffnen und "Start VPC Wizard" wählen.

Sie erhalten vier grundlegende Optionen für Netzwerkarchitekturen zu Auswahl. Nachdem Sie eine Option ausgewählt haben, können Sie den Umfang des IP-Adressbereichs der VPC und ihrer Subnetze anpassen. Wenn Sie eine Option mit Hardware-VPN-Zugang auswählen, müssen Sie die IP-Adresse der VPN-Hardware des Netzwerks angeben. Sie können die VPC bearbeiten, um sekundäre IP-Bereiche und -Gateways hinzuzufügen oder zu entfernen oder IP-Bereichen weitere Subnetze hinzuzufügen.

Die vier Optionen sind:

  1. Amazon VPC mit nur einem öffentlichem Subnetz
  2. Amazon VPC mit öffentlichen und privaten Subnetzen
  3. Amazon VPC mit öffentlichen und privaten Subnetzen und AWS Site-to-Site VPN-Zugang
  4. Amazon VPC nur mit einem privaten Subnetz und Zugriff über AWS Site-to-Site VPN

Über VPC-Endpunkte können Sie Ihre VPC privat ohne Internet-Gateway, NAT-Gerät, VPN oder Firewall-Proxys mit Services verbinden, die in AWS gehostet werden. Endpunkte sind horizontal skalierbare und hochverfügbare virtuelle Geräte zur Kommunikation zwischen Instances in Ihren VPC und AWS Services. Amazon VPC bietet zwei verschiedene Arten von Endpunkten: Gateway-Endpunkte und Schnittstellen-Endpunkte.

Gateway-Endpunkte sind nur für AWS-Services mit S3 und DynamoDB verfügbar. Endpunkte fügen einen Eintrag zu der von Ihnen ausgewählten Routing-Tabelle hinzu und leiten den Datenverkehr durch das private Netzwerk von Amazon an die unterstützten Services.

Schnittstellenendpunkte ermöglichen private Verbindungen zu Services, die durch PrivateLink unterstützt werden (AWS-Services, Ihre eigenen Services oder SaaS-Lösungen), und unterstützen die Verbindung über Direct Connect. Weitere AWS- und SaaS-Lösungen werden zu einem späteren Zeitpunkt durch diese Endpunkte unterstützt werden. Weitere Informationen zu den Preisen für Schnittstellen-Endpunkte entnehmen Sie den Preisangaben der VPC.

Fakturierung

Alles öffnen

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 AWS-Services, zum Beispiel Amazon EC2, entsprechen den für diese Ressourcen veröffentlichten Tarifen. Für den Zugriff auf AWS Web 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 Internet-Datenübertragungsgebühren an.

Anbindung

Alles öffnen

Sie können mit den folgende Optionen eine Verbindung zu Ihrer Amazon VPC herstellen:

  • 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-Instances in der VPC direkt auf das Internet zugreifen. Sie können auch ein Egress-Only-Internet-Gateway verwenden, bei dem es sich um ein zustandsbehaftetes Gateway handelt, das nur eingehenden Zugang für IPv6-Datenverkehr 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 Service 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, um den Zugriff vom/zum Internet zu ermöglichen.

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 ist über die vorhandenen Austrittspunkte und Netzwerksicherheits-/Netzwerküberwachungsgeräte der Zugriff auf das Internet möglich.

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 einer öffentlichen IP-Adresse läuft die gesamte Kommunikation zwischen Instances und in AWS gehosteten Services über 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-Datenverkehr und für sämtliche Kundenverbindungen oder Service-zu-Service-Verbindungen über Transport Layer Security (TLS). 

Eine Verbindung mit AWS Site-to-Site VPN 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 Verbindung mit AWS Site-to-Site VPN wird kein Internet-Gateway benötigt.

IP-Adressierung

Alles öffnen

Für den primären CIDR-Block können Sie jeden IPv4-Adressbereich, einschließlich RFC 1918 oder öffentlich weiterleitbare IP-Bereiche verwenden. Für die sekundären CIDR-Blöcke 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 einer VPC bis zu 5 von Amazon oder über BYOIP bereitgestellte IPv6-GUA-CIDR-Blöcke zuweisen, 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 oder über BYOIP bereitgestellte 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 /20-Netzblöcke 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, einen (1) primären 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 sowohl 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 erstellen 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). Einem Subnetz kann nur ein IPv6-CIDR-Block zugewiesen 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 eines Subnetz starten, das 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 keiner 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 Instances in Subnetzen verwendet werden, die für die Verwendung eines NAT Gateways oder einer NAT-Instance zum Zugriff auf das Internet konfiguriert sind. Dies gilt nur für IPv4. Amazon VPCs unterstützen aktuell keine EIPs für IPv6.

Bring Your Own IP( BYOIP – Verwendung der eigenen IP-Adresse)

Alles öffnen

Bring Your Own IP (BYOIP) bedeutet, dass Kunden ihren öffentlich weiterleitbaren 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 BYOIP-Elastic-IPs, von Amazon bereitgestellte IPs oder beide verwenden.

Die Verwendung der eigenen IP-Adresse 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 von BYOIP 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.

Einzelheiten zur BYOIP-Verfügbarkeit finden Sie in unserer Dokumentation.

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.

IP Address Manager

Alles öffnen

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 Features:
 

  • 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 die IP-Verwaltung 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 für andere 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.

Topologie

Alles öffnen

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.

Sicherheit und Filterung

Alles öffnen

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 Instances, der nicht explizit erlaubt ist, wird automatisch gesperrt.

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

Sicherheitsgruppen in einer VPC geben an, welcher Datenverkehr von bzw. zu einer Amazon-EC2-Instance erlaubt 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 einer 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 Traffic Mirroring und Amazon-VPC-Flow-Protokolle verwenden, um den Netzwerkdatenverkehr in Ihrer Amazon-VPC zu überwachen.

VPC-Flow-Protokolle sind ein Feature, mit dem 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 Flow-Protokollen von Amazon VPC finden Sie in 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 nachgelagerte 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 einen einzelnen Transit-Gateway-Anhang 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. Weitere Informationen zur Unterstützung von Amazon-VPC-Flow-Protokollen für Transit Gateway finden Sie in der Dokumentation.

Flow-Protokolldaten werden außerhalb des Pfades Ihres Netzwerkdatenverkehrs 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 unter Preise für Amazon CloudWatch. Sie können auch Gebühren aus der Veröffentlichung von Flow-Protokollen mit Hilfe von Kostenzuordnungs-Tags verfolgen.

VPC-Datenverkehrsspiegelung

Alles öffnen

Mithilfe von Amazon VPC Traffic Mirroring können Kunden den Netzwerkdatenverkehr von und zu einer Amazon-EC2-Instance auf einfache Weise replizieren, sowie ihn an bandexterne Sicherheits- und Überwachungs-Anwendungen für Anwendungsfälle wie Inhaltsprüfung, Bedrohungsüberwachung und Fehlerbehebung weiterleiten. Diese Anwendungen 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.

Traffic Mirroring 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. Traffic Mirroring erlaubt es Kunden, replizierten Verkehr an jeden Sammler/Broker von Netzwerkpaketen oder an jedes Analysetool zu streamen, ohne dass sie herstellerspezifische Agenten installieren müssen.

Anhand von Amazon-VPC-Flow-Protokollen 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.

Amazon VPC Traffic Mirroring bietet einen tieferen Einblick in den Netzwerkdatenverkehr, indem Sie den tatsächlichen Inhalt des Datenverkehrs einschließlich der Nutzdaten analysieren können, und 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 und EC2

Alles öffnen

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 „Keine Einstellung“ 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-Volumes zurück.

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 ein Amazon-EBS-gestütztes AMI verwendet, behält jedoch dieselbe IP-Adresse bei, wenn sie angehalten und neu 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 angehaltenen Instances 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. 

Standard-VPCs

Alles öffnen

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 Ihnen 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. März 2013 erstellt wurde, kann Ihr Konto 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 Ressourcen für Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache oder Amazon Redshift bereitgestellt haben.

Nein. Sie können die AWS Management Console, die AWS-EC2-CLI oder die Amazon-EC2-API verwenden, um EC2-Instances und andere AWS-Ressourcen in einer Standard-VPC zu starten und zu 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 Standard-Subnetzen 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-Standard-subnetzen können Sie das Ziel für Ihre Startvorgänge mithilfe der Konsole oder der Option --subnet in der CLI, API oder dem SDK angeben.

Sie können in jeder AWS-Region, für die das Attribut „Unterstützte Plattformen“ auf „EC2-VPC“ festgelegt ist, über eine Standard-VPC verfügen.

Ein Standard-Subnetz wird für jede Availability Zone in Ihrer Standard-VPC 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 zuvor gelöschte VPC wird dadurch nicht wiederhergestellt.

Ja, ein Standard-Subnetz 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 zuvor 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 „Unterstützte Plattformen“ 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

Alles öffnen

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 außer Betrieb nehmen und Sie müssen alle EC2-Instances und andere AWS-Ressourcen, die in EC2-Classic laufen, vor diesem Datum zu Amazon VPC migrieren. Im folgenden Abschnitt finden Sie weitere Informationen über die Außerbetriebnahme 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 „Absenden“.

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 unter der nachfolgenden Frage.

Amazon VPC gibt Ihnen die vollständige Kontrolle über Ihre virtuelle Netzwerkumgebung in 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:

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:

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“ unter „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 in EC2-Classic in mehreren AWS-Regionen betreiben, empfehlen wir Ihnen, EC2-Classic für jede dieser Regionen zu deaktivieren, sobald Sie alle Ihre Ressourcen in diesen Regionen zu VPC migriert haben.

Wir werden die folgenden beiden Maßnahmen vor dem Datum der Außerbetriebnahme am 15. August 2022 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 Workloads oder Services werden ab dem 16. August 2022 nach und nach den Zugriff auf alle AWS-Services in EC2-Classic verlieren, wenn wir sie außer Betrieb nehmen.

Elastic-Network-Schnittstellen

Alles öffnen

Ja.

Netzwerkschnittstellen können nur Instances in derselben Availability Zone angehängt werden.

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

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 EIPs zu.

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

Peering-Verbindungen

Alles öffnen

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

Ja, vorausgesetzt, der Besitzer der 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 Datenübertragungsraten finden Sie im Abschnitt Datenübertragung auf der EC2-Preisseite.

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 beiden 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 regionsübergreifende Peering-Verbindung ausfällt, wird der Datenverkehr 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 Datenverkehr 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 regionsübergreifenden VPC-Peering zur Auflösung in eine private IP-Adresse verwendet werden.

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

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

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

Weitere Fragen

Alles öffnen

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. Weitere Informationen über den AWS Support finden Sie hier.

ElasticFox wird offiziell nicht mehr für die Verwaltung Ihrer Amazon VPC unterstützt. Unterstützung für Amazon VPC ist über die AWS-APIs, AWS-Befehlszeilen-Tools und die AWS-Managementkonsole sowie verschiedene Hilfsprogramme von Drittanbietern verfügbar.

VPC Encryption Controls

Alles öffnen

Ein Sicherheits- und Compliance-Feature, das eine zentrale Steuerung zur Überwachung und Durchsetzung der Verschlüsselung von Datenverkehrsströmen innerhalb und zwischen VPCs in einer Region bietet. Weitere Informationen finden Sie in der Dokumentation hier.

Monitor-Modus (für Sichtbarkeit, Bewertung und Initiierung der Migration) und Enforce-modus (zur Verhinderung von unverschlüsseltem Datenverkehr).

Sicherheitsadministratoren und Cloud-Architekten, insbesondere in Branchen, die die Einhaltung von Standards wie HIPAA, FedRAMP und PCI DSS erfordern.

Der Service verwendet sowohl Verschlüsselung auf Anwendungsebene als auch die integrierten Verschlüsselungsfunktionen der AWS-Nitro-Systemhardware, um die Durchsetzung der Verschlüsselung sicherzustellen.

Der Monitor-Modus bietet Einblick in den Verschlüsselungsstatus von Datenverkehrsströmen, hilft bei der Identifizierung nicht konformer Ressourcen und füllt VPC-Flow-Protokolle mit Informationen zum Verschlüsselungsstatus auf. Ressourcen wie Network Load Balancer, Application Load Balancer, Fargate-Cluster und EKS Control Plane werden automatisch und schrittweise auf Hardware migriert, die Verschlüsselung nativ unterstützt, sobald Sie den Monitor-Modus einschalten.

Mithilfe von:

  • VPC-Flow-Protokolle mit dem Feld encryption-status
  • Konsolen-Dashboard
  • Befehl GetVpcResourcesBlockingEncryptionEnforcement

Nein, Sie müssen neue Flow-Protokolle erstellen und das Verschlüsselungsstatus-Feld manuell hinzufügen. Es wird auch empfohlen, die Felder traffic-path und flow-direction hinzuzufügen.

Sobald sich eine VPC im Enforce-Modus befindet, verhindert sie das Erstellen oder Anhängen von Ressourcen, die unverschlüsselten Datenverkehr innerhalb der VPC-Grenze erlauben. Sie werden daran gehindert, Instances auszuführen, die die native Nitro-Verschlüsselung nicht unterstützen.

Nein, Sie müssen zuerst:

  • Den Monitor-Modus aktivieren
  • Ressourcen identifizieren, die nicht den Anforderungen entsprechen
  • Ausnahmen für nicht konforme Ressourcen ändern oder erstellen
  • Wechseln Sie dann in den Enforce-Modus.

Sie müssen für diese Ressource eine Ausnahme aus den acht unterstützten Ausnahmetypen erstellen. Andere nicht unterstützte Ressourcen müssen aus der VPC migriert oder gelöscht werden, bevor der Enforce-Modus aktiviert wird. Ressourcen, die von Encryption Controls unterstützt werden, müssen auf verschlüsselungskonforme Instances migriert werden, bevor die Erzwingung aktiviert wird.

Dazu gehen Sie wie folgt vor:

  • Überprüfen Sie die Flow-Protokolle und die Ressourcen-Compliance.
  • Planen Sie die erforderlichen Ressourcenmigrationen.
  • Konfigurieren Sie die erforderlichen Ausnahmen beim Wechsel in den Enforce-Modus.

Ja, außer in dem Szenario, in dem Sie ein VPC-Peering zwischen zwei VPCs ohne Ausnahmen eingerichtet haben. In diesem Fall müssen Sie das VPC-Peering zwischen den beiden VPCs löschen und dann in den Monitor-Modus wechseln.

Verwenden Sie den Befehl GetVpcResourcesBlockingEncryptionEnforcement, um alle Ressourcen zu identifizieren, welche die Durchsetzung blockieren würden. Alternativ können Sie die Konsole verwenden, um unverschlüsselte Ressourcen zu finden.

Es gibt acht unterstützte Ausschlüsse:

  • Internet-Gateway
  • NAT-Gateway
  • Internet-Gateway nur für ausgehenden Verkehr
  • VPC-Peering-Verbindungen zu VPCs ohne Verschlüsselung
  • Virtual Private Gateway
  • Lambda-Funktionen
  • VPC Lattice
  • Elastic File System

0: nicht verschlüsselt
1: nitro-verschlüsselt
2: anwendungsverschlüsselt
3: Sowohl nitro- UND anwendungsverschlüsselt
(-): Unbekannt/VPC-Verschlüsselungssteuerungen ausgeschaltet

Um den Datenverkehr zwischen Ihren VPCs zu verschlüsseln, für die Encryption Controls aktiviert ist, können Sie VPC Peering oder Transit Gateway verwenden. Wenn Sie Transit Gateway verwenden, müssen Sie die Verschlüsselungsunterstützung explizit mithilfe der Konsole oder des Befehls modify-transit-gateway aktivieren. Für die Aktivierung der Verschlüsselung auf dem Transit Gateway fallen keine separaten Gebühren an, aber es fallen Standardgebühren für VPC Encryption Controls für alle VPCs an, die dem Transit Gateway zugeordnet sind (unabhängig davon, ob Sie Encryption Controls auf diesen VPCs aktivieren).

Verwenden Sie den Befehl „modify-transit-gateway“ oder aktivieren Sie die Verschlüsselung über die AWS-Konsole. Sie müssen die Verschlüsselungsunterstützung auf einem Transit Gateway explizit aktivieren, um den Verkehr zwischen Ihren VPCs zu verschlüsseln, bei denen Encryption Controls aktiviert ist.

Die Aktivierung der Verschlüsselung auf bestehenden TGW stört die bestehenden Datenverkehrsflüsse nicht, und die Migration von VPC-Anhängen auf verschlüsselte Leitungen erfolgt nahtlos und automatisch. Sie können die Verschlüsselungsunterstützung auf einem Transit Gateway aktivieren, um den Datenverkehr zwischen Ihren VPCs zu verschlüsseln. Der Datenverkehr zwischen zwei VPCs im Enforce-Modus (ohne Ausnahmen) wird über das TGW durchgehend verschlüsselt. Mit der Verschlüsselung in Transit Gateway können Sie auch zwei VPCs verbinden, die sich in unterschiedlichen Encryption-Controls-Modi befinden.

Das kommt darauf an. Der Datenverkehr zwischen zwei VPCs im Enforce-Modus (ohne Ausnahmen) wird über das TGW durchgehend verschlüsselt. Mit der Verschlüsselung auf dem Transit Gateway können Sie auch zwei VPCs verbinden, die sich in unterschiedlichen Encryption-Controls-Modi befinden. Sie sollten diese Option verwenden, wenn Sie Verschlüsselungskontrollen in einer VPC durchsetzen möchten, die mit einer VPC ohne erzwungener Verschlüsselung verbunden ist. In einem solchen Szenario wird Ihr gesamter Datenverkehr innerhalb der VPC mit erzwungener Verschlüsselung, einschließlich des Inter-VPC-Datenverkehrs, verschlüsselt. Der Inter-VPC-Datenverkehr wird zwischen den Ressourcen in der VPC mit erzwungener Verschlüsselung und dem Transit Gateway verschlüsselt. Darüber hinaus hängt die Verschlüsselung von den Ressourcen ab, zu denen der Datenverkehr in der nicht erzwungenen VPC geleitet wird, und es kann nicht garantiert werden, dass er verschlüsselt wird (da sich die VPC nicht im Enforce-Modus befindet). Alle VPCs müssen sich in derselben Region befinden.

Ja, der Datenverkehr bleibt verschlüsselt, bis er den TGW-Anhang in der nicht erzwungenen VPC erreicht. Der Datenverkehr bleibt von der Quelle bis zum TGW-Anhang in der Ziel-VPC verschlüsselt, unabhängig vom Verschlüsselungsstatus der Ziel-VPC.

Aktivieren Sie die Verschlüsselung auf dem TGW und behalten Sie gleichzeitig die bestehenden Verbindungen bei – der Übergang erfolgt automatisch. Die Aktivierung der Verschlüsselung auf TGW stört die bestehenden Datenverkehrsflüsse nicht.

Ja, TGW unterstützt die inkrementelle Migration, indem es während des Übergangs sowohl verschlüsselten als auch unverschlüsselten Datenverkehr verarbeitet.

Nein. Private Link mit VPC Encryption Controls wird nur für AWS-Services unterstützt. VPC-Endpunkte für Services, die nicht von AWS stammen, können nicht in VPCs verbleiben, in denen Sie die Verschlüsselung durchsetzen möchten. Sie müssten diese Endpunkte löschen, bevor Sie in den Enforce-Modus auf der VPC übergehen. VPCs, die im Enforce-Modus laufen, können mit VPC Peering oder Transit Gateway verbunden werden, um eine durchgängige Verschlüsselung zu gewährleisten.