Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Arbeiten mit einer DB-Cluster in einer VPC

Ihr DB-Cluster befindet sich in einer Virtual Private Cloud (VPC). Eine VPC ist ein virtuelles Netzwerk, das logisch von anderen virtuellen Netzwerken in der AWS Cloud isoliert ist. Amazon VPC ermöglicht es Ihnen, AWS Ressourcen wie einen Aurora oder eine Amazon EC2 EC2-Instance in einer VPC zu starten. Bei der VPC kann es sich um die mit Ihrem Konto verknüpfte Standard-VPC oder eine von Ihnen erstellte VPC handeln. Alle VPCs sind mit Ihrem Konto verknüpft. AWS

Die Standard-VPC besitzt drei Subnetze, mit denen Sie Ressourcen innerhalb der VPC separieren können. Zudem verfügt die Standard-VPC über ein Internet-Gateway, mit dem Sie den externen Zugriff auf Ressourcen in der VPC gewähren können.

Eine Liste von Szenarien mit Amazon Aurora DB-Clusters in einer VPC finden Sie unter Szenarien für den Zugriff auf eine DB- Cluster in einer VPC.

In den folgenden Tutorials lernen Sie, eine VPC zu erstellen, die Sie für ein gängiges Amazon-Aurora-Szenario verwenden können:

Arbeiten mit einer DB-Cluster in einer VPC

Hier sind einige Tipps für das Arbeiten mit einer DB-Cluster in einer VPC:

VPC-Verschlüsselungssteuerung

VPC-Verschlüsselungskontrollen ermöglichen es Ihnen, die Verschlüsselung während der Übertragung für den gesamten Netzwerkverkehr innerhalb Ihrer VPCs durchzusetzen. Verwenden Sie die Verschlüsselungskontrolle, um die gesetzlichen Anforderungen zu erfüllen, indem Sie sicherstellen, dass nur verschlüsselungsfähige Nitro-based Hardware in den dafür vorgesehenen VPCs bereitgestellt werden kann. Durch die Verschlüsselungskontrolle werden Kompatibilitätsprobleme auch bei der API-Anfrage und nicht bei der Bereitstellung erkannt. Ihre vorhandenen Workloads werden weiterhin ausgeführt und nur neue inkompatible Anfragen werden blockiert.

Richten Sie Ihre VPC-Verschlüsselungskontrollen ein, indem Sie den VPC-Steuerungsmodus auf Folgendes einstellen:

Um den aktuellen Steuermodus für Ihre VPC zu überprüfen, verwenden Sie den AWS-Managementkonsole oder DescribeVpcsCLI- oder API-Befehl.

Wenn Ihre VPC Verschlüsselung erzwingt, können Sie nur Nitro-based bereitstellen, die Verschlüsselung bei der Übertragung in dieser VPC unterstützen. Weitere Informationen finden Sie unter DB-Instance-Klassenarten. Informationen zu Nitro-Instances finden Sie unter Instances, die auf dem AWS Nitro System basieren im Amazon EC2 EC2-Benutzerhandbuch.

Aurora ServerlessFür MySQL und PostreSQL erfordert die Verschlüsselungskontrolle Plattformversion 3 oder höher.

Arbeiten mit DB-Subnetzgruppen

Subnetze sind Segmente eines IP-Adressbereichs der VPC, die Sie festlegen und mit denen Sie basierend auf Ihren Sicherheits- und Betriebsanforderungen Ressourcen gruppieren können. Eine DB-Subnetzgruppe ist eine Sammlung von Subnetzen (in der Regel private Subnetze), die Sie in einer VPC erstellen und anschließend Ihrer DB-Clusters zuweisen. Mithilfe einer DB-Subnetzgruppe können Sie eine bestimmte VPC angeben, wenn Sie mithilfe der AWS CLI oder RDS-API erstellen. Wenn Sie die Konsole verwenden, können Sie die VPC und Subnetze auswählen, die Sie verwenden möchten.

Jede DB-Subnetzgruppe sollte über Subnetze in mindestens zwei Availability Zones in einer bestimmten AWS-Region verfügen. Beim Erstellen einer DB-Cluster in einer VPC müssen Sie eine DB-Subnetzgruppe dafür auswählen. Aus der DB-Subnetzgruppe wählt Amazon Aurora ein Subnetz und eine IP-Adresse innerhalb dieses Subnetzes aus, um es mit der primären DB-Instance in Ihrem DB-Cluster zu verbinden. Die DB verwendet die Availability Zone, die das Subnetz enthält. Aurora weist immer eine IP-Adresse aus einem Subnetz zu, das über freien IP-Adressraum verfügt.

Die Subnetze in einer DB-Subnetzgruppe sind entweder öffentlich oder privat. Die Subnetze sind öffentlich oder privat, abhängig von der Konfiguration, die Sie für die Netzwerkzugriffskontrolllisten (Netzwerk-ACLs) und Routingtabellen festgelegt haben. Damit öffentlich auf eine DB-Cluster zugegriffen werden kann, müssen alle Subnetze in der entsprechenden DB-Subnetzgruppe öffentlich sein. Wenn ein Subnetz, das mit einer öffentlich zugänglichen DBCluster verknüpft ist, von öffentlich in privat geändert wird, kann dies die Verfügbarkeit der DB-Cluster beeinträchtigen.

Wenn Sie eine DB-Subnetzgruppe erstellen möchten, die den Dual-Stack-Modus unterstützt, stellen Sie sicher, dass jedem Subnetz, das Sie der DB-Subnetzgruppe hinzufügen, ein CIDR-Block der Internetprotokollversion 6 (IPv6) zugeordnet ist. Weitere Informationen finden Sie unter Amazon-Aurora-IP-Adressierung und Migrieren zu IPv6 im Amazon VPC-Benutzerhandbuch.

Wenn Amazon Aurora eine DB-Cluster in einer VPC erstellt, wird Ihrer DB-Cluster mithilfe einer IP-Adresse aus Ihrer DB-Subnetzgruppe eine Netzwerkschnittstelle zugewiesen. Wir empfehlen jedoch dringend, den DNS-Namen (Domain Name System) für die Verbindung zu Ihrem DB-Cluster zu verwenden. Wir empfehlen dies, da sich die zugrunde liegende IP-Adresse während des Failovers ändert.

Gemeinsam genutzte Subnetze

Sie können eine(n) DB-Cluster in einer gemeinsam genutzten VPC erstellen.

Einige Aspekte, die Sie bei der Verwendung gemeinsam genutzter VPCs beachten sollten:

Amazon-Aurora-IP-Adressierung

IP-Adressen ermöglichen es Ressourcen in Ihrer VPC untereinander und mit Ressourcen im Internet zu kommunizieren. Amazon Aurora unterstützt sowohl IPv4- als auch IPv6-Adressierungsprotokolle. Standardmäßig verwenden Amazon Aurora und Amazon VPC das IPv4-Adressierungsprotokoll. Sie können dieses Standardverhalten nicht deaktivieren. Wenn Sie eine VPC erstellen, müssen Sie einen IPv4 CIDR-Block (einen privaten IPv4-Adressenbereich) angeben. Optional können Sie Ihrer VPC und den Subnetzen einen IPv6 CIDR-Block zuordnen und den Clustern in Ihrem Subnetz IPv6-Adressen von diesem Block zuweisen.

Durch die Unterstützung des IPv6-Protokolls wird die Anzahl der unterstützten IP-Adressen erweitert. Durch die Verwendung des IPv6-Protokolls stellen Sie sicher, dass Sie über ausreichende verfügbare Adressen für das künftige Wachstum des Internets verfügen. Neue und vorhandene RDS-Ressourcen können IPv4- und IPv6-Adressen innerhalb Ihrer VPC verwenden. Das Konfigurieren, Sichern und Übersetzen des Netzwerkverkehrs zwischen den beiden Protokollen, die in verschiedenen Teilen einer Anwendung verwendet werden, können den Betriebsaufwand erhöhen. Sie können das IPv6-Protokoll für Amazon-RDS-Ressourcen standardisieren, um Ihre Netzwerkkonfiguration zu vereinfachen.

IPv4-Adressen

Beim Erstellen einer VPC müssen Sie für diese einen IPv4-Adressbereich in Form eines CIDR-Blocks wie 10.0.0.0/16 festlegen. Eine DB-Subnetzgruppe definiert den Bereich der IP-Adressen in diesem CIDR-Block, den eine DB-Cluster verwenden kann. Diese IP-Adressen können privat oder öffentlich sein.

Eine private IPv4-Adresse ist eine IP-Adresse, die nicht über das Internet erreichbar ist. Sie können private IPv4-Adressen zur Kommunikation zwischen Ihrem DB-Cluster und anderen Ressourcen, wie Amazon-EC2-Instances, in derselben VPC verwenden. Jeder DB-Cluster hat eine private IP-Adresse für die Kommunikation in der VPC.

Eine öffentliche IP-Adresse ist eine IPv4-Adresse, die über das Internet erreichbar ist. Sie können öffentliche Adressen zur Kommunikation zwischen Ihrem DB-Cluster und Ressourcen im Internet, wie ein SQL-Client, verwenden. Anhand der folgenden Schritte können Sie kontrollieren, ob Ihr DB-Cluster eine öffentliche IP-Adresse erhält:

Amazon RDS verwendet Public Elastic IPv4-Adressen aus dem öffentlichen IPv4-Adresspool von EC2 für öffentlich zugängliche Datenbank-Instances. Diese IP-Adressen sind in Ihrem AWS Konto sichtbar, wenn Sie die describe-addresses CLI oder API verwenden oder den Abschnitt Elastic IPs (EIP) in der AWS-Managementkonsole aufrufen. Jede RDS-managed IP-Adresse ist mit einem service_managed Attribut gekennzeichnet, das auf "rds" gesetzt ist.

Diese IPs sind zwar in Ihrem Konto sichtbar, werden aber weiterhin vollständig von Amazon RDS verwaltet und können nicht geändert oder veröffentlicht werden. Amazon RDS gibt IPs wieder in den öffentlichen IPv4-Adresspool frei, wenn sie nicht mehr verwendet werden.

CloudTrail protokolliert API-Aufrufe im Zusammenhang mit der EIP von RDS, wie z. B. AllocateAddress Diese API-Aufrufe werden vom Service Principal aufgerufen. rds.amazonaws.com

Weitere Informationen zum Erstellen einer VPC nur mit privaten IPv4-Adressen, die Sie mit einem gängigen Amazon Aurora-Szenario verwenden können, finden Sie unter Tutorial: Erstellen einer VPC zur Verwendung mit einem DB-Cluster (nur IPv4).

IPv6-Adressen

Optional können Sie Ihrer VPC und den Subnetzen einen IPv6 CIDR-Block zuordnen und den Ressourcen in Ihrer VPC IPv6-Adressen von diesem Block zuweisen. Jede IPv6-Adresse ist global eindeutig.

Der IPv6 CIDR-Block für Ihre VPC wird automatisch aus dem Amazon-Pool mit IPv6-Adressen zugewiesen. Sie können den Bereich nicht selbst auswählen.

Stellen Sie beim Herstellen einer Verbindung mit einer IPv6-Adresse sicher, dass die folgenden Bedingungen erfüllt sind:

Weitere Informationen über IPv6 finden Sie unter IP-Adresszuweisung im Amazon VPC Benutzerhandbuch.

Dual-stack Modus

Ein wird im Dual-Stack-Modus ausgeführt, wenn er sowohl über IPv4- als auch über IPv6-Adressierungsprotokolle kommunizieren kann. Ressourcen können dann entweder über IPv4, IPv6 oder beide Protokolle mit dem kommunizieren. Private DB-Instances im Dual-Stack-Modus verfügen über IPv6-Endpunkte, die RDS auf den VPC-Zugriff beschränkt, um sicherzustellen, dass Ihre IPv6-Endpunkte privat bleiben. Öffentliche DB-Instances im Dual-Stack-Modus bieten sowohl IPv4- als auch IPv6-Endpunkte, auf die Sie über das Internet zugreifen können.

Weitere Informationen zum Erstellen einer VPC sowohl mit IPv4- als auch IPv6-Adressen, die Sie mit einem gängigen Amazon-Aurora-Szenario verwenden können, finden Sie unter Tutorial: Erstellen einer VPC zur Verwendung mit einer DB–einem DB-Cluster (Dual-Stack-Modus).

Dual-stack Modus- und DB-Subnetzgruppen

Zur Verwendung des Dual-Stack-Modus stellen Sie sicher, dass jedem Subnetz in der DB-Subnetzgruppe, das Sie mit dem DB-Cluster verknüpfen, ein IPv6-CIDR-Block zugeordnet ist. Sie können eine neue DB-Subnetzgruppe erstellen oder eine vorhandene DB-Subnetzgruppe ändern, um diese Anforderung zu erfüllen. Nachdem ein DB-Cluster in den Dual-Stack-Modus gewechselt ist, können sich Clients normal damit verbinden. Stellen Sie sicher, dass Client-Sicherheits-Firewalls und Sicherheitsgruppen der RDS-DB-Instance präzise konfiguriert sind, um Datenverkehr über IPv6 zuzulassen. Zum Herstellen einer Verbindung verwenden Clients den Endpunkt der primären Instance des DB-Clusters. Clientanwendungen können angeben, welches Protokoll bevorzugt wird, wenn eine Verbindung mit einer Datenbank hergestellt wird. Im Dual-Stack-Modus erkennt der DB-Cluster das bevorzugte Netzwerkprotokoll des Clients, entweder IPv4 oder IPv6, und verwendet dieses Protokoll für die Verbindung.

Wenn eine DB-Subnetzgruppe den Dual-Stack-Modus aufgrund der Löschung des Subnetzes oder der CIDR-Trennung nicht mehr unterstützt, besteht die Gefahr eines inkompatiblen Netzwerkstatus für DB-Instances, die mit der DB-Subnetzgruppe verknüpft sind. Sie können die DB-Subnetzgruppe auch nicht verwenden, wenn Sie einen neuen DB-Cluster im Dual-Stack-Modus erstellen.

Um mithilfe von festzustellen, ob eine DB-Subnetzgruppe den Dual-Stack-Modus unterstützt AWS-Managementkonsole, sehen Sie sich den Netzwerktyp auf der Detailseite der DB-Subnetzgruppe an. Um mithilfe von zu ermitteln, ob eine DB-Subnetzgruppe den Dual-Stack-Modus unterstützt AWS CLI, führen Sie den Befehl describe-db-subnet-groups aus und sehen Sie sich die Ausgabe an. SupportedNetworkTypes

Lesereplikate werden als unabhängige DB-Instances behandelt und können einen anderen Netzwerktyp haben als die primäre DB-Instance. Wenn Sie den Netzwerktyp der primären DB-Instance eines Lesereplikats ändern, ist das Lesereplikat nicht betroffen. Wenn Sie eine DB-Instance wiederherstellen, können Sie sie auf jedem unterstützten Netzwerktyp wiederherstellen.

Arbeiten mit DB-Instances im Dual-Stack-Modus

Wenn Sie einen DB-Cluster erstellen oder ändern, können Sie den Dual-Stack-Modus angeben, damit Ihre Ressourcen mit Ihrer Ihrem DB-Cluster über IPv4, IPv6 oder beidem kommunizieren können.

Wenn Sie den verwenden, um eine DB-Instance AWS-Managementkonsole zu erstellen oder zu ändern, können Sie den Dual-Stack-Modus im Abschnitt Netzwerktyp angeben. Die folgende Abbildung zeigt den Abschnitt Network type (Netzwerktyp) in der Konsole.

Wenn Sie den verwenden AWS CLI , um einen zu erstellen oder zu ändern, stellen Sie die --network-type Option so ein, dass der Dual-Stack-Modus verwendet werden DUAL soll. Wenn Sie die RDS API zum Erstellen oder Ändern eines DB-Clusters verwenden, legen Sie den Parameter NetworkType auf DUAL fest, um den Dual-Stack-Modus zu verwenden. Wenn Sie den Netzwerktyp einer DB-Instance ändern, sind Ausfallzeiten möglich. Wenn der Dual-Stack-Modus von der angegebenen DB-Engine-Version oder der DB-Subnetzgruppe nicht unterstützt wird, wird der Fehler NetworkTypeNotSupported zurückgegeben.

Weitere Informationen zum Erstellen eines DB-Clusters finden Sie unter Erstellen eines Amazon Aurora-DB Clusters. Weitere Informationen über das Ändern eines DB-Clusters finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

Um festzustellen, ob sich ein DB-Cluster im Dual-Stack-Modus befindet, sehen Sie sich den Netzwerktyp auf der Registerkarte Connectivity & security (Konnektivität & Sicherheit) für den DB-Cluster an.

Ändern von IPv4-only zur Verwendung des Dual-Stack-Modus

Sie können einen IPv4-only so ändern, dass er den Dual-Stack-Modus verwendet. Dazu ändern Sie den Netzwerktyp der DB-Cluster. Die Änderung kann zu Ausfallzeiten führen.

Es wird empfohlen, den Netzwerktyp Ihrer Amazon-Aurora-DB-Cluster während eines Wartungsfensters zu ändern. Das Festlegen des Netzwerktyps neuer Instances auf den Dual-Stack-Modus wird derzeit nicht unterstützt. Sie können den Netzwerktyp manuell festlegen, indem Sie den Befehl modify-db-cluster verwenden.

Bevor Sie eine DB-Cluster zur Verwendung des Dual-Stack-Modus ändern, stellen Sie sicher, dass ihre DB-Subnetzgruppe den Dual-Stack-Modus unterstützt. Wenn die mit der DB-Cluster verknüpfte DB-Subnetzgruppe den Dual-Stack-Modus nicht unterstützt, geben Sie eine andere DB-Subnetzgruppe an, die DB-Cluster unterstützt, wenn Sie sie ändern. Das Ändern der DB-Subnetzgruppe eines DB-Clusters kann zu Ausfallzeiten führen.

Wenn Sie die DB-Subnetzgruppe eines DB-Clusters ändern, bevor Sie den DB-Cluster zur Verwendung des Dual-Stack-Modus ändern, stellen Sie sicher, dass die DB-Subnetzgruppe vor und nach der Änderung für den DB-Cluster gültig ist.

Wir empfehlen, dass Sie die API modify-db-cluster nur mit dem Parameter --network-type und dem Wert DUAL ausführen, um das Netzwerk eines Amazon-Aurora-Clusters auf den Dual-Stack-Modus umzustellen. Das Hinzufügen anderer Parameter zusammen mit dem Parameter --network-type in demselben API-Aufruf kann zu Ausfallzeiten führen.

Wenn Sie nach der Änderung keine Verbindung mit dem DB-Cluster herstellen können, stellen Sie sicher, dass die Firewalls und Routing-Tabellen für die Client- und Datenbanksicherheit genau konfiguriert sind, um Datenverkehr zur Datenbank im ausgewählten Netzwerk (entweder IPv4 oder IPv6) zuzulassen. Möglicherweise müssen Sie auch Betriebssystemparameter, Bibliotheken oder Treiber ändern, um eine Verbindung mithilfe einer IPv6-Adresse herzustellen.

Verfügbarkeit von Dual-Stack-Netzwerk-DB-Cluster

Dual-stack Netzwerk-DB-Cluster sind in allen verfügbar, AWS-Regionen mit Ausnahme der folgenden:

Die folgenden DB-Engine-Versionen unterstützen DB-Instances im Dual-Stack-Netzwerk:

Einschränkungen für Dual-Stack-Netzwerk-DB-Cluster

Die folgenden Einschränkungen gelten für Dual-Stack-Netzwerk-DB-Cluster:

Ausblenden einer DB-Clusters in einer VPC vor dem Internet

Ein häufiges Amazon-Aurora-Szenario ist eine VPC, in der Sie eine Amazon-EC2-Instance mit einer öffentlich zugänglichen Webanwendung und einen DB-Cluster mit einer nicht öffentlich zugänglichen Datenbank haben. Sie können beispielsweise eine VPC mit einem öffentlichen und einem privaten Subnetz erstellen. EC2-Instances, die als Webserver verwendet werden, können im öffentlichen Subnetz bereitgestellt werden. Die DB-Cluster werden im privaten Subnetz bereitgestellt. Bei einer solchen Bereitstellung haben nur die Webserver Zugang zu den DB-Cluster. Eine bildliche Darstellung dieses Szenarios finden Sie unter DB-Cluster in einer VPC, auf die eine Amazon-EC2-Instance in derselben VPC zugreift.

Wenn Sie eine DB-Cluster innerhalb einer VPC starten, verfügt die DB-Cluster über eine private IP-Adresse für den Datenverkehr innerhalb der VPC. Diese private IP-Adresse ist nicht öffentlich zugänglich. Mit der Option Public access (Öffentlicher Zugriff) können Sie festlegen, ob die DB-Cluster neben der privaten IP-Adresse auch eine öffentliche IP-Adresse hat. Wenn die DB-Cluster als öffentlich zugänglich bezeichnet wird, wird ihr DNS-Endpunkt innerhalb der VPC in die private IP-Adresse aufgelöst. Es wird in die öffentliche IP-Adresse von außerhalb der VPC aufgelöst. Zugriff auf die DB-Cluster wird letztendlich von der Sicherheitsgruppe kontrolliert, die sie verwendet. Dieser öffentliche Zugang ist nicht erlaubt, wenn die dem DB-Cluster zugewiesene Sicherheitsgruppe keine eingehenden Regeln enthält, die ihn erlauben. Damit ein DB-Cluster öffentlich zugänglich ist, müssen die Subnetze in seiner DB-Subnetzgruppe außerdem über ein Internet-Gateway verfügen. Weitere Informationen finden Sie unter Verbindung zur Amazon-RDS-DB-Instance kann nicht hergestellt werden

Sie können eine DB-Cluster ändern und die öffentliche Zugänglichkeit mit der Option Public access (Öffentlicher Zugriff) aktivieren und deaktivieren. Die folgende Abbildung zeigt die Option Public access (Öffentlicher Zugriff) im Abschnitt Additional connectivity configuration (Zusätzliche Konnektivitätskonfiguration) . Um die Option festzulegen, öffnen Sie den Abschnitt Additional connectivity configuration (Zusätzliche Konnektivitätskonfiguration) im Abschnitt Connectivity (Konnektivität) .

Hinweise zum Ändern einer DB-Instance zum Festlegen der Option Public access (Öffentlicher Zugriff) finden Sie unter Ändern einer DB-Instance in einem DB-Cluster.

Erstellen einer DB-Cluster in einer VPC

In den folgenden Verfahren wird das Erstellen einer DB-Cluster in einer VPC veranschaulicht. Um die Standard-VPC zu verwenden, können Sie mit Schritt 2 beginnen und die VPC- und DB-Subnetzgruppe verwenden, die bereits für Sie erstellt wurden. Wenn Sie eine zusätzliche VPC erstellen möchten, können Sie eine neue VPC erstellen.

Gehen Sie wie folgt vor, um eine DB-Instance in einer VPC zu erstellen:

Schritt 1: Erstellen einer VPC

Erstellen Sie eine VPC mit Subnetzen in mindestens zwei Availability Zones. Diese Subnetze verwenden Sie, wenn Sie eine DB-Subnetzgruppe erstellen. Wenn Sie eine Standard-VPC verwenden, wird automatisch ein Subnetz in jeder Availability Zone der AWS-Region für Sie erstellt.

Weitere Informationen finden Sie unter Erstellen einer VPC mit privaten und öffentlichen Subnetzen oder unter Create a VPC (VPC erstellen) im Amazon VPC Benutzerhandbuch.

Schritt 2: Erstellen einer DB-Subnetzgruppe

Eine DB-Subnetzgruppe ist eine Sammlung von Subnetzen (in der Regel private Subnetze), die Sie für eine VPC erstellen und anschließend Ihren DB-Cluster zuweisen. Mit einer DB-Subnetzgruppe können Sie eine bestimmte VPC angeben, wenn Sie mithilfe der AWS CLI oder RDS-API erstellen. Wenn Sie die Konsole verwenden, können Sie einfach die VPC und Subnetze auswählen, die Sie verwenden möchten. Jede DB-Subnetzgruppe muss über mindestens ein Subnetz in mindestens zwei Availability Zones der AWS-Region verfügen. Jede DB-Subnetzgruppe sollte über mindestens ein Subnetz für jede Availability Zone in einer bestimmten AWS-Region verfügen.

Damit öffentlich auf eine DB-Cluster zugegriffen werden kann, müssen die Subnetze in der DB-Subnetzgruppe über ein Internet-Gateway verfügen. Weitere Informationen zu Internet-Gateways für Subnetze finden Sie unter Verbinden mit dem Internet durch einen Internet-Gateway im Amazon VPC Benutzerhandbuch.

Beim Erstellen einer DB-Cluster in einer VPC müssen Sie eine DB-Subnetzgruppe auswählen. Amazon Aurora wählt ein Subnetz und eine IP-Adresse innerhalb dieses Subnetzes, um es mit Ihrem DB-Cluster zu verbinden. Wenn keine DB-Subnetzgruppen existieren, erstellt Amazon Aurora eine Standard-Subnetzgruppe, wenn Sie einen DB-Cluster erstellen. Amazon Aurora erstellt und ordnet Ihrer DB-Cluster eine Elastic-Network-Schnittstelle mit dieser IP-Adresse zu. Die DB-Cluster verwendet die Availability Zone, die das Subnetz enthält.

In diesem Schritt erstellen Sie eine DB-Subnetzgruppe und fügen die Subnetze hinzu, die Sie für Ihre VPC erstellt haben.

Schritt 3: Erstellen einer VPC-Sicherheitsgruppe

Vor der DB-Cluster müssen Sie eine VPC-Sicherheitsgruppe erstellen, die Ihrer DB-Cluster zugeordnet wird. Wenn Sie keine VPC-Sicherheitsgruppe erstellen, können Sie die Standardsicherheitsgruppe beim Erstellen einer DB-Cluster verwenden. Eine Anleitung zum Erstellen einer Sicherheitsgruppe für Ihren DB-Cluster finden Sie unter Erstellen einer VPC-Sicherheitsgruppe für einen privaten DB-Cluster, oder unter Control traffic to resources using security groups (Kontrolle des Datenverkehrs zu Ressourcen mithilfe von Sicherheitsgruppen) im Amazon VPC Benutzerhandbuch.

Schritt 4: Erstellen einer DB-Instance in der VPC

In diesem Schritt erstellen Sie eine DB-Cluster und verwenden den VPC-Namen, die DB-Subnetzgruppe und die VPC-Sicherheitsgruppe, die Sie in den vorherigen Schritten erstellt haben.

Weitere Informationen zum Erstellen eines DB-Clusters finden Sie unter Erstellen eines Amazon Aurora-DB Clusters.

Wenn Sie im Abschnitt Konnektivität dazu aufgefordert werden, geben Sie den VPC-Namen, die DB-Subnetzgruppe und die VPC-Sicherheitsgruppe ein.