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. # Richtlinie für den Datenverkehr zwischen Netzwerken MemoryDB verwendet die folgenden Techniken, um Ihre Daten zu sichern und vor unbefugtem Zugriff zu schützen: + **[MemoryDB und Amazon VPC](vpcs.md)**erklärt den Typ der Sicherheitsgruppe, die Sie für Ihre Installation benötigen. + **[MemoryDB-API und VPC-Schnittstellen-Endpunkte ()AWS PrivateLink](memorydb-privatelink.md)**ermöglicht es Ihnen, eine private Verbindung zwischen Ihren VPC- und MemoryDB-API-Endpunkten herzustellen. + **[Identitäts- und Zugriffsmanagement in MemoryDB](iam.md)**Verwenden Sie zum Erteilen und Beschränken von Aktionen von Benutzern, Gruppen und Rollen. # MemoryDB und Amazon VPC Der Amazon Virtual Private Cloud (Amazon VPC)-Service definiert ein virtuelles Netzwerk, das einem herkömmlichen Rechenzentrum sehr ähnlich ist. Wenn Sie eine Virtual Private Cloud (VPC) mit Amazon VPC konfigurieren, können Sie ihren IP-Adressbereich auswählen, Subnetze erstellen und Routentabellen, Netzwerk-Gateways und Sicherheitseinstellungen konfigurieren. Sie können dem virtuellen Netzwerk auch einen Cluster hinzufügen und den Zugriff auf den Cluster mithilfe von Amazon VPC-Sicherheitsgruppen kontrollieren. In diesem Abschnitt wird erklärt, wie Sie einen MemoryDB-Cluster in einer VPC manuell konfigurieren. Diese Informationen richten sich an Benutzer, die ein tieferes Verständnis der Zusammenarbeit von MemoryDB und Amazon VPC wünschen. **Topics** + [ # MemoryDB verstehen und VPCs ](vpcs.mdb.md) + [ # Zugriffsmuster für den Zugriff auf einen MemoryDB-Cluster in einer Amazon VPC ](memorydb-vpc-accessing.md) + [ # Erstellen einer Virtual Private Cloud (VPC) ](VPCs.creatingVPC.md) # MemoryDB verstehen und VPCs MemoryDB ist vollständig in Amazon VPC integriert. Für MemoryDB-Benutzer bedeutet dies Folgendes: + MemoryDB startet Ihren Cluster immer in einer VPC. + Wenn Sie noch nicht damit vertraut sind AWS, wird automatisch eine Standard-VPC für Sie erstellt. + Wenn Sie eine Standard-VPC haben und beim Starten eines Clusters kein Subnetz angeben, wird der Cluster in Ihrer Standard-Amazon-VPC gestartet. Weitere Informationen finden Sie unter [Detecting Your Supported Platforms and Whether You Have a Default VPC](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#detecting-platform). Mit Amazon VPC können Sie ein virtuelles Netzwerk in der AWS Cloud erstellen, das einem herkömmlichen Rechenzentrum sehr ähnlich ist. Sie können Ihre VPC konfigurieren, einschließlich der Auswahl ihres IP-Adressbereichs, der Erstellung von Subnetzen und der Konfiguration von Routentabellen, Netzwerk-Gateways und Sicherheitseinstellungen. MemoryDB verwaltet Software-Upgrades, Patches, Fehlererkennung und Wiederherstellung. ## Überblick über MemoryDB in einer VPC + Eine VPC ist ein isolierter Teil der AWS Cloud, dem ein eigener Block von IP-Adressen zugewiesen wird. + Ein Internet-Gateway verbindet Ihre VPC direkt mit dem Internet und bietet Zugriff auf andere AWS Ressourcen wie Amazon Simple Storage Service (Amazon S3), die außerhalb Ihrer VPC laufen. + Ein Amazon VPC-Subnetz ist ein Segment des IP-Adressbereichs einer VPC, in dem Sie AWS Ressourcen entsprechend Ihren Sicherheits- und Betriebsanforderungen isolieren können. + Eine Amazon VPC-Sicherheitsgruppe kontrolliert den ein- und ausgehenden Datenverkehr für Ihre MemoryDB-Cluster und Amazon-Instances. EC2 + Sie können einen MemoryDB-Cluster im Subnetz starten. Die Knoten haben private IP-Adressen aus dem Adressbereich des Subnetzes. + Sie können EC2 Amazon-Instances auch im Subnetz starten. Jede EC2 Amazon-Instance hat eine private IP-Adresse aus dem Adressbereich des Subnetzes. Die EC2 Amazon-Instance kann eine Verbindung zu jedem Knoten im selben Subnetz herstellen. + Damit eine EC2 Amazon-Instance in Ihrer VPC vom Internet aus erreichbar ist, müssen Sie der Instance eine statische, öffentliche Adresse zuweisen, die als Elastic IP-Adresse bezeichnet wird. ## Voraussetzungen Um einen MemoryDB-Cluster innerhalb einer VPC zu erstellen, muss Ihre VPC die folgenden Anforderungen erfüllen: + Ihre VPC muss nicht dedizierte EC2 Amazon-Instances zulassen. Sie können MemoryDB nicht in einer VPC verwenden, die für Dedicated Instance Tenancy konfiguriert ist. + Für Ihre VPC muss eine Subnetzgruppe definiert werden. MemoryDB verwendet diese Subnetzgruppe, um ein Subnetz und IP-Adressen innerhalb dieses Subnetzes auszuwählen, die Ihren Knoten zugeordnet werden sollen. + Für Ihre VPC muss eine Sicherheitsgruppe definiert werden, oder Sie können den bereitgestellten Standard verwenden. + Die CIDR-Blöcke für jedes Subnetz müssen groß genug sein, um Reserve-IP-Adressen bereitzustellen, die MemoryDB bei Wartungsaktivitäten verwenden kann. ## Weiterleitung und Sicherheit Sie können das Routing in Ihrer VPC so konfigurieren, dass gesteuert wird, wohin der Datenverkehr fließt (z. B. zum Internet-Gateway oder Virtual Private Gateway). Mit einem Internet-Gateway hat Ihre VPC direkten Zugriff auf andere AWS Ressourcen, die nicht in Ihrer VPC laufen. Wenn Sie sich dafür entscheiden, nur ein virtuelles privates Gateway mit einer Verbindung zum lokalen Netzwerk Ihrer Organisation zu verwenden, können Sie Ihren internetgebundenen Datenverkehr über das VPN weiterleiten und lokale Sicherheitsrichtlinien und Firewalls verwenden, um den ausgehenden Datenverkehr zu kontrollieren. In diesem Fall fallen zusätzliche Bandbreitengebühren an, wenn Sie über das Internet auf AWS Ressourcen zugreifen. Sie können Amazon VPC-Sicherheitsgruppen verwenden, um die MemoryDB-Cluster und EC2 Amazon-Instances in Ihrer Amazon VPC zu sichern. Sicherheitsgruppen wirken wie eine Firewall auf der Instance-Ebene, nicht auf der Subnetzebene. **Anmerkung** Wir empfehlen dringend, DNS-Namen zu verwenden, um eine Verbindung zu Ihren Knoten herzustellen, da sich die zugrunde liegende IP-Adresse im Laufe der Zeit ändern kann. ## Amazon VPC-Dokumentation Amazon VPC hat eine eigene Dokumentation, in der das Erstellen und Nutzen Ihrer erklärt wird. Die folgende Tabelle zeigt, wo Sie Informationen in den Amazon VPC-Handbüchern finden. | Beschreibung | Dokumentation | | --- | --- | | Erste Schritte bei der Verwendung von Amazon VPC | [Erste Schritte mit Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) | | So verwenden Sie Amazon VPC über AWS-Managementkonsole | [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/) | | Vollständige Beschreibungen aller Amazon-VPC-Befehle | [ EC2 Amazon-Befehlszeilenreferenz](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/) (die Amazon VPC-Befehle finden Sie in der EC2 Amazon-Referenz) | | Vollständige Beschreibungen der Amazon-VPC-API-Aktionen, -Datentypen und -Fehler | [ EC2 Amazon-API-Referenz](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/) (die Amazon VPC-API-Operationen finden Sie in der EC2 Amazon-Referenz) | | Informationen für den Netzwerkadministrator, der das Gateway an Ihrem Ende einer optionalen IPsec VPN-Verbindung konfigurieren muss | [Was ist AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) | Weitere Informationen zur Amazon Virtual Private Cloud finden Sie unter [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/). # Zugriffsmuster für den Zugriff auf einen MemoryDB-Cluster in einer Amazon VPC MemoryDB unterstützt die folgenden Szenarien für den Zugriff auf einen Cluster in einer Amazon VPC: **Contents** + [ ## Zugreifen auf einen MemoryDB-Cluster, wenn sich dieser und die EC2 Amazon-Instance in derselben Amazon VPC befinden ](#memorydb-vpc-accessing-same-vpc) + [ ## Zugreifen auf einen MemoryDB-Cluster, wenn sich dieser und die EC2 Amazon-Instance in einem anderen Amazon befinden VPCs ](#memorydb-vpc-accessing-different-vpc) + [In verschiedenen VPCs Amazonasgebieten in derselben Region](#memorydb-vpc-accessing-different-vpc-same-region) + [Verwenden von Transit Gateway](#memorydb-vpc-accessing-using-transit-gateway) + [In verschiedenen Amazonasgebieten VPCs in verschiedenen Regionen](#memorydb-vpc-accessing-different-vpc-different-region) + [Verwenden von Transit VPC](#memorydb-vpc-accessing-different-vpc-different-region-using-transit-vpc) + [ ## Zugreifen auf einen MemoryDB-Cluster von einer Anwendung aus, die im Rechenzentrum eines Kunden läuft ](#memorydb-vpc-accessing-data-center) + [Verwenden von VPN-Konnektivität](#memorydb-vpc-accessing-data-center-vpn) + [Verwenden von Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect) ## Zugreifen auf einen MemoryDB-Cluster, wenn sich dieser und die EC2 Amazon-Instance in derselben Amazon VPC befinden Der häufigste Anwendungsfall ist, wenn eine auf einer EC2 Instance bereitgestellte Anwendung eine Verbindung zu einem Cluster in derselben VPC herstellen muss. Der einfachste Weg, den Zugriff zwischen EC2 Instances und Clustern in derselben VPC zu verwalten, ist wie folgt: 1. Erstellen Sie eine VPC-Sicherheitsgruppe für Ihren Cluster. Diese Sicherheitsgruppe kann verwendet werden, um den Zugriff auf die Cluster einzuschränken. Sie können für diese Sicherheitsgruppe beispielsweise eine benutzerdefinierte Regel erstellen, die TCP-Zugriff über den Port, den Sie dem Cluster bei seiner Erstellung zugeordnet haben, und eine IP-Adresse gewährt, mit der Sie auf den Cluster zugreifen. Der Standardport für MemoryDB-Cluster ist. `6379` 1. Erstellen Sie eine VPC-Sicherheitsgruppe für Ihre EC2 Instances (Web- und Anwendungsserver). Diese Sicherheitsgruppe kann bei Bedarf den Zugriff auf die EC2 Instance aus dem Internet über die Routingtabelle der VPC ermöglichen. Sie können beispielsweise Regeln für diese Sicherheitsgruppe festlegen, um den TCP-Zugriff auf die EC2 Instance über Port 22 zu ermöglichen. 1. Erstellen Sie in der Sicherheitsgruppe für Ihren Cluster benutzerdefinierte Regeln, die Verbindungen von der Sicherheitsgruppe aus zulassen, die Sie für Ihre EC2 Instances erstellt haben. Damit wird jedem Mitglied der Sicherheitsgruppe der Zugriff auf die DB-Instances gestattet. **So erstellen Sie eine Regel in einer VPC-Sicherheitsgruppe, die Verbindungen über eine andere Sicherheitsgruppe zulässt** 1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon VPC-Konsole unter [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc). 1. Klicken Sie im linken Navigationsbereich auf **Security Groups**. 1. Wählen oder erstellen Sie eine Sicherheitsgruppe, die Sie für Ihre Cluster verwenden werden. Wählen Sie unter **Inbound Rules (Eingangsregeln)** die Option **Edit Inbound Rules (Eingangsregeln bearbeiten)** und dann **Add Rule (Regeln hinzufügen)**. Diese Sicherheitsgruppe gewährt Mitgliedern einer anderen Sicherheitsgruppe Zugriff. 1. Wählen Sie für **Type** die Option **Custom TCP Rule** aus. 1. Geben Sie für **Port Range** den Port an, den Sie beim Erstellen des Clusters verwendet haben. Der Standardport für MemoryDB-Cluster ist. `6379` 1. Geben Sie in das Feld **Source** die ersten Zeichen der ID der Sicherheitsgruppe ein. Wählen Sie aus der Liste die Sicherheitsgruppe aus, die Sie für Ihre EC2 Amazon-Instances verwenden möchten. 1. Wählen Sie **Save**, wenn Sie fertig sind. ## Zugreifen auf einen MemoryDB-Cluster, wenn sich dieser und die EC2 Amazon-Instance in einem anderen Amazon befinden VPCs Wenn sich Ihr Cluster in einer anderen VPC befindet als die EC2 Instance, die Sie für den Zugriff verwenden, gibt es mehrere Möglichkeiten, auf den Cluster zuzugreifen. Wenn sich der Cluster und die EC2 Instance in verschiedenen, VPCs aber in derselben Region befinden, können Sie VPC-Peering verwenden. Wenn sich der Cluster und die EC2 Instance in unterschiedlichen Regionen befinden, können Sie VPN-Konnektivität zwischen Regionen herstellen. **Topics** + [In verschiedenen VPCs Amazonasgebieten in derselben Region](#memorydb-vpc-accessing-different-vpc-same-region) + [In verschiedenen Amazonasgebieten VPCs in verschiedenen Regionen](#memorydb-vpc-accessing-different-vpc-different-region)   ### Zugreifen auf einen MemoryDB-Cluster, wenn sich dieser und die EC2 Amazon-Instance in einem anderen Amazon VPCs in derselben Region befinden *Cluster, auf den von einer EC2 Amazon-Instance in einer anderen Amazon VPC innerhalb derselben Region zugegriffen wird — VPC Peering Connection* Eine VPC-Peering-Verbindung ist eine Netzwerkverbindung zwischen zwei VPCs , mit der Sie den Verkehr zwischen ihnen mithilfe privater IP-Adressen weiterleiten können. Instances in jeder der VPCs können so miteinander kommunizieren, als befänden sie sich im selben Netzwerk. Sie können eine VPC-Peering-Verbindung zwischen Ihrem eigenen Amazon VPCs oder mit einer Amazon-VPC in einem anderen AWS Konto innerhalb einer einzelnen Region herstellen. Weitere Informationen zum Amazon-VPC-Peering finden Sie in der [VPC-Dokumentation](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html) **So greifen Sie auf einen Cluster in einer anderen Amazon VPC über Peering zu** 1. Stellen Sie sicher, dass die beiden VPCs keinen sich überschneidenden IP-Bereich haben, da Sie sie sonst nicht miteinander verbinden können. 1. Schauen Sie sich die beiden VPCs an. Weitere Informationen finden Sie unter [Erstellen und Akzeptieren einer Amazon-VPC-Peering-Verbindung](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/create-vpc-peering-connection.html). 1. Aktualisieren Sie Ihre Routing-Tabelle. Weitere Informationen finden Sie unter [Aktualisieren der Routing-Tabellen für eine VPC-Peering-Verbindung](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html). 1. Ändern Sie die Sicherheitsgruppe Ihres MemoryDB-Clusters, um eingehende Verbindungen von der Anwendungssicherheitsgruppe in der Peering-VPC zuzulassen. Weitere Informationen finden Sie unter [Verweisen auf Peer-VPC-Sicherheitsgruppen](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-security-groups.html). Beim Zugriff auf einen Cluster über eine Peering-Verbindung fallen zusätzliche Datenübertragungskosten an.   #### Verwenden von Transit Gateway Ein Transit-Gateway ermöglicht es Ihnen, Verbindungen VPCs und VPN-Verbindungen in derselben AWS Region herzustellen und den Verkehr zwischen ihnen weiterzuleiten. Ein Transit-Gateway funktioniert AWS kontenübergreifend, und Sie können AWS Resource Access Manager verwenden, um Ihr Transit-Gateway mit anderen Konten zu teilen. Nachdem Sie ein Transit-Gateway mit einem anderen AWS Konto gemeinsam genutzt haben VPCs , kann der Kontoinhaber dieses Konto mit Ihrem Transit-Gateway verknüpfen. Benutzer in einem der Konten können die Anhang jederzeit löschen. Sie können Multicast auf einem Transit Gateway aktivieren und dann eine Transit Gateway-Multicast-Domain erstellen, mit der Multicast-Datenverkehr von der Multicast-Quelle über VPC-Anhängen, die Sie der Domain zuordnen, an Multicast-Gruppenmitglieder gesendet werden kann. Sie können auch einen Peering-Verbindungsanhang zwischen Transit-Gateways in verschiedenen AWS Regionen erstellen. Auf diese Weise können Sie den Datenverkehr zwischen den Anhängen der Transit Gateways über verschiedene Regionen hinweg leiten. Weitere Informationen finden Sie unter [Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html). ### Zugreifen auf einen MemoryDB-Cluster, wenn sich dieser und die EC2 Amazon-Instance in unterschiedlichen Amazon-Regionen VPCs befinden #### Verwenden von Transit VPC Eine Alternative zur Verwendung von VPC-Peering, eine weitere gängige Strategie für die Verbindung mehrerer, geografisch verteilter VPCs und entfernter Netzwerke, ist die Einrichtung einer Transit-VPC, die als globales Netzwerk-Transitzentrum dient. Eine Transit-VPC vereinfacht die Netzwerkverwaltung und minimiert die Anzahl der Verbindungen, die für die Verbindung mehrerer VPCs und entfernter Netzwerke erforderlich sind. Dieses Design kann Zeit und Aufwand verringern und auch Kosten reduzieren, da es virtuell ohne die herkömmlichen Ausgaben implementiert wird, die beim Einrichten einer physischen Präsenz in einem Co-Location-Transit-Hub oder beim Bereitstellen physischer Netzwerkausstattung anfallen. *Verbindungen zwischen verschiedenen Regionen VPCs herstellen* Sobald die Transit Amazon VPC eingerichtet ist, kann eine Anwendung, die in einer „Spoke“ VPC in einer Region bereitgestellt wird, eine Verbindung zu einem MemoryDB-Cluster in einer „Spoke“ VPC in einer anderen Region herstellen. **So greifen Sie auf einen Cluster in einer anderen VPC in einer anderen AWS Region zu** 1. Stellen Sie eine Transit-VPC-Lösung bereit. Weitere Informationen finden Sie unter [AWS-Transit-Gateway](https://aws.amazon.com/transit-gateway/). 1. Aktualisieren Sie die VPC-Routing-Tabellen in der App und leiten VPCs Sie den Datenverkehr über das VGW (Virtual Private Gateway) und die VPN-Appliance weiter. Im Falle des dynamischen Routing mit Border Gateway Protocol (BGP) werden Ihre Routen möglicherweise automatisch gefüllt. 1. Ändern Sie die Sicherheitsgruppe Ihres MemoryDB-Clusters, um eingehende Verbindungen aus dem IP-Bereich der Anwendungsinstanzen zuzulassen. Beachten Sie, dass Sie in diesem Szenario nicht auf die Sicherheitsgruppe des Anwendungsservers verwiesen können. Beim regionsübergreifenden Zugriff auf einen Cluster entstehen Netzwerklatenzen und fallen zusätzliche, regionsübergreifende Datenübertragungskosten an. ## Zugreifen auf einen MemoryDB-Cluster von einer Anwendung aus, die im Rechenzentrum eines Kunden läuft Ein anderes mögliches Szenario ist eine Hybridarchitektur, bei der Clients oder Anwendungen im Rechenzentrum des Kunden möglicherweise auf einen MemoryDB-Cluster in der VPC zugreifen müssen. Dieses Szenario wird auch unterstützt, vorausgesetzt, dass entweder über VPN oder Direct Connect Konnektivität zwischen der VPC des Kunden und dem Rechenzentrum besteht. **Topics** + [Verwenden von VPN-Konnektivität](#memorydb-vpc-accessing-data-center-vpn) + [Verwenden von Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)   ### Zugriff auf einen MemoryDB-Cluster von einer Anwendung aus, die im Rechenzentrum eines Kunden mithilfe von VPN-Konnektivität ausgeführt wird *Über ein VPN von Ihrem Rechenzentrum aus eine Verbindung zu MemoryDB herstellen* **So greifen Sie auf einen Cluster in einer VPC von einer Anwendung vor Ort über eine VPN-Verbindung zu** 1. Richten Sie VPN-Konnektivität ein, indem Sie ein Hardware Virtual Private Gateway zu Ihrer VPC hinzufügen. Weitere Informationen finden Sie unter [Hinzufügen eines Hardware Virtual Private Gateway zu Ihrer VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html). 1. Aktualisieren Sie die VPC-Routingtabelle für das Subnetz, in dem Ihr MemoryDB-Cluster bereitgestellt wird, um Datenverkehr von Ihrem lokalen Anwendungsserver zuzulassen. Im Falle des dynamischen Routing mit BGP werden Ihre Routen möglicherweise automatisch gefüllt. 1. Ändern Sie die Sicherheitsgruppe Ihres MemoryDB-Clusters, um eingehende Verbindungen von den lokalen Anwendungsservern zuzulassen. Beim Zugriff auf einen Cluster über eine VPN-Verbindung entstehen Netzwerklatenzen und fallen zusätzliche Datenübertragungskosten an.   ### Zugreifen auf einen MemoryDB-Cluster von einer Anwendung aus, die im Rechenzentrum eines Kunden mit Direct Connect ausgeführt wird *Über Direct Connect von Ihrem Rechenzentrum aus eine Verbindung zu MemoryDB herstellen* **So greifen Sie über Direct Connect von einer in Ihrem Netzwerk ausgeführten Anwendung auf einen MemoryDB-Cluster zu** 1. Richten Sie Direct Connect-Konnektivität ein. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html). 1. Ändern Sie die Sicherheitsgruppe Ihres MemoryDB-Clusters, um eingehende Verbindungen von den lokalen Anwendungsservern zuzulassen. Beim Zugriff auf einen Cluster über eine DX-Verbindung können Netzwerklatenzen entstehen und zusätzliche Datenübertragungskosten anfallen. # Erstellen einer Virtual Private Cloud (VPC) In diesem Beispiel erstellen Sie eine virtuelle private Cloud (VPC), die auf dem Amazon VPC-Service basiert, mit einem privaten Subnetz für jede Availability Zone. ## Eine VPC (Konsole) erstellen **So erstellen Sie einen MemoryDB-Cluster in einer Amazon Virtual Private Cloud** 1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Wählen Sie auf dem VPC-Dashboard **Create VPC** (VPC erstellen) aus. 1. Wählen Sie unter **Resources to create** (Zu erstellende Ressourcen) die Option **VPC and more** (VPC und mehr) aus. 1. Wählen Sie unter **Anzahl der Availability Zones (AZs)** die Anzahl der Availability Zones aus, in denen Sie Ihre Subnetze starten möchten. 1. Wählen Sie unter **Number of public subnets** (Anzahl der öffentlichen Subnetze) die Anzahl der öffentlichen Subnetze aus, die Sie zu Ihrer VPC hinzufügen möchten. 1. Wählen Sie unter **Number of private subnets** (Anzahl der privaten Subnetze) die Anzahl der privaten Subnetze aus, die Sie zu Ihrer VPC hinzufügen möchten. **Tipp** Notieren Sie sich Ihre Subnetz-IDs und welches öffentlich und welches privat ist. Sie benötigen diese Informationen später, wenn Sie Ihre Cluster starten und Ihrer Amazon VPC eine EC2 Amazon-Instance hinzufügen. 1. Erstellen Sie eine Amazon-VPC-Sicherheitsgruppe. Sie werden diese Gruppe für Ihren Cluster und Ihre EC2 Amazon-Instance verwenden. 1. Wählen Sie im linken Navigationsbereich von die AWS-Managementkonsole Option **Sicherheitsgruppen** aus. 1. Wählen Sie **Sicherheitsgruppen erstellen** aus. 1. Geben Sie einen Namen und eine Beschreibung für Ihre Sicherheitsgruppe in die entsprechenden Felder ein. Wählen Sie für **VPC** den Bezeichner für Ihre VPC aus. 1. Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Ja, erstellen** aus. 1. Definieren Sie eine Netzwerkeingangsregel für Ihre Sicherheitsgruppe. Diese Regel ermöglicht es Ihnen, über Secure Shell (SSH) eine Verbindung zu Ihrer EC2 Amazon-Instance herzustellen. 1. Klicken Sie im linken Navigationsbereich auf **Security Groups**. 1. Suchen Sie Ihre Sicherheitsgruppe in der Liste und wählen Sie sie aus. 1. Wählen Sie unter **Security Group** die Registerkarte **Inbound** aus. Wählen Sie im Feld **Create a new rule** die Option **SSH** und anschließend **Add Rule** aus. Stellen Sie die folgenden Werte für Ihre neue eingehende Regel ein, um HTTP-Zugriff zuzulassen: + Typ: HTTP + Quelle: 0.0.0.0/0 1. Stellen Sie die folgenden Werte für Ihre neue eingehende Regel ein, um HTTP-Zugriff zuzulassen: + Typ: HTTP + Quelle: 0.0.0.0/0 Wählen Sie **Apply Rule Changes** aus. Jetzt sind Sie bereit, eine [Subnetzgruppe](https://docs.aws.amazon.com/memorydb/latest/devguide/subnetgroups.html) und [einen Cluster in Ihrer VPC zu erstellen](https://docs.aws.amazon.com/memorydb/latest/devguide/getting-started.createcluster.html). # Subnetze und Subnetzgruppen Eine *Subnetzgruppe* ist eine Sammlung von Subnetzen (in der Regel private Subnetze), die Sie für Ihre, in einer Amazon Virtual Private Cloud (VPC)-Umgebung ausgeführten, Cluster festlegen können. Wenn Sie einen Cluster in einer Amazon VPC erstellen, können Sie eine Subnetzgruppe angeben oder die bereitgestellte Standardgruppe verwenden. MemoryDB verwendet diese Subnetzgruppe, um ein Subnetz und IP-Adressen innerhalb dieses Subnetzes auszuwählen, die Ihren Knoten zugeordnet werden sollen. In diesem Abschnitt wird beschrieben, wie Sie Subnetze und Subnetzgruppen erstellen und nutzen, um den Zugriff auf Ihre MemoryDB-Ressourcen zu verwalten. Weitere Informationen zur Verwendung von Subnetzgruppen in einer Amazon-VPC-Umgebung finden Sie unter [Schritt 3: Zugriff auf den Cluster autorisieren](getting-started.md#getting-started.authorizeaccess). **Unterstützte MemoryDB AZ IDs** | Regionsname/Region | Unterstützt AZ IDs | | --- | --- | | Region USA Ost (Ohio) `us-east-2` | `use2-az1, use2-az2, use2-az3` | | Region USA Ost (Nord-Virginia) `us-east-1` | `use1-az1, use1-az2, use1-az4, use1-az5, use1-az6` | | Region USA West (Nordkalifornien) `us-west-1` | `usw1-az1, usw1-az2, usw1-az3` | | Region USA West (Oregon) `us-west-2` | `usw2-az1, usw2-az2, usw2-az3, usw2-az4` | | Region Kanada (Zentral) `ca-central-1` | `cac1-az1, cac1-az2, cac1-az4` | | Region Asien-Pazifik (Hongkong) `ap-east-1` | `ape1-az1, ape1-az2, ape1-az3` | | Region Asien-Pazifik (Mumbai) `ap-south-1` | `aps1-az1, aps1-az2, aps1-az3` | | Region Asien-Pazifik (Tokio) `ap-northeast-1` | `apne1-az1, apne1-az2, apne1-az4` | | Asia Pacific (Seoul) Region `ap-northeast-2` | `apne2-az1, apne2-az2, apne2-az3` | | Region Asien-Pazifik (Singapur) `ap-southeast-1` | `apse1-az1, apse1-az2, apse1-az3` | | Region Asien-Pazifik (Sydney) `ap-southeast-2` | apse2-az1, apse2-az2, apse2-az3 | | Region Europa (Frankfurt) `eu-central-1` | `euc1-az1, euc1-az2, euc1-az3` | | Region Europa (Irland) `eu-west-1` | `euw1-az1, euw1-az2, euw1-az3` | | Region Europa (London) `eu-west-2` | `euw2-az1, euw2-az2, euw2-az3` | | Region Europa (Paris) `eu-west-3` | `euw3-az1, euw3-az2, euw3-az3` | | Region Europa (Stockholm) `eu-north-1` | `eun1-az1, eun1-az2, eun1-az3 ` | | Region Europa (Mailand) `eu-south-1` | `eus1-az1, eus1-az2, eus1-az3 ` | | Region Südamerika (São Paulo) `sa-east-1` | `sae1-az1, sae1-az2, sae1-az3` | | Region China (Peking) `cn-north-1` | `cnn1-az1, cnn1-az2` | | Region China (Ningxia) `cn-northwest-1` | `cnw1-az1, cnw1-az2, cnw1-az3` | | `us-gov-east-1` | `usge1-az1, usge1-az2, usge1-az3` | | `us-gov-west-1` | `usgw1-az1, usgw1-az2, usgw1-az3` | | Region Europa (Spanien) `eu-south-2` | `eus2-az1, eus2-az2, eus2-az3` | **Topics** + [ # MemoryDB und IPV6 ](subnetgroups.ipv6.md) + [ # Erstellen einer Subnetzgruppe ](subnetgroups.creating.md) + [ # Aktualisierung einer Subnetzgruppe ](subnetgroups.modifying.md) + [ # Details zur Subnetzgruppe anzeigen ](subnetgroups.Viewing.md) + [ # Löschen einer Subnetzgruppe ](subnetgroups.deleting.md) # MemoryDB und IPV6 Sie können neue Dual-Stack- und reine IPv6-Cluster mit Valkey- und Redis OSS-Engines erstellen, indem Sie Subnetzgruppen mit Dual-Stack- und reinen IPv6-Subnetzen bereitstellen. Sie können den Netzwerktyp für einen vorhandenen Cluster nicht ändern. Mit dieser Funktion können Sie: + Erstellen Sie reine IPv4-Cluster und Dual-Stack-Cluster in Dual-Stack-Subnetzen. + Erstellen Sie reine IPv6-Cluster in reinen IPv6-Subnetzen. + Erstellen Sie neue Subnetzgruppen, um reine IPv4-, Dual-Stack- und reine IPv6-Subnetze zu unterstützen. + Ändern Sie bestehende Subnetzgruppen, um zusätzliche Subnetze aus der zugrunde liegenden VPC einzubeziehen. + Ändern Sie bestehende Subnetze in Subnetzgruppen + Fügen Sie IPv6 nur Subnetze zu Subnetzgruppen hinzu, für die konfiguriert sind IPv6 + Fügen Sie Subnetzgruppen, für die konfiguriert sind, Subnetze hinzu IPv4 oder verwenden Sie Dual-Stack-Unterstützung IPv4 + Ermitteln Sie alle Knoten im Cluster mit IPv4- ODER IPv6-Adressen mithilfe von Engine-Discovery-Befehlen für Dual-Stack- und IPv6-Cluster. Zu diesen Discovery-Befehlen gehören `redis_info``redis_cluster`, und ähnliche. + Ermitteln Sie die IPv4- und IPv6-Adressen aller Knoten im Cluster mithilfe von DNS-Erkennungsbefehlen für Dual-Stack- und IPv6-Cluster. # Erstellen einer Subnetzgruppe Wenn Sie eine neue Subnetzgruppe erstellen, notieren Sie sich die Anzahl der verfügbaren IP-Adressen. Wenn das Subnetz nur über wenige freie IP-Adressen verfügt, beschränkt dies auch die Anzahl der neuen Knoten, die Sie zu dem Cluster hinzufügen können. Um dieses Problem zu lösen, können Sie einer Subnetzgruppe weitere Subnetze zuweisen, um ausreichend IP-Adressen in der Availability Zone Ihres Clusters bereitzustellen. Danach können Sie dem Cluster weitere Knoten hinzufügen. Die folgenden Verfahren zeigen Ihnen, wie Sie eine Subnetzgruppe mit den Namen `mysubnetgroup` (Konsole) AWS CLI, die und die MemoryDB-API erstellen. ## Erstellen einer Subnetzgruppe (Konsole) Im folgenden Verfahren wird das Erstellen einer Subnetzgruppe (Konsole) erläutert. **Erstellen einer DB-Sicherheitsgruppe (Konsole)** 1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die MemoryDB-Konsole unter. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Wählen Sie im linken Navigationsbereich **Subnet** Groups aus. 1. Klicken Sie auf **Create Subnet Group (Subnetzgruppe ändern)**. 1. Gehen Sie auf der Seite **„Subnetzgruppe erstellen**“ wie folgt vor: 1. Geben Sie im Feld **Name** einen Namen für Ihre Subnetzgruppe ein. Für die Benennung von Clustern gelten die folgenden Einschränkungen: + Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten. + Er muss mit einem Buchstaben beginnen. + Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten. + Er darf nicht mit einem Bindestrich enden. 1. Geben Sie im Feld **Description** eine Beschreibung für Ihre Subnetzgruppe ein. 1. Wählen Sie im Feld **VPC ID** die erstellte Amazon VPC aus. Wenn Sie noch keine erstellt haben, klicken Sie auf die Schaltfläche **VPC erstellen** und folgen Sie den Schritten, um eine zu erstellen. 1. **Wählen Sie **unter Ausgewählte Subnetze** die Availability Zone und die ID Ihres privaten Subnetzes aus und klicken Sie dann auf Auswählen.** 1. Für **Tags** können Sie optional Tags anwenden, um Ihre Subnetze zu durchsuchen und zu filtern oder Ihre Kosten zu verfolgen. AWS 1. Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Erstellen** aus. 1. Klicken Sie in der angezeigten Bestätigungsmeldung auf **Close**. Ihre neue Subnetzgruppe wird in der Liste der **Subnetzgruppen** der MemoryDB-Konsole angezeigt. Unten im Fenster können Sie die Subnetzgruppe auswählen, um Details wie die der Gruppe zugeordneten Subnetze anzuzeigen. ## Erstellen einer Subnetzgruppe (AWS CLI) Geben Sie in einem Befehlszeilenfenster den Befehl `create-subnet-group` ein, um eine Subnetzgruppe zu erstellen. Für Linux, macOS oder Unix: ``` aws memorydb create-subnet-group \ --subnet-group-name mysubnetgroup \ --description "Testing" \ --subnet-ids subnet-53df9c3a ``` Für Windows: ``` aws memorydb create-subnet-group ^ --subnet-group-name mysubnetgroup ^ --description "Testing" ^ --subnet-ids subnet-53df9c3a ``` Die Ausgabe dieses Befehls sieht ähnlich wie folgt aus: ``` { "SubnetGroup": { "Subnets": [ { "Identifier": "subnet-53df9c3a", "AvailabilityZone": { "Name": "us-east-1a" } } ], "VpcId": "vpc-3cfaef47", "Name": "mysubnetgroup", "ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup", "Description": "Testing" } } ``` Weitere Informationen finden Sie im AWS CLI Thema[create-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-subnet-group.html). ## Eine Subnetzgruppe erstellen (MemoryDB-API) Rufen `CreateSubnetGroup` Sie mithilfe der MemoryDB-API mit den folgenden Parametern auf: + `SubnetGroupName=``mysubnetgroup` + `Description=``Testing` + `SubnetIds.member.1=``subnet-53df9c3a` # Aktualisierung einer Subnetzgruppe Sie können die Beschreibung einer Subnetzgruppe aktualisieren oder die Liste der Subnetze ändern, die der Subnetzgruppe IDs zugeordnet sind. Es ist nicht möglich, Subnetz-IDs aus einer Subnetzgruppe zu löschen, wenn das Subnetz derzeit von einem Cluster verwendet wird. Die folgenden Verfahren zeigen Ihnen, wie Sie eine Subnetzgruppe aktualisieren. ## Aktualisierung von Subnetzgruppen (Konsole) **Um eine Subnetzgruppe zu aktualisieren** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die MemoryDB-Konsole unter. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Wählen Sie im linken Navigationsbereich **Subnet** Groups aus. 1. Wählen Sie in der Liste der Subnetzgruppen die gewünschte Subnetzgruppe aus. 1. Die Felder **Name **VPCId****und **Beschreibung** können nicht geändert werden. 1. Klicken Sie im Abschnitt **Ausgewählte Subnetze** auf **Verwalten**, um alle Änderungen an den Availability Zones vorzunehmen, die Sie für die Subnetze benötigen. Klicken Sie auf **Save (Speichern)**, um die Änderungen zu speichern. ## Aktualisierung von Subnetzgruppen (AWS CLI) Verwenden Sie in einer Befehlszeile den Befehl, `update-subnet-group` um eine Subnetzgruppe zu aktualisieren. Für Linux, macOS oder Unix: ``` aws memorydb update-subnet-group \ --subnet-group-name mysubnetgroup \ --description "New description" \ --subnet-ids "subnet-42df9c3a" "subnet-48fc21a9" ``` Für Windows: ``` aws memorydb update-subnet-group ^ --subnet-group-name mysubnetgroup ^ --description "New description" ^ --subnet-ids "subnet-42df9c3a" "subnet-48fc21a9" ``` Die Ausgabe dieses Befehls sieht ähnlich wie folgt aus: ``` { "SubnetGroup": { "VpcId": "vpc-73cd3c17", "Description": "New description", "Subnets": [ { "Identifier": "subnet-42dcf93a", "AvailabilityZone": { "Name": "us-east-1a" } }, { "Identifier": "subnet-48fc12a9", "AvailabilityZone": { "Name": "us-east-1a" } } ], "Name": "mysubnetgroup", "ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup", } } ``` Weitere Informationen finden Sie im AWS CLI Thema [update-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html). ## Aktualisierung von Subnetzgruppen (MemoryDB-API) Rufen `UpdateSubnetGroup` Sie mithilfe der MemoryDB-API mit den folgenden Parametern auf: + `SubnetGroupName=``mysubnetgroup` + Alle anderen Parameter, deren Werte Sie ändern möchten. In diesem Beispiel wird `Description=``New%20description` verwendet, um die Beschreibung der Subnetzgruppe zu ändern. **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateSubnetGroup &Description=New%20description &SubnetGroupName=mysubnetgroup &SubnetIds.member.1=subnet-42df9c3a &SubnetIds.member.2=subnet-48fc21a9 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20141201T220302Z &Version=2014-12-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20141201T220302Z &X-Amz-Expires=20141201T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` **Anmerkung** Wenn Sie eine neue Subnetzgruppe erstellen, notieren Sie sich die Anzahl der verfügbaren IP-Adressen. Wenn das Subnetz nur über wenige freie IP-Adressen verfügt, beschränkt dies auch die Anzahl der neuen Knoten, die Sie zu dem Cluster hinzufügen können. Um dieses Problem zu lösen, können Sie einer Subnetzgruppe weitere Subnetze zuweisen, um ausreichend IP-Adressen in der Availability Zone Ihres Clusters bereitzustellen. Danach können Sie dem Cluster weitere Knoten hinzufügen. # Details zur Subnetzgruppe anzeigen Die folgenden Verfahren zeigen Ihnen, wie Sie Details zu einer Subnetzgruppe anzeigen. ## Details von Subnetzgruppen anzeigen (Konsole) **Um Details einer Subnetzgruppe anzuzeigen (Konsole)** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die MemoryDB-Konsole unter. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Wählen Sie im linken Navigationsbereich **Subnet** Groups aus. 1. Wählen Sie auf der Seite **Subnetzgruppen** die Subnetzgruppe unter **Name aus, oder geben Sie den Namen** der Subnetzgruppe in die Suchleiste ein. 1. Wählen Sie auf der Seite **Subnetzgruppen** die Subnetzgruppe unter **Name aus, oder geben Sie den Namen** der Subnetzgruppe in die Suchleiste ein. 1. Unter **Subnetzgruppeneinstellungen** können Sie den Namen, die Beschreibung, die VPC-ID und den Amazon-Ressourcennamen (ARN) der Subnetzgruppe einsehen. 1. Unter **Subnetze** können Sie die Availability Zones, Subnet IDs - und CIDR-Blöcke der Subnetzgruppe einsehen 1. Unter **Tags** können Sie alle Tags anzeigen, die der Subnetzgruppe zugeordnet sind. ## Details zu Subnetzgruppen anzeigen (AWS CLI) Verwenden Sie in einer Befehlszeile den Befehl, `describe-subnet-groups` um die Details einer bestimmten Subnetzgruppe anzuzeigen. Für Linux, macOS oder Unix: ``` aws memorydb describe-subnet-groups \ --subnet-group-name mysubnetgroup ``` Für Windows: ``` aws memorydb describe-subnet-groups ^ --subnet-group-name mysubnetgroup ``` Die Ausgabe dieses Befehls sieht ähnlich wie folgt aus: ``` {   "subnetgroups": [     {       "Subnets": [         {           "Identifier": "subnet-060cae3464095de6e",            "AvailabilityZone": {             "Name": "us-east-1a"           }         },          {           "Identifier": "subnet-049d11d4aa78700c3",            "AvailabilityZone": {             "Name": "us-east-1c"           }         },          {           "Identifier": "subnet-0389d4c4157c1edb4",            "AvailabilityZone": {             "Name": "us-east-1d"           }         }       ],        "VpcId": "vpc-036a8150d4300bcf2",        "Name": "mysubnetgroup",        "ARN": "arn:aws:memorydb:us-east-1:53791xzzz7620:subnetgroup/mysubnetgroup",        "Description": "test"     }   ] } ``` Um Details zu allen Subnetzgruppen anzuzeigen, verwenden Sie denselben Befehl, jedoch ohne Angabe eines Subnetzgruppennamens. ``` aws memorydb describe-subnet-groups ``` Weitere Informationen finden Sie im AWS CLI Thema. [describe-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html) ## Subnetzgruppen anzeigen (MemoryDB-API) Rufen `DescribeSubnetGroups` Sie mithilfe der MemoryDB-API mit den folgenden Parametern auf: `SubnetGroupName=``mysubnetgroup` **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateSubnetGroup &Description=New%20description &SubnetGroupName=mysubnetgroup &SubnetIds.member.1=subnet-42df9c3a &SubnetIds.member.2=subnet-48fc21a9 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20211801T220302Z &Version=2021-01-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20210801T220302Z &X-Amz-Expires=20210801T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` # Löschen einer Subnetzgruppe Wenn Sie eine Subnetzgruppe nicht mehr benötigen, können Sie sie löschen. Sie können eine Subnetzgruppe, die derzeit von einem Cluster verwendet wird, nicht löschen. Sie können auch eine Subnetzgruppe in einem Cluster mit aktiviertem Multi-AZ nicht löschen, wenn dieser Cluster mit weniger als zwei Subnetzen belässt. Sie müssen zuerst **Multi-AZ** deaktivieren und dann das Subnetz löschen. Das folgende Verfahren zeigt, wie Sie eine Subnetzgruppe löschen. ## Löschen einer Subnetzgruppe (Konsole) **So löschen Sie eine Subnetzgruppe** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die MemoryDB-Konsole unter. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Wählen Sie im linken Navigationsbereich **Subnet** Groups aus. 1. **Wählen Sie in der Liste der Subnetzgruppen die aus, die Sie löschen möchten, klicken Sie auf **Aktionen** und dann auf Löschen.** **Anmerkung** Sie können keine Standard-Subnetzgruppe oder eine, die mit Clustern verknüpft ist, löschen. 1. Der Bestätigungsbildschirm **„Subnetzgruppen löschen**“ wird angezeigt. 1. Um die Subnetzgruppe zu löschen, geben Sie `delete` in das Bestätigungstextfeld ein. Wählen Sie **Cancel (Abbrechen)**, um die Subnetzgruppe zu erhalten. ## Löschen einer Subnetzgruppe (AWS CLI) Rufen Sie mit dem AWS CLI den Befehl **delete-subnet-group** mit dem folgenden Parameter auf: + `--subnet-group-name` *mysubnetgroup* Für Linux, macOS oder Unix: ``` aws memorydb delete-subnet-group \ --subnet-group-name mysubnetgroup ``` Für Windows: ``` aws memorydb delete-subnet-group ^ --subnet-group-name mysubnetgroup ``` Weitere Informationen finden Sie im AWS CLI Thema [delete-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-subnet-group.html). ## Löschen einer Subnetzgruppe (MemoryDB-API) Rufen `DeleteSubnetGroup` Sie mithilfe der MemoryDB-API mit dem folgenden Parameter auf: + `SubnetGroupName=mysubnetgroup` **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=DeleteSubnetGroup &SubnetGroupName=mysubnetgroup &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20210801T220302Z &Version=2021-01-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20210801T220302Z &X-Amz-Expires=20210801T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` Mit diesem Befehl wird keine Ausgabe zurückgegeben. Weitere Informationen finden Sie im Thema MemoryDB-API. [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) # MemoryDB-API und VPC-Schnittstellen-Endpunkte ()AWS PrivateLink *Sie können eine private Verbindung zwischen Ihrer VPC und den Amazon MemoryDB-API-Endpunkten herstellen, indem Sie einen VPC-Schnittstellen-Endpunkt erstellen.* Schnittstellen-Endpunkte werden betrieben von. [AWS PrivateLink](https://aws.amazon.com/privatelink) AWS PrivateLink ermöglicht Ihnen den privaten Zugriff auf MemoryDB-API-Operationen ohne Internet-Gateway, NAT-Gerät, VPN-Verbindung oder AWS Direct Connect-Verbindung. Instances in Ihrer VPC benötigen keine öffentlichen IP-Adressen, um mit MemoryDB-API-Endpunkten zu kommunizieren. Ihre Instances benötigen auch keine öffentlichen IP-Adressen, um die verfügbaren MemoryDB-API-Operationen nutzen zu können. Der Verkehr zwischen Ihrer VPC und MemoryDB verlässt das Amazon-Netzwerk nicht. Jeder Schnittstellenendpunkt wird durch eine oder mehrere Elastic Network-Schnittstellen in Ihren Subnetzen dargestellt. Weitere Informationen zu Elastic Network-Schnittstellen finden Sie unter [Elastic Network-Schnittstellen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) im *Amazon EC2 Benutzerhandbuch.* + Weitere Informationen zu VPC-Endpunkten finden Sie unter [Interface VPC Endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) im *Amazon* VPC-Benutzerhandbuch. + [Weitere Informationen zu MemoryDB-API-Vorgängen finden Sie unter MemoryDB-API-Operationen.](https://docs.aws.amazon.com/memorydb/latest/APIReference/Welcome.html) Wenn Sie nach dem Erstellen eines VPC-Schnittstellen-Endpunkts [private DNS-Hostnamen](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) für den Endpunkt aktivieren, wird dies der Standard-MemoryDB-Endpunkt sein (https://memorydb. *Region*.amazonaws.com) wird zu Ihrem VPC-Endpunkt aufgelöst. Wenn Sie keine privaten DNS-Hostnamen aktiviert haben, stellt Amazon VPC einen DNS-Endpunktnamen bereit, den Sie im folgenden Format verwenden können: ``` VPC_Endpoint_ID.memorydb.Region.vpce.amazonaws.com ``` Weitere Informationen finden Sie unter [Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) im *Amazon-VPC-Benutzerhandbuch*. MemoryDB unterstützt Aufrufe aller [API-Aktionen in Ihrer VPC](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html). **Anmerkung** Private DNS-Hostnamen können nur für einen VPC-Endpunkt in der VPC aktiviert werden. Wenn Sie einen zusätzlichen VPC-Endpunkt erstellen möchten, sollte der private DNS-Hostname dafür deaktiviert werden. ## Überlegungen zu VPC-Endpunkten Bevor Sie einen Schnittstellen-VPC-Endpunkt für MemoryDB-API-Endpunkte einrichten, stellen Sie sicher, dass Sie die [Eigenschaften und Einschränkungen der Schnittstellenendpunkte](https://docs.aws.amazon.com/vpc/latest/privatelink/endpoint-services-overview.html) im *Amazon* VPC-Benutzerhandbuch lesen. Alle MemoryDB-API-Operationen, die für die Verwaltung von MemoryDB-Ressourcen relevant sind, sind über Ihre VPC verfügbar unter. AWS PrivateLink VPC-Endpunktrichtlinien werden für MemoryDB-API-Endpunkte unterstützt. Standardmäßig ist der vollständige Zugriff auf MemoryDB-API-Operationen über den Endpunkt zulässig. Weitere Informationen finden Sie unter [Steuerung des Zugriffs auf Services mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) im *Amazon-VPC-Benutzerhandbuch*. ### Erstellen eines VPC-Schnittstellen-Endpunkts für die MemoryDB-API Sie können einen VPC-Endpunkt für die MemoryDB-API entweder mit der Amazon VPC-Konsole oder mit dem erstellen. AWS CLI Weitere Informationen finden Sie unter [Erstellung eines Schnittstellenendpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) im *Benutzerhandbuch für Amazon VPC*. Nachdem Sie einen Schnittstellen-VPC-Endpunkt erstellt haben, können Sie private DNS-Hostnamen für den Endpunkt aktivieren. Wenn Sie dies tun, der Standard-MemoryDB-Endpunkt (https://memorydb. *Region*.amazonaws.com) wird zu Ihrem VPC-Endpunkt aufgelöst. Weitere Informationen finden Sie unter [Zugriff auf einen Service über einen Schnittstellenendpunkt](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) im *Benutzerhandbuch für Amazon VPC*. ### Erstellen einer VPC-Endpunktrichtlinie für die Amazon MemoryDB-API Sie können Ihrem VPC-Endpunkt eine Endpunktrichtlinie hinzufügen, die den Zugriff auf die MemoryDB-API steuert. Die Richtlinie legt Folgendes fest: + Prinzipal, der die Aktionen ausführen kann. + Aktionen, die ausgeführt werden können + Die Ressourcen, für die Aktionen ausgeführt werden können. Weitere Informationen finden Sie unter [Steuerung des Zugriffs auf Services mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) im *Amazon-VPC-Benutzerhandbuch*. **Example VPC-Endpunktrichtlinie für MemoryDB-API-Aktionen** Im Folgenden finden Sie ein Beispiel für eine Endpunktrichtlinie für die MemoryDB-API. Wenn diese Richtlinie an einen Endpunkt angehängt ist, gewährt sie allen Prinzipalen auf allen Ressourcen Zugriff auf die aufgelisteten MemoryDB-API-Aktionen. ``` { "Statement": [{ "Principal": "*", "Effect": "Allow", "Action": [ "memorydb:CreateCluster", "memorydb:UpdateCluster", "memorydb:CreateSnapshot" ], "Resource": "*" }] } ``` **Example VPC-Endpunktrichtlinie, die jeglichen Zugriff von einem bestimmten Konto aus verweigert AWS** Die folgende VPC-Endpunktrichtlinie verweigert dem AWS Konto *123456789012* jeglichen Zugriff auf Ressourcen, die den Endpunkt verwenden. Die Richtlinie erlaubt alle Aktionen von anderen Konten. ``` { "Statement": [{ "Action": "*", "Effect": "Allow", "Resource": "*", "Principal": "*" }, { "Action": "*", "Effect": "Deny", "Resource": "*", "Principal": { "AWS": [ "123456789012" ] } } ] } ``` # Common Vulnerabilities and Exposures (CVE): Sicherheitslücken, die in MemoryDB behoben wurden Common Vulnerabilities and Exposures (CVE) ist eine Liste von Einträgen für öffentlich bekannte Cybersicherheitsschwachstellen. Jeder Eintrag ist ein Link, der eine Identifikationsnummer, eine Beschreibung und mindestens eine öffentliche Referenz enthält. Auf dieser Seite finden Sie eine Liste von Sicherheitslücken, die in MemoryDB behoben wurden. Wir empfehlen, immer auf die neuesten MemoryDB-Versionen zu aktualisieren, um vor bekannten Sicherheitslücken geschützt zu sein. MemoryDB macht die PATCH-Komponente verfügbar. PATCH-Versionen sind für abwärtskompatible Bugfixes, Sicherheitskorrekturen und nicht funktionale Änderungen vorgesehen. Anhand der folgenden Tabelle können Sie überprüfen, ob eine bestimmte Version von MemoryDB einen Fix für eine bestimmte Sicherheitslücke enthält. Wenn Ihr MemoryDB-Cache auf ein Service-Update wartet, ist er möglicherweise anfällig für eine der unten aufgeführten Sicherheitslücken. Wir empfehlen Ihnen, das Service-Update zu installieren. Weitere Informationen zu den unterstützten Versionen der MemoryDB-Engine und zur Durchführung eines Upgrades finden Sie unter. [Engine-Versionen](engine-versions.md) **Anmerkung** Wenn ein CVE in einer MemoryDB-Version adressiert wird, bedeutet dies, dass es auch in den neueren Versionen adressiert wird. Ein Sternchen (\$1) in der folgenden Tabelle gibt an, dass Sie das neueste Service-Update für den MemoryDB-Cluster installiert haben müssen, auf dem die angegebene Version ausgeführt wird, um die Sicherheitslücke zu schließen. Weitere Informationen darüber, wie Sie überprüfen können, ob Sie das neueste Dienstupdate für die MemoryDB-Version installiert haben, auf der Ihr Cluster ausgeführt wird, finden Sie unter. [Verwalten der Service-Updates](managing-updates.md) | MemoryDB-Version | CVEs Adressiert | | --- | --- | | Valkey 7.3 und alle früheren Versionen von Valkey Redis OSS 7.1 und alle früheren Versionen von Redis OSS | [CVE-2025-49844 \$1, CVE-2025-46817 \$1, CVE-2025-46818](https://www.cve.org/CVERecord?id=CVE-2025-49844) [https://www.cve.org/CVERecord?id=CVE-2025-46817](https://www.cve.org/CVERecord?id=CVE-2025-46817) | | Valkey 7.2 und 7.3 | [CVE-2025-21607 \$1, CVE-2025-21605 \$1, CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21607) [\$1, CVE-2024-31227 \$1, CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449) | | Tal 7.2.7 | [CVE-2024-51741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-51741) | | Redis OSS 7.1 und 6.2 | [CVE-2025-21605 \$1, CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227) | | Redis OS 7.0.7 | [CVE-2023-41056 \$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056) | | Redis OS 6.2.7 | [CVE-2024-46981](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46981) | | Redis OS 6.2.6 | [CVE-2023-24834 \$1, CVE-2022-35977 \$1, CVE-2023-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24834) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35977](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35977) [CVE-2023-45145](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45145): Beachten Sie, dass dieser CVE in Redis OSS 6.2 und 7.0 behoben wurde, aber nicht in Redis OSS 7.1. | | Redis OSS 6.0.5 | [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24735](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24735) |