Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Confidentialité du trafic inter-réseau
MemoryDB utilise les techniques suivantes pour sécuriser vos données et les protéger contre tout accès non autorisé :
+ **[MemoryDB et Amazon VPC](vpcs.md)** explique le type de groupe de sécurité dont vous avez besoin pour votre installation.
+ **[API MemoryDB et points de terminaison VPC d'interface ()AWS PrivateLink](memorydb-privatelink.md)**vous permet d'établir une connexion privée entre votre VPC et les points de terminaison de l'API MemoryDB.
+ **[Gestion des identités et des accès dans MemoryDB](iam.md)** pour attribuer et limiter les actions des utilisateurs, groupes et rôles.
# MemoryDB et Amazon VPC
Le service Amazon Amazon Virtual Private Cloud (Amazon VPC) définit un réseau virtuel qui ressemble de près à un centre de données classique. Lorsque vous configurez un cloud privé virtuel (VPC) avec Amazon VPC, vous pouvez sélectionner sa plage d'adresses IP, créer des sous-réseaux et configurer des tables de routage, des passerelles réseau et des paramètres de sécurité. Vous pouvez également ajouter un cluster au réseau virtuel et contrôler l'accès au cluster à l'aide des groupes de sécurité Amazon VPC.
Cette section explique comment configurer manuellement un cluster MemoryDB dans un VPC. Ces informations sont destinées aux utilisateurs qui souhaitent mieux comprendre comment MemoryDB et Amazon VPC fonctionnent ensemble.
**Topics**
+ [Comprendre MemoryDB et VPCs](vpcs.mdb.md)
+ [Modèles d'accès pour accéder à un cluster MemoryDB dans un Amazon VPC](memorydb-vpc-accessing.md)
+ [Création d'un Virtual Private Cloud (VPC)](VPCs.creatingVPC.md)
# Comprendre MemoryDB et VPCs
MemoryDB est entièrement intégré à Amazon VPC. Pour les utilisateurs de MemoryDB, cela signifie ce qui suit :
+ MemoryDB lance toujours votre cluster dans un VPC.
+ Si vous êtes nouveau dans ce AWS domaine, un VPC par défaut sera automatiquement créé pour vous.
+ Si vous disposez d'un VPC par défaut et si vous ne spécifiez pas de sous-réseau lors du lancement d'un cluster, ce dernier est lancé dans votre Amazon VPC par défaut.
Pour plus d'informations, consultez la page [Comment identifier vos plateformes prises en charge et déterminer si vous disposez d'un VPC par défaut ?](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#detecting-platform).
Avec Amazon VPC, vous pouvez créer un réseau virtuel dans le AWS cloud qui ressemble beaucoup à un centre de données traditionnel. Vous pouvez configurer votre VPC, notamment en sélectionnant sa plage d'adresses IP, en créant des sous-réseaux et en configurant des tables de routage, des passerelles réseau et des paramètres de sécurité.
MemoryDB gère les mises à niveau logicielles, les correctifs, la détection des défaillances et la restauration.
## Présentation de MemoryDB dans un VPC
+ Un VPC est une partie isolée du AWS cloud à laquelle est attribué son propre bloc d'adresses IP.
+ Une passerelle Internet connecte votre VPC directement à Internet et donne accès à d'autres AWS ressources, telles qu'Amazon Simple Storage Service (Amazon S3), qui s'exécutent en dehors de votre VPC.
+ Un sous-réseau Amazon VPC est un segment de la plage d'adresses IP d'un VPC dans lequel vous pouvez isoler les AWS ressources en fonction de vos besoins opérationnels et de sécurité.
+ Un groupe de sécurité Amazon VPC contrôle le trafic entrant et sortant pour vos clusters MemoryDB et vos instances Amazon. EC2
+ Vous pouvez lancer un cluster MemoryDB dans le sous-réseau. Les nœuds possèdent des adresses IP privées issues de la plage d'adresses du sous-réseau.
+ Vous pouvez également lancer des EC2 instances Amazon dans le sous-réseau. Chaque EC2 instance Amazon possède une adresse IP privée issue de la plage d'adresses du sous-réseau. L' EC2 instance Amazon peut se connecter à n'importe quel nœud du même sous-réseau.
+ Pour qu'une EC2 instance Amazon de votre VPC soit accessible depuis Internet, vous devez lui attribuer une adresse publique statique appelée adresse IP élastique.
## Prérequis
Pour créer un cluster MemoryDB au sein d'un VPC, celui-ci doit répondre aux exigences suivantes :
+ Votre VPC doit autoriser les instances Amazon EC2 non dédiées. Vous ne pouvez pas utiliser MemoryDB dans un VPC configuré pour la location d'instance dédiée.
+ Un groupe de sous-réseaux doit être défini pour votre VPC. MemoryDB utilise ce groupe de sous-réseaux pour sélectionner un sous-réseau et les adresses IP de ce sous-réseau à associer à vos nœuds.
+ Un groupe de sécurité doit être défini pour votre VPC, ou vous pouvez utiliser le groupe par défaut fourni.
+ Les blocs CIDR de chaque sous-réseau doivent être suffisamment grands pour fournir des adresses IP de réserve à MemoryDB à utiliser lors des activités de maintenance.
## Routage et sécurité
Vous pouvez configurer le routage dans votre VPC pour contrôler l'endroit où le trafic circule (par exemple, vers la passerelle Internet ou la passerelle privée virtuelle). Avec une passerelle Internet, votre VPC a un accès direct à d'autres AWS ressources qui ne s'exécutent pas dans votre VPC. Si vous choisissez de n'avoir qu'une passerelle privée virtuelle connectée au réseau local de votre entreprise, vous pouvez acheminer votre trafic Internet via le VPN et utiliser les politiques de sécurité locales et le pare-feu pour contrôler la sortie. Dans ce cas, vous devez payer des frais de bande passante supplémentaires lorsque vous accédez à AWS des ressources via Internet.
Vous pouvez utiliser les groupes de sécurité Amazon VPC pour sécuriser les clusters MemoryDB et les instances Amazon de votre Amazon EC2 VPC. Les groupes de sécurité agissent comme un pare-feu au niveau de l'instance, et non au niveau du sous-réseau.
**Note**
Nous vous recommandons vivement d'utiliser des noms DNS pour vous connecter à vos nœuds, car l'adresse IP sous-jacente peut changer au fil du temps.
## Documentation Amazon VPC
Amazon VPC a son propre ensemble de documentation pour décrire comment créer et utiliser votre Amazon VPC. Le tableau suivant indique où trouver des informations dans les guides Amazon VPC.
| Description | Documentation |
| --- | --- |
| Commencer à utiliser Amazon VPC | [Mise en route avec Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) |
| Comment utiliser Amazon VPC via AWS Management Console | [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/) |
| Description complète de toutes les commandes Amazon VPC | [Amazon EC2 Command Line Reference](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/) (les commandes Amazon VPC se trouvent dans la référence Amazon EC2 ) |
| Descriptions complètes des opérations de l'API Amazon VPC, des types de données et des erreurs | [Amazon EC2 API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/) (les opérations de l'API Amazon VPC se trouvent dans la référence Amazon EC2 ) |
| Informations destinées à l'administrateur réseau qui doit configurer la passerelle à votre extrémité d'une connexion IPsec VPN optionnelle | [Qu'est-ce qu' AWS Site-to-Site un VPN ?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) |
Pour plus d'informations sur Amazon Virtual Private Cloud, veuillez consulter [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/).
# Modèles d'accès pour accéder à un cluster MemoryDB dans un Amazon VPC
MemoryDB prend en charge les scénarios suivants pour accéder à un cluster dans un Amazon VPC :
**Contents**
+ [Accès à un cluster MemoryDB lorsque celui-ci et l' EC2 instance Amazon se trouvent dans le même Amazon VPC](#memorydb-vpc-accessing-same-vpc)
+ [Accès à un cluster MemoryDB lorsque celui-ci et l' EC2 instance Amazon se trouvent dans un environnement Amazon différent VPCs](#memorydb-vpc-accessing-different-vpc)
+ [Dans un autre Amazon VPCs de la même région](#memorydb-vpc-accessing-different-vpc-same-region)
+ [Utilisation de Transit Gateway](#memorydb-vpc-accessing-using-transit-gateway)
+ [Dans différents Amazon VPCs , dans différentes régions](#memorydb-vpc-accessing-different-vpc-different-region)
+ [Utilisation de VPC en transit](#memorydb-vpc-accessing-different-vpc-different-region-using-transit-vpc)
+ [Accès à un cluster MemoryDB à partir d'une application exécutée dans le centre de données d'un client](#memorydb-vpc-accessing-data-center)
+ [Via une connectivité VPN](#memorydb-vpc-accessing-data-center-vpn)
+ [Via Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)
## Accès à un cluster MemoryDB lorsque celui-ci et l' EC2 instance Amazon se trouvent dans le même Amazon VPC
Le cas d'utilisation le plus courant est celui où une application déployée sur une EC2 instance doit se connecter à un cluster dans le même VPC.
La méthode la plus simple pour gérer l'accès entre les EC2 instances et les clusters d'un même VPC consiste à effectuer les opérations suivantes :
1. Créez un groupe de sécurité VPC pour votre cluster. Ce groupe de sécurité peut être utilisé pour restreindre l'accès aux clusters. Par exemple, vous pouvez créer une règle personnalisée pour ce groupe de sécurité, qui autorise l'accès TCP à l'aide du port que vous avez attribué au cluster lorsque vous l'avez créé et une adresse IP que vous utiliserez pour accéder au cluster.
Le port par défaut pour les clusters MemoryDB est. `6379`
1. Créez un groupe de sécurité VPC pour vos EC2 instances (serveurs Web et d'applications). Ce groupe de sécurité peut, si nécessaire, autoriser l'accès à l' EC2 instance depuis Internet via la table de routage du VPC. Par exemple, vous pouvez définir des règles sur ce groupe de sécurité pour autoriser l'accès TCP à l' EC2 instance via le port 22.
1. Créez des règles personnalisées dans le groupe de sécurité de votre cluster qui autorisent les connexions à partir du groupe de sécurité que vous avez créé pour vos EC2 instances. N'importe quel membre du groupe de sécurité peut ainsi accéder aux clusters.
**Pour créer une règle dans un groupe de sécurité VPC qui autorise les connexions à partir d'un autre groupe de sécurité**
1. [Connectez-vous à la console de AWS gestion et ouvrez la console Amazon VPC à https://console.aws.amazon.com l'adresse /vpc.](https://console.aws.amazon.com/vpc)
1. Dans le volet de navigation de gauche, sélectionnez ** Security Groups**.
1. Sélectionnez ou créez un groupe de sécurité que vous utiliserez pour vos clusters. Sous **Règles entrantes**, sélectionnez **Modifier les règles entrantes**, puis **Ajouter une règle**. Ce groupe de sécurité autorisera l'accès aux membres d'un autre groupe de sécurité.
1. Dans **Type**, choisissez **Règle TCP personnalisée**.
1. Pour **Plage de ports**, spécifiez le port utilisé lors de la création de votre cluster.
Le port par défaut pour les clusters MemoryDB est. `6379`
1. Dans le champ **Source**, saisissez l'ID de votre groupe de sécurité. Dans la liste, sélectionnez le groupe de sécurité que vous utiliserez pour vos EC2 instances Amazon.
1. Choisissez **Enregistrer** lorsque vous avez terminé.
## Accès à un cluster MemoryDB lorsque celui-ci et l' EC2 instance Amazon se trouvent dans un environnement Amazon différent VPCs
Lorsque votre cluster se trouve dans un VPC différent de l' EC2 instance que vous utilisez pour y accéder, il existe plusieurs manières d'accéder au cluster. Si le cluster et l' EC2 instance se trouvent dans une région différente VPCs mais dans la même région, vous pouvez utiliser le peering VPC. Si le cluster et l' EC2 instance se trouvent dans des régions différentes, vous pouvez créer une connectivité VPN entre les régions.
**Topics**
+ [Dans un autre Amazon VPCs de la même région](#memorydb-vpc-accessing-different-vpc-same-region)
+ [Dans différents Amazon VPCs , dans différentes régions](#memorydb-vpc-accessing-different-vpc-different-region)
### Accès à un cluster MemoryDB lorsque celui-ci et l' EC2 instance Amazon se trouvent dans un Amazon différent VPCs dans la même région
*Cluster accessible par une EC2 instance Amazon dans un autre Amazon VPC au sein de la même région - VPC Peering Connection*
Une connexion d'appairage VPC est une connexion réseau entre deux entités VPCs qui vous permet d'acheminer le trafic entre elles à l'aide d'adresses IP privées. Les instances des deux VPC peuvent communiquer entre elles comme si elles se trouvaient dans le même réseau. Vous pouvez créer une connexion de peering VPC entre votre propre Amazon ou avec un Amazon VPCs VPC d'un autre AWS compte au sein d'une même région. Pour en savoir plus sur l'appairage d'Amazon VPC, veuillez consulter la [documentation VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html).
**Pour accéder à un cluster dans un Amazon VPC différent via l'appairage**
1. Assurez-vous que les deux adresses IP VPCs ne se chevauchent pas, sinon vous ne pourrez pas les comparer.
1. Regardez les deux VPCs. Pour de plus amples informations, veuillez consulter [Création et acceptation d'une connexion d'appairage d'Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/create-vpc-peering-connection.html).
1. Mettez à jour votre table de routage. Pour de plus amples informations, veuillez consulter [Mise à jour de vos tables de routage pour une connexion d'appairage de VPC](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html).
1. Modifiez le groupe de sécurité de votre cluster MemoryDB pour autoriser les connexions entrantes depuis le groupe de sécurité des applications dans le VPC homologue. Pour de plus amples informations, veuillez consulter [Référencer des groupes de sécurité du VPC pair](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-security-groups.html).
L'accès à un cluster sur une connexion d'appairage entraînera des frais de transfert de données supplémentaires.
#### Utilisation de Transit Gateway
Une passerelle de transit vous permet de connecter VPCs des connexions VPN dans la même AWS région et d'acheminer le trafic entre elles. Une passerelle de transit fonctionne sur plusieurs AWS comptes, et vous pouvez utiliser AWS Resource Access Manager pour partager votre passerelle de transit avec d'autres comptes. Une fois que vous avez partagé une passerelle de transit avec un autre AWS compte, le titulaire du compte peut l'associer VPCs à votre passerelle de transit. Un utilisateur de l'un des comptes peut supprimer l'attachement à tout moment.
Vous pouvez activer la multicast sur une passerelle de transit, puis créer un domaine multicast de passerelle de transit qui autorise l'envoi du trafic multicast à partir de votre source multicast vers des membres de groupe multicast sur des attachements de VPC que vous associez au domaine.
Vous pouvez également créer une pièce jointe de connexion d'appairage entre les passerelles de transport en commun de différentes AWS régions. Cela vous permet d'acheminer le trafic entre les attachements des passerelles de transit dans différentes régions.
Pour plus d'informations, consultez [Passerelles de transit](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html).
### Accès à un cluster MemoryDB lorsque celui-ci et l' EC2 instance Amazon se trouvent dans des régions différentes d'Amazon VPCs
#### Utilisation de VPC en transit
Une alternative à l'utilisation du peering VPC, une autre stratégie courante pour connecter plusieurs réseaux distants VPCs et géographiquement dispersés consiste à créer un VPC de transit faisant office de centre de transit du réseau mondial. Un VPC de transit simplifie la gestion du réseau et minimise le nombre de connexions nécessaires pour connecter plusieurs réseaux VPCs distants. Cette structure permet de gagner du temps et de l'énergie, ainsi que de réduire les coûts. Elle est en effet implémentée virtuellement et évite donc les dépenses traditionnelles liées à l'implantation physique dans un hub de transit de colocalisation ou au déploiement d'un matériel réseau physique.
*Connexion entre VPCs différentes régions*
Une fois le VPC Transit Amazon établi, une application déployée dans un VPC « relais » d'une région peut se connecter à un cluster MemoryDB d'un VPC « relais » d'une autre région.
**Pour accéder à un cluster dans un autre VPC au sein d'une autre région AWS**
1. Déployez une solution VPC de transit. Pour plus d'informations, veuillez consulter [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/).
1. Mettez à jour les tables de routage VPC dans l'application et VPCs pour acheminer le trafic via le VGW (Virtual Private Gateway) et l'appliance VPN. En cas de routage dynamique avec le BGP (Border Gateway Protocol), vos routes peuvent être automatiquement propagées.
1. Modifiez le groupe de sécurité de votre cluster MemoryDB pour autoriser les connexions entrantes depuis la plage d'adresses IP des instances d'application. Notez que vous ne pourrez pas référencer le groupe de sécurité du serveur de l'application dans ce scénario.
Le fait d'accéder à un cluster d'une région à une autre entraînera des latences réseau et des frais de transfert de données entre régions supplémentaires.
## Accès à un cluster MemoryDB à partir d'une application exécutée dans le centre de données d'un client
Un autre scénario possible est une architecture hybride dans laquelle les clients ou les applications du centre de données du client peuvent avoir besoin d'accéder à un cluster MemoryDB dans le VPC. Ce scénario est également pris en charge, à condition qu'une connectivité existe entre le VPC d'un client et le centre de données, via un VPN ou via Direct Connect.
**Topics**
+ [Via une connectivité VPN](#memorydb-vpc-accessing-data-center-vpn)
+ [Via Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)
### Accès à un cluster MemoryDB à partir d'une application exécutée dans le centre de données d'un client à l'aide de la connectivité VPN
*Connexion à MemoryDB depuis votre centre de données via un VPN*
**Pour accéder à un cluster dans un VPC à partir d'une application sur site via une connexion VPN**
1. Etablissez une connectivité VPN en ajoutant une passerelle réseau privé virtuel Hardware vers votre VPC. Pour de plus amples informations, veuillez consulter [Ajout d'une passerelle réseau privé virtuel Hardware à votre VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html).
1. Mettez à jour la table de routage VPC du sous-réseau sur lequel votre cluster MemoryDB est déployé afin d'autoriser le trafic provenant de votre serveur d'applications sur site. En cas de routage dynamique avec le BGP (Border Gateway Protocol), vos routes peuvent être automatiquement propagées.
1. Modifiez le groupe de sécurité de votre cluster MemoryDB pour autoriser les connexions entrantes depuis les serveurs d'applications locaux.
Le fait d'accéder à un cluster via une connexion VPN entraînera des latences réseau et des frais de transfert de données supplémentaires.
### Accès à un cluster MemoryDB à partir d'une application exécutée dans le centre de données d'un client à l'aide de Direct Connect
*Connexion à MemoryDB depuis votre centre de données via Direct Connect*
**Pour accéder à un cluster MemoryDB à partir d'une application exécutée sur votre réseau à l'aide de Direct Connect**
1. Etablissez une connectivité Direct Connect. Pour plus d'informations, voir [Getting Started with AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html).
1. Modifiez le groupe de sécurité de votre cluster MemoryDB pour autoriser les connexions entrantes depuis les serveurs d'applications locaux.
Le fait d'accéder à un cluster via une connexion DX peut entraîner des latences réseau et des frais de transfert de données supplémentaires.
# Création d'un Virtual Private Cloud (VPC)
Dans cet exemple, vous créez un cloud privé virtuel (VPC) basé sur le service Amazon VPC avec un sous-réseau privé pour chaque zone de disponibilité.
## Création d'un VPC (console)
**Pour créer un cluster MemoryDB dans un Amazon Virtual Private Cloud**
1. Connectez-vous à la console AWS de gestion et ouvrez la console Amazon VPC à l'adresse. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)
1. Dans le tableau de bord VPC, choisissez **Create VPC** (Créer un VPC).
1. Sous **Resources to create** (Ressources à créer), choisissez **VPC and more** (VPC et autres).
1. Sous **Nombre de zones de disponibilité (AZs)**, choisissez le nombre de zones de disponibilité dans lesquelles vous souhaitez lancer vos sous-réseaux.
1. Sous **Number of public subnets** (Nombre de sous-réseaux publics), choisissez le nombre de sous-réseaux publics que vous voulez ajouter à votre VPC.
1. Sous **Number of private subnets** (Nombre de sous-réseaux privés), choisissez le nombre de sous-réseaux privés que vous voulez ajouter à votre VPC.
**Astuce**
Notez les identifiants de vos sous-réseaux, et notez lesquels sont publics et privés. Vous aurez besoin de ces informations ultérieurement lorsque vous lancerez vos clusters et ajouterez une EC2 instance Amazon à votre Amazon VPC.
1. Créez un groupe de sécurité Amazon VPC. Vous utiliserez ce groupe pour votre cluster et votre EC2 instance Amazon.
1. Dans le volet de navigation gauche du AWS Management Console, choisissez **Security Groups**.
1. Sélectionnez **Create Security Group** (Créer un groupe de sécurité).
1. Entrez un nom et une description pour votre groupe de sécurité dans les cases correspondantes. Pour **VPC**, choisissez l'identifiant de votre VPC.
1. Lorsque les paramètres vous conviennent, choisissez **Yes, Create**.
1. Définissez une règle de trafic entrant réseau pour votre groupe de sécurité. Cette règle vous permettra de vous connecter à votre EC2 instance Amazon à l'aide de Secure Shell (SSH).
1. Dans le volet de navigation de gauche, sélectionnez ** Security Groups**.
1. Recherchez votre groupe de sécurité dans la liste, puis sélectionnez-le.
1. Sous **Security Group**, choisissez l'onglet **Inbound**. Dans la zone **Create a new rule**, choisissez **SSH**, puis **Add Rule**.
Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise HTTP à accéder à :
+ Type : HTTP
+ Source : 0.0.0.0/0
1. Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise HTTP à accéder à :
+ Type : HTTP
+ Source : 0.0.0.0/0
Choisissez **Apply Rule Changes**.
Vous êtes maintenant prêt à créer un [groupe de sous-réseaux](https://docs.aws.amazon.com/memorydb/latest/devguide/subnetgroups.html) et [un cluster](https://docs.aws.amazon.com/memorydb/latest/devguide/getting-started.createcluster.html) dans votre VPC.
# Sous-réseaux et groupes de sous-réseaux
Un *groupe de sous-réseaux* est un ensemble de sous-réseaux (généralement privés) que vous pouvez utiliser pour vos clusters fonctionnant dans un environnement Amazon Virtual Private Cloud (VPC).
Lorsque vous créez un cluster dans un Amazon VPC, vous pouvez spécifier un groupe de sous-réseaux ou utiliser celui fourni par défaut. MemoryDB utilise ce groupe de sous-réseaux pour choisir un sous-réseau et les adresses IP de ce sous-réseau à associer à vos nœuds.
Cette section explique comment créer et exploiter des sous-réseaux et des groupes de sous-réseaux pour gérer l'accès à vos ressources MemoryDB.
Pour plus d'informations sur l'utilisation du groupe de sous-réseaux dans un environnement Amazon VPC, veuillez consulter [Étape 4 : Autoriser l'accès au cluster](getting-started.md#getting-started.authorizeaccess).
**MemoryDB AZ pris en charge IDs**
| Nom de région/Région | AZ pris en charge IDs |
| --- | --- |
| Région US East (Ohio) `us-east-2` | `use2-az1, use2-az2, use2-az3` |
| Région US East (N. Virginia) `us-east-1` | `use1-az1, use1-az2, use1-az4, use1-az5, use1-az6` |
| Région US West (N. California) `us-west-1` | `usw1-az1, usw1-az2, usw1-az3` |
| Région US West (Oregon) `us-west-2` | `usw2-az1, usw2-az2, usw2-az3, usw2-az4` |
| Région Canada (Centre) `ca-central-1` | `cac1-az1, cac1-az2, cac1-az4` |
| Région Asie-Pacifique (Hong Kong) `ap-east-1` | `ape1-az1, ape1-az2, ape1-az3` |
| Région Asia Pacific (Mumbai) `ap-south-1` | `aps1-az1, aps1-az2, aps1-az3` |
| Région Asia Pacific (Tokyo) `ap-northeast-1` | `apne1-az1, apne1-az2, apne1-az4` |
| Asia Pacific (Seoul) Region `ap-northeast-2` | `apne2-az1, apne2-az2, apne2-az3` |
| Région Asie-Pacifique (Singapour) `ap-southeast-1` | `apse1-az1, apse1-az2, apse1-az3` |
| Région Asia Pacific (Sydney) `ap-southeast-2` | apse2-az1, apse2-az2, apse2-az3 |
| Région Europe (Frankfurt) `eu-central-1` | `euc1-az1, euc1-az2, euc1-az3` |
| Région Europe (Irlande) `eu-west-1` | `euw1-az1, euw1-az2, euw1-az3` |
| Région Europe (London) `eu-west-2` | `euw2-az1, euw2-az2, euw2-az3` |
| Région Europe (Paris) `eu-west-3` | `euw3-az1, euw3-az2, euw3-az3` |
| Région Europe (Stockholm) `eu-north-1` | `eun1-az1, eun1-az2, eun1-az3 ` |
| Europe (Milan) Region `eu-south-1` | `eus1-az1, eus1-az2, eus1-az3 ` |
| Région South America (São Paulo) `sa-east-1` | `sae1-az1, sae1-az2, sae1-az3` |
| Région Chine (Beijing) `cn-north-1` | `cnn1-az1, cnn1-az2` |
| Région Chine (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` |
| Région Europe (Espagne) `eu-south-2` | `eus2-az1, eus2-az2, eus2-az3` |
**Topics**
+ [MemoryDB et IPV6](subnetgroups.ipv6.md)
+ [Création d'un groupe de sous-réseaux](subnetgroups.creating.md)
+ [Mettre à jour un groupe de sous-réseaux](subnetgroups.modifying.md)
+ [Afficher les détails d'un groupe de sous-réseaux](subnetgroups.Viewing.md)
+ [Suppression d'un groupe de sous-réseaux](subnetgroups.deleting.md)
# MemoryDB et IPV6
Vous pouvez créer de nouveaux clusters à double pile et uniquement IPv6 avec les moteurs Valkey et Redis OSS, en fournissant des groupes de sous-réseaux avec des sous-réseaux à double pile et des sous-réseaux IPv6 uniquement. Vous ne pouvez pas modifier le type de réseau d'un cluster existant.
Grâce à cette fonctionnalité, vous pouvez :
+ Créez des clusters IPv4 uniquement et à double pile sur des sous-réseaux à double pile.
+ Créez des clusters IPv6 uniquement sur des sous-réseaux IPv6 uniquement.
+ Créez de nouveaux groupes de sous-réseaux pour prendre en charge les sous-réseaux IPv4 uniquement, Dual Stack et IPv6 uniquement.
+ Modifiez les groupes de sous-réseaux existants pour inclure des sous-réseaux supplémentaires provenant du VPC sous-jacent.
+ Modifier les sous-réseaux existants dans les groupes de sous-réseaux
+ Ajoutez IPv6 uniquement des sous-réseaux aux groupes de sous-réseaux configurés pour IPv6
+ Ajoutez des sous-réseaux IPv4 ou des sous-réseaux à double pile aux groupes de sous-réseaux configurés pour la prise en charge de IPv4 la double pile
+ Découvrez tous les nœuds du cluster dotés d'adresses IPv4 OU IPv6, grâce aux commandes de découverte du moteur pour les clusters à double pile et IPv6. Ces commandes de découverte incluent `redis_info``redis_cluster`, et similaires.
+ Découvrez les adresses IPv4 et IPv6 de tous les nœuds du cluster, via des commandes de découverte DNS pour les clusters à double pile et IPv6.
# Création d'un groupe de sous-réseaux
Lorsque vous créez un nouveau groupe de sous-réseaux de , notez le nombre d'adresses IP disponibles. Si le sous-réseau a très peu d'adresses IP libres, vous pourriez ne pas pouvoir ajouter autant de nœuds de que vous le souhaitez au cluster. Pour résoudre ce problème, vous pouvez assigner un ou plusieurs sous-réseaux à un groupe de sous-réseaux afin d'avoir un nombre suffisant d'adresses IP dans la zone de disponibilité de votre cluster. Vous pouvez, ensuite, ajouter plusieurs nœuds de cache à votre cluster.
Les procédures suivantes vous montrent comment créer un groupe de sous-réseaux appelé `mysubnetgroup` (console), le AWS CLI, et l'API MemoryDB.
## Pour créer un groupe de sous-réseaux (console)
La procédure suivante indique comment créer un groupe de sous-réseaux (console).
**Pour créer un groupe de sous-réseaux (console)**
1. Connectez-vous à la console de AWS gestion et ouvrez la console MemoryDB à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Subnet Groups**.
1. Choisissez **Créer un groupe de sous-réseaux**.
1. Sur la page **Créer un groupe de sous-réseaux**, procédez comme suit :
1. Dans le champ **Name**, saisissez le nom de votre groupe de sous-réseaux de
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
1. Dans la zone **Description**, saisissez une description de votre groupe de sous-réseaux de
1. Dans la zone **VPC ID (ID du VPC)**, choisissez l’Amazon VPC que vous avez créé. Si vous n'en avez pas créé un, cliquez sur le bouton **Créer un VPC** et suivez les étapes pour en créer un.
1. **Dans **Sous-réseaux sélectionnés**, choisissez la zone de disponibilité et l'ID de votre sous-réseau privé, puis choisissez Choisir.**
1. Pour les **balises**, vous pouvez éventuellement appliquer des balises pour rechercher et filtrer vos sous-réseaux ou suivre vos AWS coûts.
1. Lorsque tous les paramètres vous conviennent, choisissez **Créer**.
1. Dans le message de confirmation qui s'affiche, cliquez sur **Close**.
Votre nouveau groupe de sous-réseaux apparaît dans la liste des **groupes de sous-réseaux** de la console MemoryDB. En bas de la fenêtre, vous pouvez choisir le groupe de sous-réseaux pour voir les détails, tels que tous les sous-réseaux associés à ce groupe.
## Création d'un groupe de sous-réseaux (AWS CLI)
A l'invite de commande, utilisez la commande `create-subnet-group` pour créer un groupe de sous-réseaux de
Pour Linux, macOS ou Unix :
```
aws memorydb create-subnet-group \
--subnet-group-name mysubnetgroup \
--description "Testing" \
--subnet-ids subnet-53df9c3a
```
Pour Windows :
```
aws memorydb create-subnet-group ^
--subnet-group-name mysubnetgroup ^
--description "Testing" ^
--subnet-ids subnet-53df9c3a
```
Cette commande doit produire une sortie similaire à ce qui suit :
```
{
"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"
}
}
```
Pour plus d'informations, consultez la AWS CLI rubrique[create-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-subnet-group.html).
## Création d'un groupe de sous-réseaux (API MemoryDB)
À l'aide de l'API MemoryDB, appelez `CreateSubnetGroup` avec les paramètres suivants :
+ `SubnetGroupName=``mysubnetgroup`
+ `Description=``Testing`
+ `SubnetIds.member.1=``subnet-53df9c3a`
# Mettre à jour un groupe de sous-réseaux
Vous pouvez mettre à jour la description d'un groupe de sous-réseaux ou modifier la liste des sous-réseaux IDs associés au groupe de sous-réseaux. Vous ne pouvez pas supprimer un ID de sous-réseau d'un groupe de sous-réseaux de si un cluster de utilise actuellement ce sous-réseau.
Les procédures suivantes indiquent comment mettre à jour un groupe de sous-réseaux.
## Mise à jour de groupes de sous-réseaux (console)
**Pour mettre à jour un groupe de sous-réseaux**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Subnet Groups**.
1. Dans la liste des groupes de sous-réseaux, choisissez celui que vous voulez modifier.
1. Les champs **Nom **VPCId****et **Description** ne sont pas modifiables.
1. Dans la section **Sous-réseaux sélectionnés**, cliquez sur **Gérer pour apporter les** modifications nécessaires aux zones de disponibilité dont vous avez besoin pour les sous-réseaux. Choisissez **Save** pour enregistrer les changements.
## Mise à jour de groupes de sous-réseaux (AWS CLI)
À l'invite de commande, utilisez la commande `update-subnet-group` pour mettre à jour un groupe de sous-réseaux.
Pour Linux, macOS ou Unix :
```
aws memorydb update-subnet-group \
--subnet-group-name mysubnetgroup \
--description "New description" \
--subnet-ids "subnet-42df9c3a" "subnet-48fc21a9"
```
Pour Windows :
```
aws memorydb update-subnet-group ^
--subnet-group-name mysubnetgroup ^
--description "New description" ^
--subnet-ids "subnet-42df9c3a" "subnet-48fc21a9"
```
Cette commande doit produire une sortie similaire à ce qui suit :
```
{
"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",
}
}
```
Pour plus d'informations, consultez la AWS CLI rubrique [update-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html).
## Mise à jour de groupes de sous-réseaux (API MemoryDB)
À l'aide de l'API MemoryDB, appelez `UpdateSubnetGroup` avec les paramètres suivants :
+ `SubnetGroupName=``mysubnetgroup`
+ D'autres paramètres dont vous voulez modifier les valeurs. Cet exemple utilise `Description=``New%20description` pour modifier la description du groupe de sous-réseaux de
**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
```
**Note**
Lorsque vous créez un nouveau groupe de sous-réseaux de , notez le nombre d'adresses IP disponibles. Si le sous-réseau a très peu d'adresses IP libres, vous pourriez ne pas pouvoir ajouter autant de nœuds de que vous le souhaitez au cluster. Pour résoudre ce problème, vous pouvez assigner un ou plusieurs sous-réseaux à un groupe de sous-réseaux afin d'avoir un nombre suffisant d'adresses IP dans la zone de disponibilité de votre cluster. Vous pouvez, ensuite, ajouter plusieurs nœuds de cache à votre cluster.
# Afficher les détails d'un groupe de sous-réseaux
Les procédures suivantes vous montrent comment afficher les détails d'un groupe de sous-réseaux.
## Affichage des détails des groupes de sous-réseaux (console)
**Pour afficher les détails d'un groupe de sous-réseaux (console)**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Subnet Groups**.
1. Sur la page **Groupes de sous-réseaux**, choisissez le groupe de sous-réseaux sous **Nom** ou entrez le nom du groupe de sous-réseaux dans la barre de recherche.
1. Sur la page **Groupes de sous-réseaux**, choisissez le groupe de sous-réseaux sous **Nom** ou entrez le nom du groupe de sous-réseaux dans la barre de recherche.
1. Dans **les paramètres du groupe de sous-réseaux**, vous pouvez afficher le nom, la description, l'ID VPC et le nom de ressource Amazon (ARN) du groupe de sous-réseaux.
1. Sous **Sous-réseaux**, vous pouvez afficher les zones de disponibilité, les sous-réseaux IDs et les blocs CIDR du groupe de sous-réseaux
1. Sous **Balises**, vous pouvez afficher toutes les balises associées au groupe de sous-réseaux.
## Affichage des détails des groupes de sous-réseaux (AWS CLI)
À l'invite de commande, utilisez la commande `describe-subnet-groups` pour afficher les détails d'un groupe de sous-réseaux spécifié.
Pour Linux, macOS ou Unix :
```
aws memorydb describe-subnet-groups \
--subnet-group-name mysubnetgroup
```
Pour Windows :
```
aws memorydb describe-subnet-groups ^
--subnet-group-name mysubnetgroup
```
Cette commande doit produire une sortie similaire à ce qui suit :
```
{
"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"
}
]
}
```
Pour afficher les détails de tous les groupes de sous-réseaux, utilisez la même commande, mais sans spécifier de nom de groupe de sous-réseaux.
```
aws memorydb describe-subnet-groups
```
Pour plus d'informations, consultez la AWS CLI rubrique[describe-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html).
## Affichage des groupes de sous-réseaux (API MemoryDB)
À l'aide de l'API MemoryDB, appelez `DescribeSubnetGroups` avec les paramètres suivants :
`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
```
# Suppression d'un groupe de sous-réseaux
Si vous décidez que vous n'avez plus besoin de votre groupe de sous-réseaux de , vous pouvez le supprimer. Vous ne pouvez pas supprimer un groupe de sous-réseaux de s'il est actuellement utilisé par un cluster de Vous ne pouvez pas non plus supprimer un groupe de sous-réseaux sur un cluster avec Multi-AZ activé si cela laisse ce cluster avec moins de deux sous-réseaux. Vous devez d'abord décocher **Multi-AZ**, puis supprimer le sous-réseau.
Les procédures suivantes vous montrent comment supprimer un groupe de sous-réseaux.
## Suppression d’un groupe de sous-réseaux (console)
**Pour supprimer un groupe de sous-réseaux**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Subnet Groups**.
1. Dans la liste des groupes de sous-réseaux, choisissez celui que vous souhaitez supprimer, sélectionnez **Actions**, puis sélectionnez **Supprimer**.
**Note**
Vous ne pouvez pas supprimer un groupe de sous-réseaux par défaut ou un groupe associé à un cluster.
1. L'écran de confirmation de **suppression des groupes de sous-réseaux** s'affiche.
1. Pour supprimer le groupe de sous-réseaux, entrez `delete` dans la zone de texte de confirmation. Pour conserver le groupe de sous-réseaux, choisissez **Cancel (Annuler)**.
## Supprimer un groupe de sous-réseaux (AWS CLI)
À l'aide de AWS CLI, appelez la commande **delete-subnet-group** avec le paramètre suivant :
+ `--subnet-group-name` *mysubnetgroup*
Pour Linux, macOS ou Unix :
```
aws memorydb delete-subnet-group \
--subnet-group-name mysubnetgroup
```
Pour Windows :
```
aws memorydb delete-subnet-group ^
--subnet-group-name mysubnetgroup
```
Pour plus d'informations, consultez la AWS CLI rubrique [delete-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-subnet-group.html).
## Supprimer un groupe de sous-réseaux (API MemoryDB)
À l'aide de l'API MemoryDB, appelez `DeleteSubnetGroup` avec le paramètre suivant :
+ `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
```
Cette commande ne produit aucun résultat.
Pour plus d'informations, consultez la rubrique relative à l'API MemoryDB. [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html)
# API MemoryDB et points de terminaison VPC d'interface ()AWS PrivateLink
*Vous pouvez établir une connexion privée entre votre VPC et les points de terminaison d'API Amazon MemoryDB en créant un point de terminaison VPC d'interface.* Les points de terminaison de l'interface sont alimentés par [AWS PrivateLink](https://aws.amazon.com/privatelink). AWS PrivateLink vous permet d'accéder en privé aux opérations de l'API MemoryDB sans passerelle Internet, périphérique NAT, connexion VPN ou connexion Direct AWS Connect.
Les instances de votre VPC n'ont pas besoin d'adresses IP publiques pour communiquer avec les points de terminaison de l'API MemoryDB. Vos instances n'ont pas non plus besoin d'adresses IP publiques pour utiliser les opérations d'API MemoryDB disponibles. Le trafic entre votre VPC et MemoryDB ne quitte pas le réseau Amazon. Chaque point de terminaison d'interface est représenté par une ou plusieurs interfaces réseau Elastic dans vos sous-réseaux. Pour plus d'informations sur les interfaces réseau Elastic, veuillez consulter [Interfaces réseau Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans le *Guide de l'utilisateur Amazon EC2.*
+ *Pour plus d'informations sur les points de terminaison VPC, consultez la section Interface [VPC endpoints () dans AWS PrivateLink le guide de l'](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)utilisateur Amazon VPC.*
+ Pour plus d'informations sur les opérations de l'API MemoryDB, consultez la section Opérations de l'API [MemoryDB](https://docs.aws.amazon.com/memorydb/latest/APIReference/Welcome.html).
Après avoir créé un point de terminaison VPC d'interface, si vous activez les noms d'hôte [DNS privés](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) pour le point de terminaison, il s'agit du point de terminaison MemoryDB par défaut (https://memorydb). *Region*.amazonaws.com) correspond à votre point de terminaison VPC. Si vous n'activez pas les noms d'hôte DNS privés, Amazon VPC fournit un nom de point de terminaison DNS que vous pouvez utiliser au format suivant :
```
VPC_Endpoint_ID.memorydb.Region.vpce.amazonaws.com
```
Pour de plus amples informations, consultez [Points de terminaison VPC (AWS PrivateLink) ](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) dans le *Guide de l'utilisateur Amazon VPC*. MemoryDB prend en charge les appels à toutes ses [actions d'API](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html) au sein de votre VPC.
**Note**
Les noms d'hôtes DNS privés ne peuvent être activés que pour un seul point de terminaison d'un VPC dans le VPC. Si vous voulez créer un point de terminaison d'un VPC supplémentaire, le nom d'hôte DNS privé doit être désactivé pour celui-ci.
## Considérations relatives aux points de terminaison d'un VPC
*Avant de configurer un point de terminaison VPC d'interface pour les points de terminaison d'API MemoryDB, assurez-vous de consulter les [propriétés et les limites du point de terminaison d'interface dans le guide de l'](https://docs.aws.amazon.com/vpc/latest/privatelink/endpoint-services-overview.html)utilisateur Amazon VPC.* Toutes les opérations de l'API MemoryDB pertinentes pour la gestion des ressources MemoryDB sont disponibles depuis votre VPC à l'aide de. AWS PrivateLink Les politiques de point de terminaison VPC sont prises en charge pour les points de terminaison de l'API MemoryDB. Par défaut, l'accès complet aux opérations de l'API MemoryDB est autorisé via le point de terminaison. Pour plus d’informations, consultez [Contrôle de l’accès aux services avec points de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) dans le *Guide de l’utilisateur Amazon VPC*.
### Création d'un point de terminaison VPC d'interface pour l'API MemoryDB
Vous pouvez créer un point de terminaison VPC pour l'API MemoryDB à l'aide de la console Amazon VPC ou du. AWS CLI Pour plus d’informations, consultez [Création d’un point de terminaison d’interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) dans le *Guide de l’utilisateur Amazon VPC*.
Une fois que vous avez créé un point de terminaison de VPC d'interface, vous pouvez activer les noms d'hôte DNS privés pour le point de terminaison. Lorsque vous le faites, le point de terminaison MemoryDB par défaut (https://memorydb. *Region*.amazonaws.com) correspond à votre point de terminaison VPC. Pour plus d’informations, consultez [Accès à un service via un point de terminaison d’interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) dans le *Guide de l’utilisateur Amazon VPC*.
### Création d'une politique de point de terminaison VPC pour l'API Amazon MemoryDB
Vous pouvez associer une politique de point de terminaison à votre point de terminaison VPC qui contrôle l'accès à l'API MemoryDB. La stratégie spécifie les éléments suivants :
+ Le principal qui peut exécuter des actions.
+ Les actions qui peuvent être effectuées.
+ Les ressources sur lesquelles les actions peuvent être exécutées.
Pour plus d’informations, consultez [Contrôle de l’accès aux services avec points de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) dans le *Guide de l’utilisateur Amazon VPC*.
**Example Politique de point de terminaison VPC pour les actions de l'API MemoryDB**
Voici un exemple de politique de point de terminaison pour l'API MemoryDB. Lorsqu'elle est attachée à un point de terminaison, cette politique accorde l'accès aux actions de l'API MemoryDB répertoriées pour tous les principaux sur toutes les ressources.
```
{
"Statement": [{
"Principal": "*",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:UpdateCluster",
"memorydb:CreateSnapshot"
],
"Resource": "*"
}]
}
```
**Example Politique de point de terminaison VPC qui refuse tout accès depuis un compte spécifié AWS**
La politique de point de terminaison VPC suivante refuse au AWS compte *123456789012* tout accès aux ressources utilisant le point de terminaison. La politique autorise toutes les actions provenant d’autres comptes.
```
{
"Statement": [{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
# Vulnérabilités et expositions courantes (CVE) : vulnérabilités de sécurité corrigées dans MemoryDB
Vulnérabilités et expositions courantes (CVE) est une liste d'entrées pour les vulnérabilités de cybersécurité connues du public. Chaque entrée est un lien qui contient un numéro d'identification, une description et au moins une référence publique. Vous trouverez sur cette page une liste des failles de sécurité corrigées dans MemoryDB.
Nous vous recommandons de toujours effectuer une mise à niveau vers les dernières versions de MemoryDB afin de vous protéger contre les vulnérabilités connues. MemoryDB expose le composant PATCH. Les versions PATCH sont destinées aux corrections de bogues rétrocompatibles, aux correctifs de sécurité et aux modifications non fonctionnelles.
Vous pouvez utiliser le tableau suivant pour vérifier si une version particulière de MemoryDB inclut un correctif pour une vulnérabilité de sécurité spécifique. Si votre cache MemoryDB est en attente de mise à jour du service, il est peut-être vulnérable à l'une des failles de sécurité répertoriées ci-dessous. Nous vous recommandons d'appliquer la mise à jour du service. Pour plus d'informations sur les versions du moteur MemoryDB prises en charge et sur la procédure de mise à niveau, consultez. [Versions du moteur](engine-versions.md)
**Note**
Si un CVE est traité dans une version de MemoryDB, cela signifie qu'il est également traité dans les versions plus récentes.
Un astérisque (\$1) dans le tableau suivant indique que la dernière mise à jour du service doit être appliquée au cluster MemoryDB exécutant la version spécifiée afin de corriger la vulnérabilité de sécurité. Pour plus d'informations sur la façon de vérifier que la dernière mise à jour du service est appliquée à la version de MemoryDB sur laquelle votre cluster est exécuté, consultez. [Gestion des mises à jour du service](managing-updates.md)
| Version de MemoryDB | CVEs Adressée |
| --- | --- |
| Valkey 7.3 et toutes les versions précédentes de Valkey Redis OSS 7.1 et toutes les versions précédentes de Redis OSS | [CVE-2025-49844 \$1, CVE-2025-46817](https://www.cve.org/CVERecord?id=CVE-2025-49844) [https://www.cve.org/CVERecord?id=CVE-2025-46818](https://www.cve.org/CVERecord?id=CVE-2025-46818) |
| Valkey 7.2 et 7.3 | [CVE-2025-21607\$1, CVE-2025-21605\$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21607)[, CVE-2024-31449\$1, CVE-2024-31227\$1](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) |
| Vallée 7.2.7 | [CVE-2024-51741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-51741) |
| Redis OSS 7.1 et 6.2 | [CVE-2025-21605\$1, CVE-2024-31449\$1](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 OSS 7.0.7 | [CVE-2023-41056 \$1](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056) |
| Redis OSS 6.2.7 | [CVE-2024-46981](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46981) |
| Redis OSS 6.2.6 | [CVE-24834 \$1, CVE-35977 \$1, CVE-36021 \$1, CVE-2023-22458](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24834)[, CVE-2023-25155](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35977) [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021) [CVE-2023-45145](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45145) : Notez que ce CVE a été résolu dans Redis OSS 6.2 et 7.0, mais pas dans 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) |