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.
# Sécurité dans MemoryDB
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit ceci comme la sécurité du cloud et la sécurité dans le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l'efficacité de notre sécurité dans le cadre des programmes de [AWS conformité Programmes](https://aws.amazon.com/compliance/programs/) de de conformité. Pour en savoir plus sur les programmes de conformité qui s'appliquent à MemoryDB, voir [AWS Services concernés par programme de conformitéAWS](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre entreprise et la législation et la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation de MemoryDB. Il vous montre comment configurer MemoryDB pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres AWS services qui vous aident à surveiller et à sécuriser vos ressources MemoryDB.
**Topics**
+ [Protection des données](data-protection.md)
+ [Gestion des identités et des accès](iam.md)
+ [Journalisation et surveillance](monitoring-overview.md)
+ [Validation de conformité](memorydb-compliance.md)
+ [Sécurité de l’infrastructure](infrastructure-security.md)
+ [Confidentialité du trafic inter-réseau](Security.traffic.md)
+ [Mises à jour de service](service-updates.md)
# Protection des données dans MemoryDB
Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) de s'applique à la protection des données dans. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec ou d'autres Services AWS utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
# Sécurité des données dans MemoryDB
Pour garantir la sécurité de vos données, MemoryDB et Amazon EC2 fournissent des mécanismes de protection contre tout accès non autorisé à vos données sur le serveur.
MemoryDB fournit également des fonctionnalités de chiffrement pour les données des clusters :
+ Le chiffrement des données en transit chiffre vos données lorsqu'elles sont déplacées d'un emplacement à un autre, par exemple de nœuds vers un cluster ou entre votre cluster et votre application.
+ Le chiffrement au repos chiffre le journal des transactions et vos données sur disque lors des opérations de capture instantanée.
Vous pouvez également l'utiliser [Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs](clusters.acls.md) pour contrôler l'accès des utilisateurs à vos clusters.
**Topics**
+ [Sécurité des données dans MemoryDB](encryption.md)
+ [Chiffrement au repos dans MemoryDB](at-rest-encryption.md)
+ [Chiffrement en transit (TLS) dans MemoryDB](in-transit-encryption.md)
+ [Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs](clusters.acls.md)
+ [Authentification avec IAM](auth-iam.md)
# Chiffrement au repos dans MemoryDB
Pour garantir la sécurité de vos données, MemoryDB et Amazon S3 proposent différentes méthodes pour restreindre l'accès aux données de vos clusters. Pour plus d’informations, consultez [MemoryDB et Amazon VPC](vpcs.md) et [Gestion des identités et des accès dans MemoryDB](iam.md).
Le chiffrement au repos de MemoryDB est toujours activé pour renforcer la sécurité des données en chiffrant les données persistantes. Il chiffre les aspects suivants :
+ Données du journal des transactions
+ Disque pendant les opérations de synchronisation, de capture d'écran et de swap
+ Instantanés stockés dans Amazon S3
MemoryDB propose un chiffrement par défaut (géré par le service) au repos, ainsi que la possibilité d'utiliser vos propres clés racine symétriques gérées par le client dans le [service de gestion des AWS clés (](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)KMS).
Les données stockées sur SSDs (disques SSD) dans des clusters compatibles avec la hiérarchisation des données sont toujours chiffrées par défaut.
Pour plus d'informations sur le chiffrement en transit, veuillez consulter [Chiffrement en transit (TLS) dans MemoryDB](in-transit-encryption.md).
**Topics**
+ [Utilisation de clés gérées par le client à partir de AWS KMS](#using-customer-managed-keys-for-memorydb-security)
+ [consultez aussi](#at-rest-encryption-see-also)
## Utilisation de clés gérées par le client à partir de AWS KMS
MemoryDB prend en charge les clés racines symétriques gérées par le client (clé KMS) pour le chiffrement au repos. Les clés KMS gérées par le client sont des clés de chiffrement que vous créez, détenez et gérez dans votre AWS compte. Pour plus d'informations, voir [Customer Root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) dans le *Guide du développeur du service de gestion des AWS clés*. Les clés doivent être créées dans AWS KMS avant de pouvoir être utilisées avec MemoryDB.
Pour savoir comment créer des clés racines AWS KMS, consultez la section [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *guide du développeur du service de gestion des AWS clés*.
MemoryDB vous permet de vous intégrer à KMS. AWS Pour plus d'informations, veuillez consulter [Utilisation d'octrois](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) dans le *Guide du développeur AWS Key Management Service*. Aucune action du client n'est requise pour activer l'intégration de MemoryDB avec AWS KMS.
La clé de `kms:ViaService` condition limite l'utilisation d'une clé AWS KMS aux demandes provenant de AWS services spécifiques. À utiliser `kms:ViaService` avec MemoryDB, incluez les deux ViaService noms dans la valeur de la clé de condition :. `memorydb.amazon_region.amazonaws.com` Pour plus d'informations, voir [kms : ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
Vous pouvez l'utiliser [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)pour suivre les demandes que MemoryDB envoie en votre AWS Key Management Service nom. Tous les appels d'API AWS Key Management Service liés aux clés gérées par le client ont CloudTrail des journaux correspondants. Vous pouvez également voir les autorisations créées par MemoryDB en appelant l'appel d'API [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)KMS.
Une fois qu'un cluster est chiffré à l'aide d'une clé gérée par le client, tous les instantanés du cluster sont chiffrés comme suit :
+ Les instantanés quotidiens automatiques sont chiffrés à l'aide de la clé gérée par le client associée au cluster.
+ L'instantané final créé lorsque le cluster est supprimé est également chiffré à l'aide de la clé gérée par le client associée au cluster.
+ Les instantanés créés manuellement sont chiffrés par défaut pour utiliser la clé KMS associée au cluster. Vous pouvez la remplacer en choisissant une autre clé gérée par le client.
+ La copie d'un instantané utilise par défaut la clé gérée par le client associée à l'instantané source. Vous pouvez la remplacer en choisissant une autre clé gérée par le client.
**Note**
Les clés gérées par le client ne peuvent pas être utilisées lors de l'exportation d'instantanés vers le compartiment Amazon S3 que vous avez sélectionné. Cependant, tous les instantanés exportés vers Amazon S3 sont chiffrés à l'aide [du chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Vous pouvez choisir de copier le fichier instantané sur un nouvel objet S3 et de le chiffrer à l'aide d'une clé KMS gérée par le client, de copier le fichier dans un autre compartiment S3 configuré avec le chiffrement par défaut à l'aide d'une clé KMS ou de modifier une option de chiffrement dans le fichier lui-même.
Vous pouvez également utiliser des clés gérées par le client pour chiffrer des instantanés créés manuellement qui n'utilisent pas de clés gérées par le client pour le chiffrement. Avec cette option, le fichier de capture enregistré dans Amazon S3 est chiffré à l'aide d'une clé KMS, même si les données ne sont pas chiffrées sur le cluster d'origine.
La restauration à partir d'un instantané vous permet de choisir parmi les options de chiffrement disponibles, à l'instar des options de chiffrement disponibles lors de la création d'un nouveau cluster.
+ Si vous supprimez la clé ou si vous la [désactivez](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) et que vous [révoquez les autorisations](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) relatives à la clé que vous avez utilisée pour chiffrer un cluster, celui-ci devient irrécupérable. En d'autres termes, il ne peut pas être modifié ou restauré après une panne matérielle. AWS KMS supprime les clés racines uniquement après une période d'attente d'au moins sept jours. Une fois la clé supprimée, vous pouvez utiliser une autre clé gérée par le client pour créer un instantané à des fins d'archivage.
+ La rotation automatique des clés préserve les propriétés de vos clés racines AWS KMS, de sorte que la rotation n'a aucun effet sur votre capacité à accéder à vos données MemoryDB. Les clusters MemoryDB chiffrés ne prennent pas en charge la rotation manuelle des clés, qui implique la création d'une nouvelle clé racine et la mise à jour des références à l'ancienne clé. Pour en savoir plus, consultez [Rotating Customer root keys](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) dans le *Guide du développeur du service de gestion des AWS clés*.
+ Le chiffrement d'un cluster MemoryDB à l'aide d'une clé KMS nécessite une autorisation par cluster. Cette subvention est utilisée pendant toute la durée de vie du cluster. En outre, une subvention par instantané est utilisée lors de la création de l'instantané. Cette subvention est retirée une fois le cliché créé.
+ Pour plus d'informations sur les autorisations et les limites AWS KMS, consultez la section [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) du *Guide du développeur du service de gestion des AWS clés*.
## consultez aussi
+ [Chiffrement en transit (TLS) dans MemoryDB](in-transit-encryption.md)
+ [MemoryDB et Amazon VPC](vpcs.md)
+ [Gestion des identités et des accès dans MemoryDB](iam.md)
# Chiffrement en transit (TLS) dans MemoryDB
Pour garantir la sécurité de vos données, MemoryDB et Amazon EC2 fournissent des mécanismes de protection contre tout accès non autorisé à vos données sur le serveur. En fournissant une fonctionnalité de chiffrement en transit, MemoryDB vous fournit un outil que vous pouvez utiliser pour protéger vos données lorsqu'elles sont déplacées d'un endroit à un autre. Par exemple, vous pouvez déplacer des données d'un nœud principal vers un nœud de réplication en lecture au sein d'un cluster, ou entre votre cluster et votre application.
**Topics**
+ [Présentation du chiffrement en transit](#in-transit-encryption-overview)
+ [Consultez aussi](#in-transit-encryption-see-also)
## Présentation du chiffrement en transit
Le chiffrement en transit de MemoryDB est une fonctionnalité qui renforce la sécurité de vos données aux points les plus vulnérables, c'est-à-dire lorsqu'elles sont en transit d'un endroit à un autre.
Le chiffrement en transit de MemoryDB implémente les fonctionnalités suivantes :
+ **Connexions cryptées : les connexions** au serveur et au client sont cryptées par le protocole TLS (Transport Layer Security).
+ **Réplication chiffrée** : les données transférées entre un nœud primaire et des nœuds en réplica sont chiffrées.
+ **Authentification du serveur** : les clients peuvent authentifier leur connexion au bon serveur.
Depuis le 20/07/2023, TLS 1.2 est la version minimale prise en charge pour les clusters nouveaux et existants. Utilisez ce [lien](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) pour en savoir plus sur le protocole TLS 1.2 à l'adresse AWS.
Pour plus d'informations sur la connexion aux clusters MemoryDB, consultez. [Connexion aux nœuds MemoryDB à l'aide de redis-cli](getting-started.md#connect-tls)
## Consultez aussi
+ [Chiffrement au repos dans MemoryDB](at-rest-encryption.md)
+ [Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB et Amazon VPC](vpcs.md)
+ [Gestion des identités et des accès dans MemoryDB](iam.md)
# Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs
Vous pouvez authentifier les utilisateurs à l'aide de listes de contrôle d'accès (ACLs).
ACLs vous permettent de contrôler l'accès au cluster en regroupant les utilisateurs. Ces listes de contrôle d'accès sont conçues pour organiser l'accès aux clusters.
Avec ACLs, vous créez des utilisateurs et leur attribuez des autorisations spécifiques à l'aide d'une chaîne d'accès, comme décrit dans la section suivante. Vous assignez les utilisateurs à des listes de contrôle d'accès alignées sur un rôle spécifique (administrateurs, ressources humaines) qui sont ensuite déployées sur un ou plusieurs clusters MemoryDB. Vous pouvez ainsi établir des limites de sécurité entre les clients utilisant le ou les mêmes clusters MemoryDB et empêcher les clients d'accéder aux données des autres.
ACLs sont conçus pour prendre en charge l'introduction de l'[ACL](https://valkey.io/docs/topics/acl/) dans Redis OSS 6. Lorsque vous l'utilisez ACLs avec votre cluster MemoryDB, certaines limites s'appliquent :
+ Vous ne pouvez pas spécifier de mots de passe dans une chaîne d'accès. Vous définissez des mots de passe avec [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html)ou par [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html)appels.
+ Pour les droits d'utilisateur, vous passez `on` et `off` dans le cadre de la chaîne d'accès. Si aucune des deux n'est spécifiée dans la chaîne d'accès, l'utilisateur est affecté au cluster `off` et ne dispose pas de droits d'accès.
+ Vous ne pouvez pas utiliser de commandes interdites. Si vous spécifiez une commande interdite, une exception sera émise. Pour obtenir la liste de ces commandes, consultez[Commandes limitées](restrictedcommands.md).
+ Vous ne pouvez pas utiliser la commande `reset` dans le cadre d'une chaîne d'accès. Vous spécifiez les mots de passe avec les paramètres de l'API, et MemoryDB gère les mots de passe. Par conséquent, vous ne pouvez pas utiliser `reset` car il supprimerait tous les mots de passe d'un utilisateur.
+ Redis OSS 6 introduit la commande [ACL LIST](https://valkey.io/commands/acl-list). Cette commande renvoie une liste d'utilisateurs ainsi que les règles de liste ACL appliquées à chaque utilisateur. MemoryDB prend en charge la `ACL LIST` commande, mais ne prend pas en charge le hachage des mots de passe comme le fait Redis OSS. Avec MemoryDB, vous pouvez utiliser l'[DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)opération pour obtenir des informations similaires, y compris les règles contenues dans la chaîne d'accès. Cependant, [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)ne permet pas de récupérer le mot de passe utilisateur.
[Les autres commandes en lecture seule prises en charge par MemoryDB incluent [ACL WHOAMI, ACL USERS](https://valkey.io/commands/acl-whoami) et [ACL CAT](https://valkey.io/commands/acl-users).](https://valkey.io/commands/acl-cat) MemoryDB ne prend en charge aucune autre commande ACL basée sur l'écriture.
L'utilisation ACLs avec MemoryDB est décrite plus en détail ci-dessous.
**Topics**
+ [Définition des autorisations à l'aide d'une chaîne d'accès](#access-string)
+ [Capacités de recherche vectorielle](#access-vss)
+ [Appliquer ACLs à un cluster pour MemoryDB](#rbac-using)
## Définition des autorisations à l'aide d'une chaîne d'accès
Pour spécifier les autorisations d'accès à un cluster MemoryDB, vous créez une chaîne d'accès et vous l'attribuez à un utilisateur en utilisant le AWS CLI ou. AWS Management Console
Les chaînes d'accès sont définies comme une liste de règles délimitées par des espaces qui sont appliquées à l'utilisateur. Elles définissent les commandes qu'un utilisateur peut exécuter et les clés qu'un utilisateur peut utiliser. Pour exécuter une commande, un utilisateur doit avoir accès à la commande en cours d'exécution et à toutes les clés accessibles par la commande. Les règles sont appliquées de gauche à droite de manière cumulative, et une chaîne plus simple peut être utilisée à la place de celle fournie en cas de redondance dans la chaîne fournie.
Pour plus d'informations sur la syntaxe des règles de liste ACL, veuillez consulter [Listes ACL](https://valkey.io/topics/acl).
Dans l'exemple suivant, la chaîne d'accès représente un utilisateur actif ayant accès à toutes les clés et commandes disponibles.
`on ~* &* +@all`
La syntaxe de la chaîne d'accès se décompose comme suit :
+ `on` : l'utilisateur est un utilisateur actif.
+ `~*` : l'accès est accordé à toutes les clés disponibles.
+ `&*`— L'accès est donné à toutes les chaînes pubsub.
+ `+@all` : l'accès est accordé à toutes les commandes disponibles.
Les paramètres précédents sont les moins restrictifs. Vous pouvez modifier ces paramètres pour les rendre plus sécurisés.
Dans l'exemple suivant, la chaîne d'accès représente un utilisateur dont l'accès est restreint à l'accès en lecture sur les clés commençant par un keyspace « app:: »
`on ~app::* -@all +@read`
Vous pouvez affiner ces autorisations en listant les commandes auxquelles l'utilisateur a accès :
`+command1` : l'accès de l'utilisateur aux commandes est limité à *`command1`*.
`+@category` : l'accès de l'utilisateur est limité à une catégorie de commandes.
Pour plus d'informations sur l'attribution d'une chaîne d'accès à un utilisateur, veuillez consulter [Création d'utilisateurs et de listes de contrôle d'accès à l'aide de la console et de la CLI](#users-management).
Si vous migrez une charge de travail existante vers MemoryDB, vous pouvez récupérer la chaîne d'accès en appelant`ACL LIST`, en excluant l'utilisateur et tout hachage de mot de passe.
## Capacités de recherche vectorielle
En [Recherche vectorielle](vector-search.md) effet, toutes les commandes de recherche appartiennent à la `@search` catégorie et aux catégories existantes `@read``@write`, `@fast` et `@slow` sont mises à jour pour inclure les commandes de recherche. Si un utilisateur n'a pas accès à une catégorie, il n'a accès à aucune commande de cette catégorie. Par exemple, si l'utilisateur n'y a pas accès`@search`, il ne peut exécuter aucune commande liée à la recherche.
Le tableau suivant indique le mappage des commandes de recherche vers les catégories appropriées.
| Commandes VSS | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | Y | Y | |
| FT.DROPINDEX | | Y | Y | |
| FT.LIST | Y | | | Y |
| FT.INFO | Y | | Y | |
| FT.SEARCH | Y | | | Y |
| FT.AGGREGATE | Y | | | Y |
| FT.PROFILE | Y | | | Y |
| FT.ALIASADD | | Y | Y | |
| FT.ALIASDEL | | Y | Y | |
| FT.ALIASUPDATE | | Y | Y | |
| FT.\$1ALIASLIST | Y | | | Y |
| FT.EXPLAIN | Y | | Y | |
| FT.EXPLAINCLI | Y | | Y | |
| FT.CONFIG | Y | | Y | |
## Appliquer ACLs à un cluster pour MemoryDB
Pour utiliser MemoryDB ACLs, vous devez suivre les étapes suivantes :
1. Créez un ou plusieurs utilisateurs.
1. Créez une ACL et ajoutez des utilisateurs à la liste.
1. Assignez l'ACL à un cluster.
Ces étapes sont décrites en détail ci-dessous.
**Topics**
+ [Création d'utilisateurs et de listes de contrôle d'accès à l'aide de la console et de la CLI](#users-management)
+ [Gestion des listes de contrôle d'accès avec la console et la CLI](#user-groups)
+ [Affectation de listes de contrôle d'accès aux clusters](#users-groups-to-clusterss)
### Création d'utilisateurs et de listes de contrôle d'accès à l'aide de la console et de la CLI
Les informations utilisateur pour ACLs les utilisateurs sont un nom d'utilisateur, et éventuellement un mot de passe et une chaîne d'accès. La chaîne d'accès fournit le niveau d'autorisation relatif aux clés et commandes. Le nom est propre à l'utilisateur et est transmis au moteur.
Assurez-vous que les autorisations utilisateur que vous fournissez correspondent à l'objectif de l'ACL. Par exemple, si vous créez une ACL appelée`Administrators`, la chaîne d'accès de tout utilisateur que vous ajoutez à ce groupe doit être définie de manière à avoir un accès complet aux touches et aux commandes. Pour les utilisateurs d'une `e-commerce` ACL, vous pouvez définir leurs chaînes d'accès en lecture seule.
MemoryDB configure automatiquement un utilisateur par défaut par compte avec un nom d'utilisateur. `"default"` Il ne sera associé à aucun cluster sauf s'il est explicitement ajouté à une ACL. Vous ne pouvez pas le supprimer ou le modifier. Cet utilisateur est destiné à être compatible avec le comportement par défaut des versions précédentes de Redis OSS et dispose d'une chaîne d'accès qui lui permet d'appeler toutes les commandes et d'accéder à toutes les touches.
Une ACL « open access » immuable sera créée pour chaque compte contenant l'utilisateur par défaut. Il s'agit de la seule ACL dont l'utilisateur par défaut peut être membre. Lorsque vous créez un cluster, vous devez sélectionner une ACL à associer au cluster. Bien que vous ayez la possibilité d'appliquer l'ACL « libre accès » à l'utilisateur par défaut, nous vous recommandons vivement de créer une ACL avec des utilisateurs dont les autorisations sont limitées à leurs besoins commerciaux.
Les clusters sur lesquels le protocole TLS n'est pas activé doivent utiliser l'ACL « open access » pour fournir une authentification ouverte.
ACLs peut être créé sans aucun utilisateur. Une ACL vide n'aurait aucun accès à un cluster et ne pourrait être associée qu'à des clusters compatibles TLS.
Lors de la création d'un utilisateur, vous pouvez configurer jusqu'à deux mots de passe. Lorsque vous modifiez un mot de passe, toutes les connexions existantes aux clusters sont conservées.
Tenez compte en particulier de ces contraintes liées au mot de passe utilisateur lors de l'utilisation ACLs de MemoryDB :
+ Les mots de passe doivent comporter de 16 à 128 caractères imprimables.
+ Les caractères non alphanumériques suivants ne sont pas autorisés : `,` `""` `/` `@`.
#### Gestion des utilisateurs avec la console et la CLI
##### Création d'un utilisateur (console)
**Pour créer des utilisateurs sur la 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, sélectionnez **Utilisateurs**.
1. Sélectionnez **Créer un utilisateur**
1. Sur la page **Créer un utilisateur**, entrez un **nom**.
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. Sous **Mots de passe**, vous pouvez saisir jusqu'à deux mots de passe.
1. Sous **Chaîne d'accès**, entrez une chaîne d'accès. La chaîne d'accès définit le niveau d'autorisation accordé à l'utilisateur pour les clés et commandes.
1. Pour les **tags**, vous pouvez éventuellement appliquer des tags pour rechercher et filtrer vos utilisateurs ou suivre vos AWS coûts.
1. Choisissez **Créer**.
##### Création d'un utilisateur à l'aide du AWS CLI
**Pour créer un utilisateur à l'aide de la CLI**
+ Utilisez la commande [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) pour créer un utilisateur.
Pour Linux, macOS ou Unix :
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
Pour Windows :
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modifier un utilisateur (console)
**Pour modifier les utilisateurs sur la 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, sélectionnez **Utilisateurs**.
1. Cliquez sur le bouton radio à côté de l'utilisateur que vous souhaitez modifier, puis choisissez **Actions** -> **Modifier**
1. Si vous souhaitez modifier un mot de passe, cliquez sur le bouton radio **Modifier les mots de passe**. Notez que si vous avez deux mots de passe, vous devez saisir les deux lorsque vous modifiez l'un d'entre eux.
1. Si vous mettez à jour la chaîne d'accès, entrez la nouvelle.
1. Sélectionnez **Modifier**.
##### Modifier un utilisateur à l'aide de AWS CLI
**Pour modifier un utilisateur à l'aide de la CLI**
1. Utilisez la commande [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) pour modifier un utilisateur.
1. Lorsqu'un utilisateur est modifié, les listes de contrôle d'accès associées à l'utilisateur sont mises à jour, ainsi que tous les clusters associés à l'ACL. Toutes les connexions existantes sont maintenues. Voici quelques exemples.
Pour Linux, macOS ou Unix :
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
Pour Windows :
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Afficher les détails de l'utilisateur (console)
**Pour afficher les détails de l'utilisateur sur la 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, sélectionnez **Utilisateurs**.
1. Choisissez l'utilisateur sous **Nom d'utilisateur** ou utilisez le champ de recherche pour trouver l'utilisateur.
1. Dans **Paramètres utilisateur**, vous pouvez consulter la chaîne d'accès, le nombre de mots de passe, le statut et le nom de ressource Amazon (ARN) de l'utilisateur.
1. Sous **Listes de contrôle d'accès (ACL)**, vous pouvez consulter l'ACL à laquelle appartient l'utilisateur.
1. Sous **Tags**, vous pouvez consulter tous les tags associés à l'utilisateur.
##### Afficher les détails de l'utilisateur à l'aide du AWS CLI
Utilisez la commande [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) pour afficher les détails d'un utilisateur.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Supprimer un utilisateur (console)
**Pour supprimer des utilisateurs sur la 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, sélectionnez **Utilisateurs**.
1. Cliquez sur le bouton radio à côté de l'utilisateur que vous souhaitez modifier, puis choisissez **Actions** -> **Supprimer**
1. Pour confirmer, entrez `delete` dans la zone de texte de confirmation, puis choisissez **Supprimer**.
1. Pour annuler, choisissez **Cancel (Annuler)**.
##### Supprimer un utilisateur à l'aide du AWS CLI
**Pour supprimer un utilisateur à l'aide de la CLI**
+ Utilisez la commande [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) pour supprimer un utilisateur.
Le compte est supprimé et retiré de toutes les listes de contrôle d'accès auxquelles il appartient. Voici un exemple.
Pour Linux, macOS ou Unix :
```
aws memorydb delete-user \
--user-name user-name-2
```
Pour Windows :
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Gestion des listes de contrôle d'accès avec la console et la CLI
Vous pouvez créer des listes de contrôle d'accès pour organiser et contrôler l'accès des utilisateurs à un ou plusieurs clusters, comme indiqué ci-dessous.
Utilisez la procédure suivante pour gérer les listes de contrôle d'accès à l'aide de la console.
#### Création d'une liste de contrôle d'accès (ACL) (console)
**Pour créer une liste de contrôle d'accès à l'aide de la 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 **Listes de contrôle d'accès (ACL)**.
1. Choisissez **Create ACL**.
1. Sur la page **Créer une liste de contrôle d'accès (ACL)**, entrez un nom d'ACL.
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. Sous **Utilisateurs sélectionnés**, effectuez l'une des opérations suivantes :
1. Créez un nouvel utilisateur en choisissant **Créer un utilisateur**
1. Ajoutez des utilisateurs en choisissant **Gérer**, puis en sélectionnant des utilisateurs dans la boîte de dialogue **Gérer les utilisateurs**, puis en sélectionnant **Choisir**.
1. Pour les **balises**, vous pouvez éventuellement appliquer des balises pour rechercher et filtrer vos coûts ACLs ou suivre vos AWS coûts.
1. Choisissez **Créer**.
#### Création d'une liste de contrôle d'accès (ACL) à l'aide du AWS CLI
Utilisez les procédures suivantes pour créer une liste de contrôle d'accès à l'aide de la CLI.
**Pour créer une nouvelle ACL et ajouter un utilisateur à l'aide de la CLI**
+ Utilisez la commande [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) pour créer une ACL.
Pour Linux, macOS ou Unix :
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
Pour Windows :
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modifier une liste de contrôle d'accès (ACL) (console)
**Pour modifier une liste de contrôle d'accès à l'aide de la 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 **Listes de contrôle d'accès (ACL)**.
1. Choisissez l'ACL que vous souhaitez modifier, puis choisissez **Modifier**
1. Sur la page **Modifier**, sous **Utilisateurs sélectionnés**, effectuez l'une des opérations suivantes :
1. Créez un nouvel utilisateur en choisissant **Create user** à ajouter à l'ACL.
1. Ajoutez ou supprimez des utilisateurs en choisissant **Gérer**, puis en sélectionnant ou désélectionnant des utilisateurs dans la boîte de dialogue **Gérer les utilisateurs**, puis en sélectionnant **Choisir**.
1. Sur la page **Créer une liste de contrôle d'accès (ACL)**, entrez un nom d'ACL.
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. Sous **Utilisateurs sélectionnés**, effectuez l'une des opérations suivantes :
1. Créez un nouvel utilisateur en choisissant **Créer un utilisateur**
1. Ajoutez des utilisateurs en choisissant **Gérer**, puis en sélectionnant des utilisateurs dans la boîte de dialogue **Gérer les utilisateurs**, puis en sélectionnant **Choisir**.
1. Choisissez **Modifier** pour enregistrer vos modifications ou **Annuler** pour les ignorer.
#### Modification d'une liste de contrôle d'accès (ACL) à l'aide du AWS CLI
**Pour modifier une ACL en ajoutant de nouveaux utilisateurs ou en supprimant des membres actuels à l'aide de la CLI**
+ Utilisez la commande [update-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html) pour modifier une ACL.
Pour Linux, macOS ou Unix :
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
Pour Windows :
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**Note**
Cette commande met fin à toutes les connexions ouvertes appartenant à un utilisateur supprimé d'une ACL.
#### Affichage des détails de la liste de contrôle d'accès (ACL) (console)
**Pour afficher les détails de l'ACL sur la 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 **Listes de contrôle d'accès (ACL)**.
1. Choisissez l'ACL sous le **nom de l'ACL** ou utilisez le champ de recherche pour trouver l'ACL.
1. Sous **Utilisateurs**, vous pouvez consulter la liste des utilisateurs associés à l'ACL.
1. Sous **Clusters associés**, vous pouvez consulter le cluster auquel appartient l'ACL.
1. Sous **Tags**, vous pouvez consulter tous les tags associés à l'ACL.
#### Affichage des listes de contrôle d'accès (ACL) à l'aide du AWS CLI
Utilisez la commande [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) pour afficher les détails d'une ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Supprimer une liste de contrôle d'accès (ACL) (console)
**Pour supprimer des listes de contrôle d'accès à l'aide de la 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 **Listes de contrôle d'accès (ACL)**.
1. Choisissez l'ACL que vous souhaitez modifier, puis choisissez **Supprimer**
1. Sur la page **Supprimer**, entrez `delete` dans la case de confirmation et choisissez **Supprimer** ou **Annuler** pour éviter de supprimer l'ACL.
C'est l'ACL elle-même, et non les utilisateurs appartenant au groupe, qui est supprimée.
#### Suppression d'une liste de contrôle d'accès (ACL) à l'aide du AWS CLI
**Pour supprimer une ACL à l'aide de la CLI**
+ Utilisez la commande [delete-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) pour supprimer une ACL.
Pour Linux, macOS ou Unix :
```
aws memorydb delete-acl /
--acl-name
```
Pour Windows :
```
aws memorydb delete-acl ^
--acl-name
```
Les exemples précédents renvoient la réponse suivante.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Affectation de listes de contrôle d'accès aux clusters
Après avoir créé une ACL et ajouté des utilisateurs, la dernière étape de la mise en œuvre ACLs consiste à attribuer l'ACL à un cluster.
#### Affectation de listes de contrôle d'accès à des clusters à l'aide de la console
Pour ajouter une ACL à un cluster à l'aide du AWS Management Console, voir[Création d'un cluster MemoryDB](getting-started.md#clusters.create).
#### Affectation de listes de contrôle d'accès à des clusters à l'aide du AWS CLI
L' AWS CLI opération suivante crée un cluster avec le chiffrement en transit (TLS) activé et le **acl-name** paramètre avec la valeur`my-acl-name`. Remplacez le groupe de sous-réseaux `subnet-group` par un groupe de sous-réseaux existant.
**Paramètres clés**
+ **--engine-version**— Doit être 6,2.
+ **--tls-enabled**— Utilisé pour l'authentification et pour associer une ACL.
+ **--acl-name**— Cette valeur fournit des listes de contrôle d'accès composées d'utilisateurs dotés d'autorisations d'accès spécifiées pour le cluster.
Pour Linux, macOS ou Unix :
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
Pour Windows :
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
L' AWS CLI opération suivante modifie un cluster dont le chiffrement en transit (TLS) est activé et dont le **acl-name** paramètre contient la valeur. `new-acl-2`
Pour Linux, macOS ou Unix :
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
Pour Windows :
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# Authentification avec IAM
**Topics**
+ [Présentation de](#auth-iam-overview)
+ [Limitations](#auth-iam-limits)
+ [Configuration](#auth-iam-setup)
+ [Connexion](#auth-iam-Connecting)
## Présentation de
Avec l'authentification IAM, vous pouvez authentifier une connexion à MemoryDB à l'aide d'identités AWS IAM, lorsque votre cluster est configuré pour utiliser Valkey ou Redis OSS version 7 ou supérieure. Cela vous permet de renforcer votre modèle de sécurité et de simplifier de nombreuses tâches administratives de sécurité. Avec l'authentification IAM, vous pouvez configurer un contrôle d'accès précis pour chaque cluster MemoryDB individuel et chaque utilisateur de MemoryDB et suivre les principes d'autorisation du moindre privilège. L'authentification IAM pour MemoryDB fonctionne en fournissant un jeton d'authentification IAM de courte durée au lieu d'un mot de passe utilisateur MemoryDB de longue durée dans la commande or. `AUTH` `HELLO` Pour plus d'informations sur le jeton d'authentification IAM, reportez-vous au [processus de signature Signature version 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) du Guide de référence AWS général et à l'exemple de code ci-dessous.
Vous pouvez utiliser les identités IAM et leurs politiques associées pour restreindre davantage l'accès à Valkey ou Redis OSS. Vous pouvez également accorder l'accès aux utilisateurs depuis leurs fournisseurs d'identité fédérés directement aux clusters MemoryDB.
Pour utiliser AWS IAM avec MemoryDB, vous devez d'abord créer un utilisateur MemoryDB avec le mode d'authentification défini sur IAM, puis vous pouvez créer ou réutiliser une identité IAM. L'identité IAM a besoin d'une politique associée pour accorder l'`memorydb:Connect`action au cluster MemoryDB et à l'utilisateur MemoryDB. Une fois configuré, vous pouvez créer un jeton d'authentification IAM à l'aide des AWS informations d'identification de l'utilisateur ou du rôle IAM. Enfin, vous devez fournir le jeton d'authentification IAM de courte durée sous forme de mot de passe dans votre client Valkey ou Redis OSS lorsque vous vous connectez à votre nœud de cluster MemoryDB. Un client prenant en charge le fournisseur d'informations d'identification peut générer automatiquement les informations d'identification temporaires pour chaque nouvelle connexion. MemoryDB effectuera l'authentification IAM pour les demandes de connexion des utilisateurs de MemoryDB compatibles IAM et validera les demandes de connexion avec IAM.
## Limitations
Les limites suivantes s'appliquent avec l'authentification IAM :
+ L'authentification IAM est disponible lors de l'utilisation de Valkey ou du moteur Redis OSS version 7.0 ou supérieure.
+ Le jeton d'authentification IAM est valide pendant 15 minutes. Pour les connexions de longue durée, nous vous recommandons d'utiliser un client Redis OSS qui prend en charge une interface de fournisseur d'informations d'identification.
+ Une connexion authentifiée IAM à MemoryDB sera automatiquement déconnectée au bout de 12 heures. La connexion peut être prolongée de 12 heures en envoyant une commande `AUTH` ou `HELLO` avec un nouveau jeton d'authentification IAM.
+ L'authentification IAM n'est pas prise en charge dans les commandes `MULTI EXEC`.
+ Actuellement, l'authentification IAM ne prend pas en charge toutes les clés de contexte de condition globale. Pour plus d'informations sur les clés de contexte de condition globale, consultez [Clés de contexte de condition globale AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le Guide de l'utilisateur IAM.
## Configuration
Pour configurer une authentification IAM :
1. Créer un cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. Créez un document de stratégie d'approbation IAM, comme indiqué ci-dessous, pour votre rôle afin d'autoriser votre compte à assumer le nouveau rôle. Enregistrez la politique dans un fichier nommé *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Créez un document de politique IAM, comme indiqué ci-dessous. Enregistrez la politique dans un fichier nommé *policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Créez un rôle IAM.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Créez la politique IAM.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Attachez la politique gérée IAM au rôle.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Créez un compte utilisateur prenant en charge IAM.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Créez une ACL et attachez l'utilisateur.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## Connexion
**Se connecter avec un jeton comme mot de passe**
Vous devez d'abord générer le jeton d'authentification IAM de courte durée à l'aide d'une [Demande pré-signée AWS SigV4](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). Ensuite, vous fournissez le jeton d'authentification IAM comme mot de passe lors de la connexion à un cluster MemoryDB, comme indiqué dans l'exemple ci-dessous.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Vous trouverez ci-dessous la définition de `IAMAuthTokenRequest`.
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**Se connecter avec un fournisseur d'informations d'identification**
Le code ci-dessous montre comment s'authentifier auprès de MemoryDB à l'aide du fournisseur d'identifiants d'authentification IAM.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Vous trouverez ci-dessous un exemple de client de cluster Lettuce qui intègre un fournisseur d'informations d'identification pour générer automatiquement des informations d'identification temporaires IAMAuth TokenRequest en cas de besoin.
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```
# Gestion des identités et des accès dans MemoryDB
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources MemoryDB. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment fonctionne MemoryDB avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
+ [Résolution des problèmes d'identité et d'accès à MemoryDB](security_iam_troubleshoot.md)
+ [Contrôle d’accès](#iam.accesscontrol)
+ [Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB](iam.overview.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes d'identité et d'accès à MemoryDB](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment fonctionne MemoryDB avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md))
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération AWS CLI ou AWS API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Comment fonctionne MemoryDB avec IAM
Avant d'utiliser IAM pour gérer l'accès à MemoryDB, découvrez quelles fonctionnalités IAM peuvent être utilisées avec MemoryDB.
**Fonctionnalités IAM que vous pouvez utiliser avec MemoryDB**
| Fonctionnalité IAM | Support de MemoryDB |
| --- | --- |
| [Politiques basées sur l’identité](#security_iam_service-with-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies) | Non |
| [Actions de politique](#security_iam_service-with-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#security_iam_service-with-iam-id-based-policies-resources) | Oui |
| [Clés de condition de politique](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Oui |
| [ACLs](#security_iam_service-with-iam-acls) | Oui |
| [ABAC (étiquettes dans les politiques)](#security_iam_service-with-iam-tags) | Oui |
| [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Autorisations de principal](#security_iam_service-with-iam-principal-permissions) | Oui |
| [Rôles de service](#security_iam_service-with-iam-roles-service) | Oui |
| [Rôles liés à un service](#security_iam_service-with-iam-roles-service-linked) | Oui |
*Pour obtenir une vue d'ensemble du fonctionnement de MemoryDB et des autres AWS services avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM dans le guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
## Politiques basées sur l'identité pour MemoryDB
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de politiques basées sur l'identité pour MemoryDB
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
## Politiques basées sur les ressources dans MemoryDB
**Prend en charge les politiques basées sur les ressources :** non
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Actions de politique pour MemoryDB
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
*Pour voir la liste des actions MemoryDB, voir [Actions définies par MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) dans la référence d'autorisation de service.*
Les actions de politique dans MemoryDB utilisent le préfixe suivant avant l'action :
```
MemoryDB
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"MemoryDB:action1",
"MemoryDB:action2"
]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "MemoryDB:Describe*"
```
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
## Ressources relatives aux politiques pour MemoryDB
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
*Pour consulter la liste des types de ressources MemoryDB et leurs caractéristiques ARNs, consultez la section [Ressources définies par MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies) dans la référence d'autorisation de service.* Pour savoir avec quelles actions vous pouvez spécifier l'ARN de chaque ressource, voir [Actions définies par MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions).
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
## Clés de conditions de politique pour MemoryDB
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
### Utilisation de clés de condition
Vous pouvez spécifier des conditions pour déterminer comment une politique IAM prend effet. Dans MemoryDB, vous pouvez utiliser l'`Condition`élément d'une politique JSON pour comparer les clés dans le contexte de la demande avec les valeurs clés que vous spécifiez dans votre politique. Pour plus d'informations, consultez [Éléments de politique JSON IAM : condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html).
*Pour consulter la liste des clés de condition de MemoryDB, voir Clés de [condition pour MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys) dans la référence d'autorisation de service.*
Pour obtenir la liste de toutes les clés de condition globales, veuillez consulter [Clés de contexte de condition globales AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
#### Spécification de conditions : Utilisation de clés de condition
Pour mettre en œuvre un contrôle précis, vous pouvez rédiger une politique d'autorisation IAM qui spécifie les conditions permettant de contrôler un ensemble de paramètres individuels pour certaines demandes. Vous pouvez ensuite appliquer la politique aux utilisateurs, groupes ou rôles IAM que vous créez à l'aide de la console IAM.
Pour appliquer une condition, vous ajoutez les informations de condition à la déclaration de politique IAM. Par exemple, pour interdire la création d'un cluster MemoryDB avec le protocole TLS désactivé, vous pouvez spécifier la condition suivante dans votre déclaration de politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "false"
}
}
}
]
}
```
------
Pour plus d'informations sur le balisage, consultez[Marquer vos ressources MemoryDB](tagging-resources.md).
Pour plus d'informations sur l'utilisation d'opérateurs de condition de politique, veuillez consulter [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md).
#### Exemples de politique : Utilisation de conditions pour un contrôle de paramètre détaillé
Cette section présente des exemples de politiques pour implémenter un contrôle d'accès précis sur les paramètres MemoryDB répertoriés précédemment.
1. **memorydb : TLSEnabled** — Spécifiez que les clusters seront créés uniquement avec le protocole TLS activé.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"arn:aws:memorydb:*:*:parametergroup/*",
"arn:aws:memorydb:*:*:subnetgroup/*",
"arn:aws:memorydb:*:*:acl/*"
]
},
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "true"
}
}
}
]
}
```
------
1. **memorydb : UserAuthenticationMode :** — Spécifiez que les utilisateurs peuvent être créés avec un mode d'authentification de type spécifique (IAM par exemple).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:Createuser"
],
"Resource": [
"arn:aws:memorydb:*:*:user/*"
],
"Condition": {
"StringEquals": {
"memorydb:UserAuthenticationMode": "iam"
}
}
}
]
}
```
------
Dans les cas où vous définissez des politiques basées sur le « refus », il est recommandé d'utiliser l'[StringEqualsIgnoreCase](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)opérateur pour éviter tous les appels avec un type de mode d'authentification utilisateur spécifique, quel que soit le cas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"memorydb:UserAuthenticationMode": "password"
}
}
}
]
}
```
------
## Listes de contrôle d'accès (ACLs) dans MemoryDB
**Supports ACLs :** Oui
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## Contrôle d'accès basé sur les attributs (ABAC) avec MemoryDB
**Prise en charge d’ABAC (balises dans les politiques) :** Oui
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation d'informations d'identification temporaires avec MemoryDB
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Autorisations principales interservices pour MemoryDB
**Prend en charge les sessions d’accès direct (FAS) :** oui
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour MemoryDB
**Prend en charge les rôles de service :** oui
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
**Avertissement**
La modification des autorisations pour un rôle de service peut interrompre les fonctionnalités de MemoryDB. Modifiez les rôles de service uniquement lorsque MemoryDB fournit des instructions à cet effet.
## Rôles liés à un service pour MemoryDB
**Prend en charge les rôles liés à un service :** oui
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Pour plus d’informations sur la création ou la gestion des rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Recherchez un service dans le tableau qui inclut un `Yes` dans la colonne **Rôle lié à un service**. Choisissez le lien **Oui** pour consulter la documentation du rôle lié à ce service.
# Exemples de politiques basées sur l'identité pour MemoryDB
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources MemoryDB. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
*Pour plus de détails sur les actions et les types de ressources définis par MemoryDB, y compris le ARNs format de chaque type de ressource, voir [Actions, ressources et clés de condition pour MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html) dans la référence d'autorisation de service.*
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console MemoryDB](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
## Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources MemoryDB dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console MemoryDB
Pour accéder à la console MemoryDB, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher les détails des ressources MemoryDB de votre. Compte AWS Si vous créez une politique basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette politique.
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.
Pour garantir que les utilisateurs et les rôles peuvent toujours utiliser la console MemoryDB, attachez également la MemoryDB `ConsoleAccess` ou la politique `ReadOnly` AWS gérée aux entités. Pour plus d’informations, consultez [Ajout d’autorisations à un utilisateur](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dans le *Guide de l’utilisateur IAM*.
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Résolution des problèmes d'identité et d'accès à MemoryDB
Utilisez les informations suivantes pour diagnostiquer et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec MemoryDB et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans MemoryDB](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources MemoryDB](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans MemoryDB
S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni votre nom d’utilisateur et votre mot de passe.
L’exemple d’erreur suivant se produit quand l’utilisateur `mateojackson` tente d’utiliser la console pour afficher des informations détaillées sur une ressource `my-example-widget` fictive, mais ne dispose pas des autorisations `MemoryDB:GetWidget` fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: MemoryDB:GetWidget on resource: my-example-widget
```
Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `my-example-widget` à l’aide de l’action `MemoryDB:GetWidget`.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à effectuer l'`iam:PassRole`action, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à MemoryDB.
Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé `marymajor` essaie d'utiliser la console pour effectuer une action dans MemoryDB. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources MemoryDB
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si MemoryDB prend en charge ces fonctionnalités, consultez. [Comment fonctionne MemoryDB avec IAM](security_iam_service-with-iam.md)
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Contrôle d’accès
Vous pouvez disposer d'informations d'identification valides pour authentifier vos demandes, mais vous ne pouvez pas créer de ressources MemoryDB ou y accéder sans autorisation. Par exemple, vous devez disposer des autorisations nécessaires pour créer un cluster MemoryDB.
Les sections suivantes décrivent comment gérer les autorisations pour MemoryDB. Nous vous recommandons de lire d’abord la présentation.
+ [Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB](iam.overview.md)
+ [Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB](iam.identitybasedpolicies.md)
# Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB
Chaque AWS ressource appartient à un AWS compte, et les autorisations de création ou d'accès à une ressource sont régies par des politiques d'autorisation. Un compte administrateur peut attacher des politiques d'autorisations à des identités IAM (c'est-à-dire des utilisateurs, des groupes et des rôles). En outre, MemoryDB prend également en charge l'attachement de politiques d'autorisation aux ressources.
**Note**
Un *administrateur de compte* (ou utilisateur administrateur) est un utilisateur doté des privilèges d’administrateur. Pour plus d'informations, consultez [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l'utilisateur IAM*.
Pour activer l’accès, ajoutez des autorisations à vos utilisateurs, groupes ou rôles :
+ Utilisateurs et groupes dans AWS IAM Identity Center :
Créez un jeu d’autorisations. Suivez les instructions de la rubrique [Création d’un jeu d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) du *Guide de l’utilisateur AWS IAM Identity Center *.
+ Utilisateurs gérés dans IAM par un fournisseur d’identité :
Créez un rôle pour la fédération d’identité. Suivez les instructions de la rubrique [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*.
+ Utilisateurs IAM :
+ Créez un rôle que votre utilisateur peut assumer. Suivez les instructions de la rubrique [Création d’un rôle pour un utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
+ (Non recommandé) Attachez une politique directement à un utilisateur ou ajoutez un utilisateur à un groupe d’utilisateurs. Suivez les instructions de la rubrique [Ajout d’autorisations à un utilisateur (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) du *Guide de l’utilisateur IAM*.
**Topics**
+ [Ressources et opérations de MemoryDB](#iam.overview.resourcesandoperations)
+ [Présentation de la propriété des ressources](#access-control-resource-ownership)
+ [Gestion de l’accès aux ressources](#iam.overview.managingaccess)
+ [Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB](iam.identitybasedpolicies.md)
+ [Autorisations de niveau ressource](iam.resourcelevelpermissions.md)
+ [Utilisation de rôles liés à un service pour MemoryDB](using-service-linked-roles.md)
+ [AWS politiques gérées pour MemoryDB](security-iam-awsmanpol.md)
+ [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
## Ressources et opérations de MemoryDB
*Dans MemoryDB, la ressource principale est un cluster.*
Ces ressources sont associées à des noms de ressources Amazon (ARNs) uniques, comme indiqué ci-dessous.
**Note**
Pour que les autorisations au niveau des ressources soient efficaces, le nom de la ressource sur la chaîne ARN doit être en minuscules.
****
| Type de ressource | Format ARN |
| --- | --- |
| Utilisateur | arn:aws:memorydb ::user/user1 *us-east-1:123456789012* |
| Liste de contrôle d'accès (ACL) | arn:aws:memorydb ::acl/myacl *us-east-1:123456789012* |
| Cluster | arn:aws:memorydb ::cluster/my-cluster *us-east-1:123456789012* |
| Instantané | arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012* |
| Groupe de paramètres | arn:aws:memorydb ::parametergroup/ *us-east-1:123456789012* my-parameter-group |
| Groupe de sous-réseaux | arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group |
MemoryDB fournit un ensemble d'opérations permettant de travailler avec les ressources MemoryDB. [Pour une liste des opérations disponibles, consultez la section Actions MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)
## Présentation de la propriété des ressources
*Le propriétaire d'une ressource* est le AWS compte qui a créé la ressource. En d'autres termes, le propriétaire de la ressource est le AWS compte de l'entité principale qui authentifie la demande qui crée la ressource. Une *entité principale* peut être le compte root, un utilisateur IAM ou un rôle IAM. Les exemples suivants illustrent comment cela fonctionne :
+ Supposons que vous utilisiez les informations d'identification du compte root de votre AWS compte pour créer un cluster. Dans ce cas, votre AWS compte est le propriétaire de la ressource. Dans MemoryDB, la ressource est le cluster.
+ Supposons que vous créiez un utilisateur IAM dans votre AWS compte et que vous accordiez des autorisations pour créer un cluster à cet utilisateur. Dans ce cas, l'utilisateur peut créer un cluster. Toutefois, votre AWS compte, auquel appartient l'utilisateur, est propriétaire de la ressource du cluster.
+ Supposons que vous créiez un rôle IAM dans votre AWS compte avec les autorisations nécessaires pour créer un cluster. Dans ce cas, toute personne capable d'assumer ce rôle peut créer un cluster. Votre AWS compte, auquel appartient le rôle, est propriétaire de la ressource du cluster.
## Gestion de l’accès aux ressources
Une *politique d'autorisation* décrit qui a accès à quoi. La section suivante explique les options disponibles pour créer des politiques d'autorisations.
**Note**
Cette section décrit l'utilisation d'IAM dans le contexte de MemoryDB. Elle ne fournit pas d’informations détaillées sur le service IAM. Pour une documentation complète sur IAM, consultez [Qu'est-ce que IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) dans le *Guide de l'utilisateur IAM*. Pour plus d'informations sur la syntaxe et les descriptions des stratégies IAM, consultez [Référence de stratégie AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) dans le *Guide de l'utilisateur IAM*.
Les politiques attachées à une identité IAM sont appelées des politiques *basées sur l'identité* (politiques IAM). Les stratégies attachées à une ressource sont appelées stratégies *basées sur une ressource*.
**Topics**
+ [Politiques basées sur une identité (politiques IAM)](#iam.overview.managingaccess.identitybasedpolicies)
+ [Spécification des éléments d'une politique : actions, effets, ressources et mandataires](#iam.overview.policyelements)
+ [Spécification de conditions dans une politique](#iam.specifyconditions)
### Politiques basées sur une identité (politiques IAM)
Vous pouvez attacher des politiques à des identités IAM. Par exemple, vous pouvez effectuer les opérations suivantes :
+ **Attacher une politique d'autorisations à un utilisateur ou à un groupe dans votre compte** : un administrateur de compte peut utiliser une politique d'autorisations associée à un utilisateur particulier pour accorder des autorisations. Dans ce cas, les autorisations permettent à cet utilisateur de créer une ressource MemoryDB, telle qu'un cluster, un groupe de paramètres ou un groupe de sécurité.
+ **Attacher une politique d'autorisations à un rôle (accorder des autorisations entre comptes)** : vous pouvez attacher une politique d'autorisation basée sur une identité à un rôle IAM afin d'accorder des autorisations entre comptes. Par exemple, l'administrateur du compte A peut créer un rôle pour accorder des autorisations entre comptes à un autre AWS compte (par exemple, le compte B) ou à un AWS service comme suit :
1. L'administrateur du Compte A crée un rôle IAM et attache une politique d'autorisation à ce rôle qui accorde des autorisations sur les ressources dans le Compte A.
1. L'administrateur du Compte A attache une politique d'approbation au rôle identifiant le Compte B comme principal pouvant assumer ce rôle.
1. L'administrateur du compte B peut ensuite déléguer les autorisations nécessaires pour assumer le rôle à n'importe quel utilisateur du compte B. Cela permet aux utilisateurs du compte B de créer des ressources ou d'accéder à des ressources dans le compte A. Dans certains cas, vous souhaiterez peut-être accorder à un AWS service des autorisations lui permettant d'assumer le rôle. Pour soutenir cette approche, le principal dans la politique d'approbation peut également être un mandataire du service AWS .
Pour en savoir plus sur l'utilisation d'IAM pour déléguer des autorisations, consultez [Gestion des accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) dans le *Guide de l'utilisateur IAM*.
Voici un exemple de politique qui permet à un utilisateur d'effectuer l'`DescribeClusters`action pour votre AWS compte. MemoryDB prend également en charge l'identification de ressources spécifiques à l'aide de la ressource ARNs pour les actions d'API. (Cette approche est également appelée autorisations au niveau des ressources.)
Pour plus d'informations sur l'utilisation de politiques basées sur l'identité avec MemoryDB, consultez. [Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB](iam.identitybasedpolicies.md) Pour de plus amples informations sur les utilisateurs, les groupes, les rôles et les autorisations, veuillez consulter [Identités (utilisateurs, groupes et rôles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) dans le *Guide de l'utilisateur IAM*.
### Spécification des éléments d'une politique : actions, effets, ressources et mandataires
Pour chaque ressource MemoryDB (voir[Ressources et opérations de MemoryDB](#iam.overview.resourcesandoperations)), le service définit un ensemble d'opérations d'API (voir [Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)). Pour accorder des autorisations pour ces opérations d'API, MemoryDB définit un ensemble d'actions que vous pouvez spécifier dans une politique. Par exemple, pour la ressource de cluster MemoryDB, les actions suivantes sont définies : `CreateCluster``DeleteCluster`, et. `DescribeClusters` Une opération d’API peut exiger des autorisations pour plusieurs actions.
Voici les éléments les plus élémentaires d'une politique :
+ **Ressource** : dans une politique, vous utilisez un Amazon Resource Name (ARN) pour identifier la ressource à laquelle la politique s'applique. Pour de plus amples informations, veuillez consulter [Ressources et opérations de MemoryDB](#iam.overview.resourcesandoperations).
+ **Action :** vous utilisez des mots clés d’action pour identifier les opérations de ressource que vous voulez accorder ou refuser. Par exemple, en fonction de ce qui est spécifié`Effect`, l'`memorydb:CreateCluster`autorisation autorise ou refuse à l'utilisateur l'autorisation d'effectuer l'opération MemoryDB`CreateCluster`.
+ **Effet** – Vous spécifiez l’effet produit lorsque l’utilisateur demande l’action spécifique, qui peut être une autorisation ou un refus. Si vous n’accordez pas explicitement l’accès pour (autoriser) une ressource, l’accès est implicitement refusé. Vous pouvez également explicitement refuser l’accès à une ressource. Par exemple,vous pouvez le faire afin de vous assurer qu'un utilisateur n'y a pas accès, même si une politique différente accorde cet accès.
+ **Principal** : dans les politiques basées sur une identité (politiques IAM), l'utilisateur auquel la politique est attachée est le principal implicite. Pour les politiques basées sur une ressource, vous spécifiez l'utilisateur, le compte, le service ou une autre entité qui doit recevoir les autorisations (s'applique uniquement aux politiques basées sur une ressource).
Pour en savoir plus sur la syntaxe des stratégies IAM et pour obtenir des descriptions, consultez [Référence de stratégie IAM AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) dans le *Guide de l'utilisateur IAM*.
Pour un tableau présentant toutes les actions de l'API MemoryDB, consultez. [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
### Spécification de conditions dans une politique
Lorsque vous accordez des autorisations, vous pouvez utiliser le langage des politiques IAM afin de spécifier les conditions définissant à quel moment une politique doit prendre effet. Par exemple, il est possible d'appliquer une politique après seulement une date spécifique. Pour plus d'informations sur la spécification de conditions dans un langage de politique, consultez [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) dans le *Guide de l'utilisateur IAM*.
# Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB
Cette rubrique fournit des exemples de politiques basées sur une identité dans lesquelles un administrateur de compte peut attacher des politiques d'autorisation aux identités IAM (c'est-à-dire aux utilisateurs, groupes et rôles).
**Important**
Nous vous recommandons de lire d'abord les rubriques qui expliquent les concepts et options de base pour gérer l'accès aux ressources MemoryDB. Pour de plus amples informations, veuillez consulter [Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB](iam.overview.md).
Les sections de cette rubrique couvrent les sujets suivants :
+ [Autorisations requises pour utiliser la console MemoryDB](#iam.identitybasedpolicies.minconpolicies)
+ [AWS-politiques gérées (prédéfinies) pour MemoryDB](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies)
+ [Exemples de politiques gérées par le client](#iam.identitybasedpolicies.customermanagedpolicies)
Un exemple de politique d'autorisation est exposé ci-dessous.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:DescribeClusters",
"memorydb:UpdateCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
```
------
La politique possède deux énoncés:
+ La première instruction accorde des autorisations pour les actions MemoryDB (`memorydb:CreateCluster`,`memorydb:DescribeClusters`, et`memorydb:UpdateCluster`) sur tout cluster appartenant au compte.
+ La deuxième instruction accorde des autorisations pour l'action IAM (`iam:PassRole`) sur le nom du rôle IAM spécifié à la fin de la valeur `Resource`.
La politique ne spécifie pas l'élément `Principal` car, dans une politique basée sur une identité, vous ne spécifiez pas le principal qui obtient l'autorisation. Quand vous attachez une politique à un utilisateur, l'utilisateur est le principal implicite. Lorsque vous attachez une politique d'autorisation à un rôle IAM, le principal identifié dans la politique d'approbation de ce rôle obtient les autorisations.
Pour un tableau présentant toutes les actions de l'API MemoryDB et les ressources auxquelles elles s'appliquent, consultez. [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
## Autorisations requises pour utiliser la console MemoryDB
Le tableau de référence des autorisations répertorie les opérations de l'API MemoryDB et indique les autorisations requises pour chaque opération. Pour plus d'informations sur les opérations de l'API MemoryDB, consultez. [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
Pour utiliser la console MemoryDB, accordez d'abord des autorisations pour des actions supplémentaires, comme indiqué dans la politique d'autorisation suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "MinPermsForMemDBConsole",
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
```
------
La console MemoryDB a besoin de ces autorisations supplémentaires pour les raisons suivantes :
+ Les autorisations pour les actions MemoryDB permettent à la console d'afficher les ressources MemoryDB dans le compte.
+ La console a besoin d'autorisations pour effectuer les `ec2` actions permettant d'interroger Amazon EC2 afin de pouvoir afficher les zones de disponibilité VPCs, les groupes de sécurité et les attributs de compte.
+ Les autorisations relatives aux `cloudwatch` actions permettent à la console de récupérer CloudWatch les métriques et les alarmes Amazon et de les afficher dans la console.
+ Les autorisations pour les actions `sns` permettent à la console de récupérer les abonnements et les rubriques Amazon Simple Notification Service (Amazon SNS), et de les afficher dans la console.
## Exemples de politiques gérées par le client
Si vous n'utilisez pas de politique par défaut et que vous choisissez d'utiliser une politique gérée personnalisée, vous devez assurer l'un des deux points suivants. Vous devez soit avoir les autorisations d'appeler `iam:createServiceLinkedRole` (pour plus d'informations, veuillez consulter [Exemple 4 : Autoriser un utilisateur à appeler l'API IAM CreateServiceLinkedRole](#create-service-linked-role-policy)). Ou vous auriez dû créer un rôle lié au service MemoryDB.
Combinés aux autorisations minimales nécessaires pour utiliser la console MemoryDB, les exemples de politiques présentés dans cette section accordent des autorisations supplémentaires. Les exemples sont également pertinents pour le AWS SDKs et le AWS CLI. Pour plus d'informations sur les autorisations nécessaires pour utiliser la console MemoryDB, consultez. [Autorisations requises pour utiliser la console MemoryDB](#iam.identitybasedpolicies.minconpolicies)
Pour plus d'informations sur la configuration des utilisateurs et des groupes IAM, veuillez consulter [Création de votre premier groupe d'utilisateurs et d'administrateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) dans le *Guide de l'utilisateur IAM*.
**Important**
Veillez à toujours tester vos politiques IAM de manière approfondie avant de les utiliser. Certaines actions MemoryDB qui semblent simples peuvent nécessiter d'autres actions pour les prendre en charge lorsque vous utilisez la console MemoryDB. Par exemple, `memorydb:CreateCluster` accorde des autorisations pour créer des clusters MemoryDB. Toutefois, pour effectuer cette opération, la console MemoryDB utilise un certain nombre d'`List`actions `Describe` et pour remplir les listes de consoles.
**Topics**
+ [Exemple 1 : autoriser un utilisateur à accéder en lecture seule aux ressources MemoryDB](#example-allow-list-current-memorydb-resources)
+ [Exemple 2 : autoriser un utilisateur à effectuer des tâches courantes d'administrateur système MemoryDB](#example-allow-specific-memorydb-actions)
+ [Exemple 3 : Autoriser un utilisateur à accéder à toutes les actions de l'API MemoryDB](#allow-unrestricted-access)
+ [Exemple 4 : Autoriser un utilisateur à appeler l'API IAM CreateServiceLinkedRole](#create-service-linked-role-policy)
### Exemple 1 : autoriser un utilisateur à accéder en lecture seule aux ressources MemoryDB
La politique suivante accorde des autorisations pour les actions MemoryDB qui permettent à un utilisateur de répertorier des ressources. En général, vous attachez ce type de politique d'autorisations à un groupe de gestionnaires.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MemDBUnrestricted",
"Effect":"Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"],
"Resource":"*"
}
]
}
```
------
### Exemple 2 : autoriser un utilisateur à effectuer des tâches courantes d'administrateur système MemoryDB
Les tâches courantes des administrateurs système incluent la modification des clusters, des paramètres et des groupes de paramètres. Un administrateur système peut également souhaiter obtenir des informations sur les événements MemoryDB. La politique suivante accorde à un utilisateur l'autorisation d'effectuer des actions MemoryDB pour ces tâches courantes d'administrateur système. Généralement, vous attachez ce type de politique d'autorisations au groupe d'administrateurs système.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MDBAllowSpecific",
"Effect": "Allow",
"Action": [
"memorydb:UpdateCluster",
"memorydb:DescribeClusters",
"memorydb:DescribeEvents",
"memorydb:UpdateParameterGroup",
"memorydb:DescribeParameterGroups",
"memorydb:DescribeParameters",
"memorydb:ResetParameterGroup"
],
"Resource": "*"
}
]
}
```
------
### Exemple 3 : Autoriser un utilisateur à accéder à toutes les actions de l'API MemoryDB
La politique suivante permet à un utilisateur d'accéder à toutes les actions MemoryDB. Nous vous conseillons d'accorder ce type de politique d'autorisations uniquement à un utilisateur administrateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MDBAllowAll",
"Effect":"Allow",
"Action":[
"memorydb:*" ],
"Resource":"*"
}
]
}
```
------
### Exemple 4 : Autoriser un utilisateur à appeler l'API IAM CreateServiceLinkedRole
La politique suivante permet à un utilisateur d'appeler l'API `CreateServiceLinkedRole` IAM. Nous vous recommandons d'accorder ce type de politique d'autorisations à l'utilisateur qui invoque des opérations mutatives de MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWS ServiceName":"memorydb.amazonaws.com"
}
}
}
]
}
```
------
# Autorisations de niveau ressource
Vous pouvez restreindre la portée des autorisations en spécifiant des ressources dans une politique IAM. De nombreuses actions d' AWS CLI API prennent en charge un type de ressource qui varie en fonction du comportement de l'action. Chaque déclaration de politique IAM accorde une autorisation pour une action effectuée sur une ressource. Lorsque l'action n'agit pas sur une ressource nommée, ou lorsque vous accordez l'autorisation d'effectuer l'action sur toutes les ressources, la valeur de la ressource de la politique est un caractère générique (\$1). Pour la plupart des actions d'API, vous pouvez limiter les ressources qu'un utilisateur peut modifier en spécifiant l'Amazon Resource Name (ARN) d'une ressource ou un modèle ARN qui correspond à plusieurs ressources. Pour limiter les autorisations par ressource, spécifiez la ressource par son ARN.
**Format ARN des ressources MemoryDB**
**Note**
Pour que les autorisations au niveau des ressources soient effectives, le nom de la ressource dans la chaîne ARN doit être en minuscules.
+ Utilisateur — arn:aws:memorydb ::user/user1 *us-east-1:123456789012*
+ ACL — arn:aws:memorydb ::acl/my-acl *us-east-1:123456789012*
+ Cluster — arn:aws:memorydb ::cluster/my-cluster *us-east-1:123456789012*
+ Snapshot — arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012*
+ Groupe de paramètres — arn:aws:memorydb ::parametergroup/ *us-east-1:123456789012* my-parameter-group
+ Groupe de sous-réseaux — arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group
**Topics**
+ [Exemple 1 : accorder à un utilisateur un accès complet à des types de ressources MemoryDB spécifiques](#example-allow-list-current-memorydb-resources-resource)
+ [Exemple 2 : refuser à un utilisateur l'accès à un cluster.](#example-allow-specific-memorydb-actions-resource)
## Exemple 1 : accorder à un utilisateur un accès complet à des types de ressources MemoryDB spécifiques
La politique suivante autorise explicitement l'accès `account-id` complet spécifié à toutes les ressources de type groupe de sous-réseaux, groupe de sécurité et cluster.
```
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:subnetgroup/*",
"arn:aws:memorydb:us-east-1:account-id:securitygroup/*",
"arn:aws:memorydb:us-east-1:account-id:cluster/*"
]
}
```
## Exemple 2 : refuser à un utilisateur l'accès à un cluster.
L'exemple suivant refuse explicitement l'`account-id`accès spécifié à un cluster particulier.
```
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:cluster/name"
]
}
```
# Utilisation de rôles liés à un service pour MemoryDB
[MemoryDB utilise des rôles liés à un service Gestion des identités et des accès AWS (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rôle lié à un service est un type unique de rôle IAM directement lié à un AWS service, tel que MemoryDB. Les rôles liés au service MemoryDB sont prédéfinis par MemoryDB. Ils comprennent toutes les autorisations requises par le service pour appeler des services AWS au nom de vos clusters.
Un rôle lié à un service facilite la configuration de MemoryDB car il n'est pas nécessaire d'ajouter manuellement les autorisations nécessaires. Les rôles existent déjà dans votre AWS compte, mais ils sont liés à des cas d'utilisation de MemoryDB et disposent d'autorisations prédéfinies. Seul MemoryDB peut assumer ces rôles, et seuls ces rôles peuvent utiliser la politique d'autorisation prédéfinie. Vous pouvez supprimer les rôles uniquement après la suppression préalable de leurs ressources connexes. Cela protège vos ressources MemoryDB car vous ne pouvez pas supprimer par inadvertance les autorisations nécessaires pour accéder aux ressources.
Pour plus d’informations sur les autres services qui prennent en charge les rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services avec un **Oui ** dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
**Contents**
+ [Autorisations de rôles liés à un service](#service-linked-role-permissions)
+ [Création d'un rôle lié à un service (IAM)](#create-service-linked-role-iam)
+ [Utilisation de la console IAM](#create-service-linked-role-iam-console)
+ [Utilisation de la CLI IAM](#create-service-linked-role-iam-cli)
+ [Utilisation de l'API IAM](#create-service-linked-role-iam-api)
+ [Modification de la description d'un rôle lié à un service](#edit-service-linked-role)
+ [Utilisation de la console IAM](#edit-service-linked-role-iam-console)
+ [Utilisation de la CLI IAM](#edit-service-linked-role-iam-cli)
+ [Utilisation de l'API IAM](#edit-service-linked-role-iam-api)
+ [Supprimer un rôle lié à un service pour MemoryDB](#delete-service-linked-role)
+ [Nettoyage d'un rôle lié à un service](#service-linked-role-review-before-delete)
+ [Suppression d'un rôle lié à un service (console IAM)](#delete-service-linked-role-iam-console)
+ [Suppression d'un rôle lié à un service (CLI IAM)](#delete-service-linked-role-iam-cli)
+ [Suppression d'un rôle lié à un service (API IAM)](#delete-service-linked-role-iam-api)
## Autorisations de rôle liées à un service pour MemoryDB
MemoryDB utilise le rôle lié à un service nommé **AWSServiceRoleForMemoryDB. Cette politique permet à MemoryDB** de gérer les AWS ressources en votre nom, selon les besoins de gestion de vos clusters.
La AWSService RoleForMemory politique d'autorisation des rôles liés au service de base de données permet à MemoryDB d'effectuer les actions suivantes sur les ressources spécifiées :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
Pour de plus amples informations, veuillez consulter [AWS politique gérée : Mémoire DBService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-memorydbServiceRolePolicy).
**Pour autoriser une entité IAM à créer des rôles liés à un service de AWSService RoleForMemory base de données**
Ajoutez la déclaration de politique suivante aux autorisations de cette entité IAM :
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
**Pour autoriser une entité IAM à supprimer des rôles liés à un service de AWSService RoleForMemory base de données**
Ajoutez la déclaration de politique suivante aux autorisations de cette entité IAM :
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
Vous pouvez également utiliser une politique AWS gérée pour fournir un accès complet à MemoryDB.
## Création d'un rôle lié à un service (IAM)
Vous pouvez créer un rôle lié à un service à l'aide de la console IAM, de la CLI ou de l'API.
### Création d'un rôle lié à un service (console IAM)
Vous pouvez utiliser la console IAM pour créer un rôle lié à un service.
**Pour créer un rôle lié à un service (console)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**. Ensuite, choisissez **Create new role (Créer un nouveau rôle)**.
1. Sous **Sélectionner un type d’entité de confiance**, choisissez **AWS Service**.
1. Sous **Ou sélectionnez un service pour afficher ses cas d'utilisation**, choisissez **MemoryDB**.
1. Choisissez **Suivant : Autorisations**.
1. Sous **Policy name (Nom de la politique)**, notez que la `MemoryDBServiceRolePolicy` est nécessaire pour ce rôle. Choisissez **Suivant : balises**.
1. Notez que les balises ne sont pas prises en charge pour les rôles liés à un service. Choisissez **Next: Review (Suivant : vérifier)**.
1. (Facultatif) Dans le champ **Description du rôle**, modifiez la description du nouveau rôle lié à un service.
1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.
### Création d'un rôle lié à un service (CLI IAM)
Vous pouvez utiliser les opérations IAM depuis le AWS Command Line Interface pour créer un rôle lié à un service. Ce rôle peut inclure la politique d'approbation et les politiques en ligne dont le service a besoin pour endosser le rôle.
**Pour créer un rôle lié à un service (CLI)**
Utilisez l'opération suivante :
```
$ aws iam [create-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) --aws-service-name memorydb.amazonaws.com
```
### Création d'un rôle lié à un service (API IAM)
Vous pouvez utiliser l'API IAM pour créer un rôle lié à un service. Ce rôle peut contenir la politique d'approbation et les politiques en ligne dont le service a besoin pour endosser le rôle.
**Pour créer un rôle lié à un service (API)**
Utilisez l'appel d'API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Dans la demande, spécifiez un nom de service sous la forme `memorydb.amazonaws.com`.
## Modification de la description d'un rôle lié à un service pour MemoryDB
MemoryDB ne vous permet pas de modifier le rôle lié au service de AWSService RoleForMemory base de données. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM.
### Modification de la description d'un rôle lié à un service (console IAM)
Vous pouvez utiliser la console IAM pour modifier la description d'un rôle lié à un service.
**Pour modifier la description d'un rôle lié à un service (console)**
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**.
1. Choisissez le nom du rôle à modifier.
1. A l'extrême droite de **Description du rôle**, choisissez **Edit (Modifier)**.
1. Saisissez une nouvelle description dans la zone et choisissez **Save (Enregistrer)**.
### Modification de la description d'un rôle lié à un service (CLI IAM)
Vous pouvez utiliser les opérations IAM depuis le AWS Command Line Interface pour modifier la description d'un rôle lié à un service.
**Pour changer la description d'un rôle d'un rôle lié à un service (CLI)**
1. (Facultatif) Pour afficher la description actuelle d'un rôle, utilisez l'opération AWS CLI `[get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)` for IAM.
**Example**
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name AWSServiceRoleForMemoryDB
```
Utilisez le nom du rôle, pas l'ARN, pour faire référence aux opérations de la CLI. Par exemple, si un rôle a l'ARN : `arn:aws:iam::123456789012:role/myrole`, faites référence au rôle en tant que **myrole**.
1. Pour mettre à jour la description d'un rôle lié à un service, utilisez l'opération AWS CLI for IAM. `[update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)`
Pour Linux, macOS ou Unix :
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) \
--role-name AWSServiceRoleForMemoryDB \
--description "new description"
```
Pour Windows :
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ^
--role-name AWSServiceRoleForMemoryDB ^
--description "new description"
```
### Modification de la description d'un rôle lié à un service (API IAM)
Vous pouvez utiliser l'API IAM pour modifier la description d'un rôle lié à un service.
**Pour changer la description d'un rôle lié à un service (API)**
1. (Facultatif) Pour afficher la description courante d'un rôle, utilisez l'opération d'API IAM [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&AUTHPARAMS
```
1. Pour mettre à jour la description d'un rôle, utilisez l'opération d'API IAM [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&Description="New description"
```
## Supprimer un rôle lié à un service pour MemoryDB
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer.
MemoryDB ne supprime pas le rôle lié au service pour vous.
### Nettoyage d'un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vérifiez d'abord qu'aucune ressource (cluster) n'est associée au rôle.
**Pour vérifier si une session est active pour le rôle lié à un service dans la console IAM**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**. Choisissez ensuite le nom (et non la case à cocher) du rôle de AWSService RoleForMemory base de données.
1. Sur la page **Récapitulatif** du rôle sélectionné, choisissez l'onglet **Access Advisor**.
1. Dans l'onglet **Access Advisor**, consultez l'activité récente pour le rôle lié à un service.
**Pour supprimer les ressources MemoryDB qui nécessitent une base de AWSService RoleForMemory données (console)**
+ Pour supprimer un cluster, consultez les rubriques suivantes :
+ [En utilisant le AWS Management Console](getting-started.md#clusters.deleteclusters.viewdetails)
+ [En utilisant le AWS CLI](getting-started.md#clusters.delete.cli)
+ [Utilisation de l'API MemoryDB](getting-started.md#clusters.delete.api)
### Suppression d'un rôle lié à un service (console IAM)
Vous pouvez utiliser la console IAM pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (console)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**. Cochez ensuite la case en regard du nom du rôle que vous souhaitez supprimer, sans sélectionner le nom ou la ligne.
1. Pour les actions sur les **Rôle** en haut de la page, sélectionnez **Supprimer**.
1. Sur la page de confirmation, passez en revue les données du dernier accès au service, qui indiquent la date à laquelle chacun des rôles sélectionnés a accédé à un AWS service pour la dernière fois. Cela vous permet de confirmer si le rôle est actif actuellement. Si vous souhaitez continuer, sélectionnez **Oui, supprimer** pour lancer la tâche de suppression du rôle.
1. Consultez les notifications de la console IAM pour surveiller la progression de la suppression du rôle lié à un service. Dans la mesure où la suppression du rôle lié à un service IAM est asynchrone, une fois que vous soumettez le rôle afin qu’il soit supprimé, la suppression peut réussir ou échouer. Si la tâche échoue, vous pouvez choisir **View details** (Afficher les détails) ou **View Resources** (Afficher les ressources) à partir des notifications pour connaître le motif de l'échec de la suppression.
### Suppression d'un rôle lié à un service (CLI IAM)
Vous pouvez utiliser les opérations IAM depuis le AWS Command Line Interface pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (CLI)**
1. Si vous ne connaissez pas le nom du rôle lié à un service que vous souhaitez supprimer, saisissez la commande suivante. Cette commande répertorie les rôles et leurs noms de ressources Amazon (ARNs) dans votre compte.
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name role-name
```
Utilisez le nom du rôle, pas l'ARN, pour faire référence aux opérations de la CLI. Par exemple, si un rôle a l'ARN `arn:aws:iam::123456789012:role/myrole`, vous faites référence au rôle en tant que **myrole**.
1. Dans la mesure où un rôle lié à un service ne peut pas être supprimé s'il est utilisé ou si des ressources lui sont associées, vous devez envoyer une demande de suppression. Cette demande peut être refusée si ces conditions ne sont pas satisfaites. Vous devez capturer le `deletion-task-id` de la réponse afin de vérifier l'état de la tâche de suppression. Saisissez la commande suivante pour envoyer une demande de suppression d'un rôle lié à un service.
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) --role-name role-name
```
1. Tapez la commande suivante pour vérifier l'état de la tâche de suppression.
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) --deletion-task-id deletion-task-id
```
L’état de la tâche de suppression peut être `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` ou `FAILED`. Si la suppression échoue, l’appel renvoie le motif de l’échec, afin que vous puissiez apporter une solution.
### Suppression d'un rôle lié à un service (API IAM)
Vous pouvez utiliser l'API IAM pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (API)**
1. Pour envoyer une demande de suppression pour un rôle lié à un service, appelez [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). Dans la demande, spécifiez le nom d'un rôle.
Dans la mesure où un rôle lié à un service ne peut pas être supprimé s'il est utilisé ou si des ressources lui sont associées, vous devez envoyer une demande de suppression. Cette demande peut être refusée si ces conditions ne sont pas satisfaites. Vous devez capturer le `DeletionTaskId` de la réponse afin de vérifier l'état de la tâche de suppression.
1. Pour vérifier l'état de la suppression, appelez [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). Dans la demande, spécifiez le `DeletionTaskId`.
L’état de la tâche de suppression peut être `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` ou `FAILED`. Si la suppression échoue, l’appel renvoie le motif de l’échec, afin que vous puissiez apporter une solution.
# AWS politiques gérées pour MemoryDB
Pour ajouter des autorisations aux utilisateurs, aux groupes et aux rôles, il est plus facile d'utiliser des politiques AWS gérées que de les rédiger vous-même. Il faut du temps et de l’expertise pour [créer des politiques gérées par le client IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) qui ne fournissent à votre équipe que les autorisations dont elle a besoin. Pour démarrer rapidement, vous pouvez utiliser nos politiques AWS gérées. Ces politiques couvrent les cas d'utilisation courants et sont disponibles dans votre AWS compte. Pour plus d'informations sur les politiques AWS gérées, voir les [politiques AWS gérées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *guide de l'utilisateur IAM*.
AWS les services maintiennent et mettent à jour les politiques AWS gérées. Vous ne pouvez pas modifier les autorisations dans les politiques AWS gérées. Les services ajoutent occasionnellement des autorisations à une politique gérée par AWS pour prendre en charge de nouvelles fonctionnalités. Ce type de mise à jour affecte toutes les identités (utilisateurs, groupes et rôles) auxquelles la politique est attachée. Les services sont très susceptibles de mettre à jour une politique gérée par AWS quand une nouvelle fonctionnalité est lancée ou quand de nouvelles opérations sont disponibles. Les services ne suppriment pas les autorisations d'une politique AWS gérée. Les mises à jour des politiques n'endommageront donc pas vos autorisations existantes.
En outre, AWS prend en charge les politiques gérées pour les fonctions professionnelles qui couvrent plusieurs services. Par exemple, la politique **ReadOnlyAccess** AWS gérée fournit un accès en lecture seule à tous les AWS services et ressources. Lorsqu'un service lance une nouvelle fonctionnalité, il AWS ajoute des autorisations en lecture seule pour les nouvelles opérations et ressources. Pour obtenir la liste des politiques de fonctions professionnelles et leurs descriptions, consultez la page [politiques gérées par AWS pour les fonctions de tâche](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
## AWS politique gérée : Mémoire DBService RolePolicy
Vous ne pouvez pas associer la politique de DBService RolePolicy AWS gestion de la mémoire aux identités de votre compte. Cette politique fait partie du rôle lié au service AWS MemoryDB. Ce rôle permet au service de gérer les interfaces réseau et les groupes de sécurité de votre compte.
MemoryDB utilise les autorisations définies dans cette politique pour gérer les groupes de sécurité et les interfaces réseau EC2. Cela est nécessaire pour gérer les clusters MemoryDB.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
## AWS-politiques gérées (prédéfinies) pour MemoryDB
AWS répond à de nombreux cas d'utilisation courants en fournissant des politiques IAM autonomes créées et administrées par. AWS Les politiques gérées octroient les autorisations requises dans les cas d’utilisation courants et vous évitent d’avoir à réfléchir aux autorisations qui sont requises. Pour plus d'informations, consultez [ Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l'utilisateur IAM*.
Les politiques AWS gérées suivantes, que vous pouvez associer aux utilisateurs de votre compte, sont spécifiques à MemoryDB :
### AmazonMemoryDBReadOnlyAccess
Vous pouvez associer la politique `AmazonMemoryDBReadOnlyAccess` à vos identités IAM. Cette politique accorde des autorisations administratives qui permettent un accès en lecture seule à toutes les ressources MemoryDB.
**AmazonMemoryDBReadOnlyAccess**- Accorde un accès en lecture seule aux ressources MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"
],
"Resource": "*"
}]
}
```
------
### AmazonMemoryDBFullAccès
Vous pouvez associer la politique `AmazonMemoryDBFullAccess` à vos identités IAM. Cette politique accorde des autorisations administratives qui permettent un accès complet à toutes les ressources de MemoryDB.
**AmazonMemoryDBFullAccès** : accorde un accès complet aux ressources de MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws-cn:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
Vous pouvez également créer vos propres politiques IAM personnalisées pour autoriser les actions de l'API MemoryDB. Vous pouvez attacher ces politiques personnalisées aux utilisateurs ou groupes IAM qui nécessitent ces autorisations.
## Mises à jour de MemoryDB pour les politiques gérées AWS
Consultez les détails des mises à jour des politiques AWS gérées pour MemoryDB depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la page d'historique des documents de MemoryDB.
| Modifier | Description | Date |
| --- | --- | --- |
| [AWS politique gérée : Mémoire DBService RolePolicy](#security-iam-awsmanpol-memorydbServiceRolePolicy)— Ajout d'une politique | Memory DBService RolePolicy a ajouté l'autorisation pour memorydb :. ReplicateMultiRegionClusterData Cette autorisation permettra au rôle lié au service de répliquer les données pour les clusters multirégionaux MemoryDB. | 01/12/2024 |
| [AmazonMemoryDBFullAccès](#iam.identitybasedpolicies.predefinedpolicies-fullaccess)— Ajout d'une politique | MemoryDB a ajouté de nouvelles autorisations pour décrire et répertorier les ressources prises en charge. Ces autorisations sont requises pour que MemoryDB puisse interroger toutes les ressources prises en charge dans un compte. | 07/10/2021 |
| [AmazonMemoryDBReadOnlyAccess](#iam.identitybasedpolicies.predefinedpolicies-readonly)— Ajout d'une politique | MemoryDB a ajouté de nouvelles autorisations pour décrire et répertorier les ressources prises en charge. Ces autorisations sont requises pour que MemoryDB puisse créer des applications basées sur un compte en interrogeant toutes les ressources prises en charge dans un compte. | 07/10/2021 |
| MemoryDB a commencé à suivre les modifications | Lancement de service | 19/08/2021 |
# Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions
Lorsque vous configurez le [contrôle d'accès](iam.md#iam.accesscontrol) et que vous écrivez des politiques d'autorisation à associer à une stratégie IAM (basée sur l'identité ou sur les ressources), utilisez le tableau suivant comme référence. Le tableau répertorie chaque opération de l'API MemoryDB et les actions correspondantes pour lesquelles vous pouvez accorder des autorisations pour effectuer l'action. Vous spécifiez les actions dans le champ `Action` de la politique ainsi qu’une valeur des ressources dans le champ `Resource` de la politique. Sauf indication contraire, la ressource est requise. Certains champs incluent à la fois une ressource obligatoire et des ressources facultatives. Lorsqu'il n'y a pas d'ARN de ressource, la ressource de la politique est un caractère générique (\$1).
**Note**
Pour indiquer une action, utilisez le préfixe `memorydb:` suivi du nom de l'opération d'API (par exemple, `memorydb:DescribeClusters`).
Utilisez les barres de défilement pour voir le reste du tableau.
**API MemoryDB et autorisations requises pour les actions**
| Opérations de l'API MemoryDB | Autorisations requises (actions API) | Ressources |
| --- | --- | --- |
| [BatchUpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_BatchUpdateCluster.html) | `memorydb:BatchUpdateCluster` | Cluster |
| [CopySnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CopySnapshot.html) | `memorydb:CopySnapshot` `memorydb:TagResource` `s3:GetBucketLocation` `s3:ListAllMyBuckets` | Instantané (source, cible) \$1 \$1 |
| [CreateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateCluster.html) | `memorydb:CreateCluster` `memorydb:TagResource` `s3:GetObject` Si vous utilisez le paramètre `SnapshotArns`, chaque membre de la liste `SnapshotArns` doit avoir sa propre autorisation `s3:GetObject` avec l'ARN `s3` comme ressource. | Groupe de paramètres. (Facultatif) cluster, instantané, identifiants de groupe de sécurité et groupe de sous-réseaux `arn:aws:s3:::my_bucket/snapshot1.rdb` Où*my\$1bucket*/*snapshot1*représente un compartiment S3 et un instantané à partir desquels vous souhaitez créer le cluster. |
| [CreateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateParameterGroup.html) | `memorydb:CreateParameterGroup` `memorydb:TagResource` | Groupe de paramètres |
| [CreateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSubnetGroup.html) | `memorydb:CreateSubnetGroup` `memorydb:TagResource` | Groupe de sous-réseaux | \$1 |
| [CreateSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSnapshot.html) | `memorydb:CreateSnapshot` `memorydb:TagResource` | Instantané, cluster |
| [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) | `memorydb:CreateUser` `memorydb:TagResource` | Utilisateur |
| [Créer un ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateACL.html) | `memorydb:CreateACL` `memorydb:TagResource` | Liste de contrôle d'accès (ACL) |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | Cluster |
| [DeleteCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteCluster.html) | `memorydb:DeleteCluster` | Cluster. (Facultatif) Instantané |
| [DeleteParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteParameterGroup.html) | `memorydb:DeleteParameterGroup` | Groupe de paramètres |
| [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) | `memorydb:DeleteSubnetGroup` | Groupe de sous-réseaux |
| [DeleteSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSnapshot.html) | `memorydb:DeleteSnapshot` | Instantané |
| [DeleteUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteUser.html) | `memorydb:DeleteUser` | Utilisateur |
| [Supprimer l'ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteACL.html) | `memorydb:DeleteACL` | ACL |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeEngineVersions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEngineVersions.html) | `memorydb:DescribeEngineVersions` | Aucun ARN de ressource :\$1 |
| [DescribeParameterGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameterGroups.html) | `memorydb:DescribeParameterGroups` | Groupe de paramètres |
| [DescribeParameters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameters.html) | `memorydb:DescribeParameters` | Groupe de paramètres |
| [DescribeSubnetGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSubnetGroups.html) | `memorydb:DescribeSubnetGroups` | Groupe de sous-réseaux | \$1 |
| [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) | `memorydb:DescribeEvents` | Aucun ARN de ressource :\$1 |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeServiceUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html) | `memorydb:DescribeServiceUpdates` | Aucun ARN de ressource :\$1 |
| [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html) | `memorydb:DescribeSnapshots` | Instantané |
| [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) | `memorydb:DescribeUsers` | Utilisateur |
| [DécrireACLs](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeACLs.html) | `memorydb:DescribeACLs` | ACLs |
| [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) | `memorydb:ListAllowedNodeTypeUpdates` | Cluster |
| [ListTags](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListTags.html) | `memorydb:ListTags` | (Facultatif) cluster, instantané |
| [UpdateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateParameterGroup.html) | `memorydb:UpdateParameterGroup` | Groupe de paramètres |
| [UpdateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateSubnetGroup.html) | `memorydb:UpdateSubnetGroup` | Groupe de sous-réseaux |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | grappe. (Facultatif) Groupe de paramètres, groupe de sécurité |
| [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) | `memorydb:UpdateUser` | Utilisateur |
| [Mettre à jour l'ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateACL.html) | `memorydb:UpdateACL` | ACL |
| [UntagResource](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UntagResource.html) | `memorydb:UntagResource` | (Facultatif) Cluster, instantané |
| [ResetParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ResetParameterGroup.html) | `memorydb:ResetParameterGroup` | Groupe de paramètres |
| [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) | `memorydb:FailoverShard` | grappe, fragment |
# Journalisation et surveillance
La surveillance joue un rôle important dans le maintien de la fiabilité, de la disponibilité et des performances de MemoryDB et de vos autres AWS solutions. AWS fournit les outils de surveillance suivants pour surveiller MemoryDB, signaler un problème et prendre des mesures automatiques le cas échéant :
+ *Amazon CloudWatch* surveille vos AWS ressources et les applications que vous utilisez AWS en temps réel. Vous pouvez collecter et suivre les métriques, créer des tableaux de bord personnalisés, et définir des alarmes qui vous informent ou prennent des mesures lorsqu’une métrique spécifique atteint un seuil que vous spécifiez. Par exemple, vous pouvez CloudWatch suivre l'utilisation du processeur ou d'autres indicateurs de vos EC2 instances Amazon et lancer automatiquement de nouvelles instances en cas de besoin. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon CloudWatch Logs* vous permet de surveiller, de stocker et d'accéder à vos fichiers journaux à partir d' EC2 instances Amazon et d'autres sources. CloudTrail CloudWatch Les journaux peuvent surveiller les informations contenues dans les fichiers journaux et vous avertir lorsque certains seuils sont atteints. Vous pouvez également archiver vos données de journaux dans une solution de stockage hautement durable. Pour plus d'informations, consultez le [guide de l'utilisateur d'Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail*capture les appels d'API et les événements associés effectués par ou pour le compte de votre AWS compte et envoie les fichiers journaux dans un compartiment Amazon S3 que vous spécifiez. Vous pouvez identifier les utilisateurs et les comptes appelés AWS, l'adresse IP source à partir de laquelle les appels ont été effectués et la date des appels. Pour plus d’informations, consultez le [Guide de l’utilisateur AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Surveillance de MemoryDB avec Amazon CloudWatch
Vous pouvez surveiller MemoryDB en utilisant CloudWatch, qui collecte les données brutes et les traite en métriques lisibles en temps quasi réel. Ces statistiques sont enregistrées pour une durée de 15 mois ; par conséquent, vous pouvez accéder aux informations historiques et acquérir un meilleur point de vue de la façon dont votre service ou application web s’exécute. Vous pouvez également définir des alarmes qui surveillent certains seuils et envoient des notifications ou prennent des mesures lorsque ces seuils sont atteints. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
Les sections suivantes répertorient les métriques et les dimensions de MemoryDB.
**Topics**
+ [Métriques au niveau de l'hôte](metrics.HostLevel.md)
+ [Métriques pour MemoryDB](metrics.memorydb.md)
+ [Quelles métriques dois-je surveiller ?](metrics.whichshouldimonitor.md)
+ [Choix des périodes et des statistiques de métriques](metrics.ChoosingStatisticsAndPeriods.md)
+ [CloudWatch Métriques de surveillance](cloudwatchmetrics.md)
# Métriques au niveau de l'hôte
L'espace de `AWS/MemoryDB` noms inclut les métriques suivantes au niveau de l'hôte pour les nœuds individuels.
**Voir aussi**
+ [Métriques pour MemoryDB](metrics.memorydb.md)
| Métrique | Description | Unit |
| --- | --- | --- |
| CPUUtilization | Le pourcentage d'utilisation de l'UC pour l'hôte entier. Valkey et Redis OSS étant à thread unique, nous vous recommandons de surveiller les EngineCPUUtilization métriques pour les nœuds contenant 4 v. ou plus. CPUs | Pourcentage |
| FreeableMemory | Espace mémoire disponible sur l'hôte. Ce nombre est dérivé de la mémoire vive et des tampons que le système d'exploitation considère comme libérables. | Octets |
| NetworkBytesIn | Nombre d'octets lus par l'hôte à partir du réseau. | Octets |
| NetworkBytesOut | Nombre d'octets envoyés par l'instance sur toutes les interfaces réseau. | Octets |
| NetworkPacketsIn | Nombre de paquets reçus par l'instance sur toutes les interfaces réseau. Cette métrique identifie le volume du trafic entrant en ce qui concerne le nombre de paquets sur une seule instance. | Nombre |
| NetworkPacketsOut | Nombre de paquets envoyés par l'instance sur toutes les interfaces réseau. Cette métrique identifie le volume du trafic sortant en ce qui concerne le nombre de paquets sur une seule instance. | Nombre |
| NetworkBandwidthInAllowanceExceeded | Nombre de paquets formés parce que la bande passante agrégée entrante a dépassé le maximum de l'instance. | Nombre |
| NetworkConntrackAllowanceExceeded | Nombre de paquets formés parce que le suivi des connexions a dépassé le maximum de l'instance et que de nouvelles connexions n'ont pas pu être établies. Cela peut entraîner une perte de paquets pour le trafic vers ou en provenance de l’instance. | Nombre |
| NetworkBandwidthOutAllowanceExceeded | Nombre de paquets formés parce que la bande passante agrégée sortante a dépassé le maximum de l'instance. | Nombre |
| NetworkPacketsPerSecondAllowanceExceeded | Nombre de paquets formés parce que le PPS bidirectionnel a dépassé le maximum de l’instance. | Nombre |
| NetworkMaxBytesIn | Nombre maximal d'octets reçus par seconde par minute. | Octets |
| NetworkMaxBytesOut | Nombre maximal d'octets transmis par seconde par minute. | Octets |
| NetworkMaxPacketsIn | Nombre maximal de paquets reçus par seconde par minute. | Nombre |
| NetworkMaxPacketsOut | Nombre maximal de paquets transmis par seconde par minute. | Nombre |
| SwapUsage | Nombre de permutations utilisées sur l'hôte. | Octets |
# Métriques pour MemoryDB
L’espace de noms `AWS/MemoryDB` inclut les métriques suivantes.
À l'exception de`ReplicationLag`,`EngineCPUUtilization`, et `SuccessfulWriteRequestLatency``SuccessfulReadRequestLatency`, ces métriques sont dérivées des commandes Valkey et Redis OSS**info**. Chaque métrique est calculée au niveau du nœud.
Pour une documentation complète de la **INFO** commande, voir [INFO](http://valkey.io/commands/info).
**Voir aussi :**
+ [Métriques au niveau de l'hôte](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/metrics.memorydb.html)
Voici des regroupements de certains types de commandes, dérivés de **info commandstats**. La section commandstats fournit des statistiques basées sur le type de commande, y compris le nombre d'appels.
Pour une liste complète des commandes disponibles, consultez la section [commandes](https://valkey.io/commands).
| Métrique | Description | Unit |
| --- | --- | --- |
| EvalBasedCmds | Nombre total de commandes pour les commandes basées sur eval. Ceci est dérivé de la commandstats statistique en additionnant eval et. evalsha | Nombre |
| GeoSpatialBasedCmds | Nombre total de commandes pour les commandes basées sur la géolocalisation. Ceci est dérivé de la commandstats statistique. Il est dérivé en additionnant tous les types de commandes géo : geoadd, geodist, geohash, geopos, georadius et georadiusbymember. | Nombre |
| GetTypeCmds | Le nombre total de commandes basées sur les types de commandes read-only. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de read-only type (gethget,scard,lrange,, etc.) | Nombre |
| HashBasedCmds | Nombre total de commandes basées sur le hachage. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs hachages (hget,,,hkeys, hvalshdel, etc.). | Nombre |
| HyperLogLogBasedCmds | Nombre total de commandes basées sur HyperLogLog. Ceci est dérivé de la commandstats statistique en additionnant tous les pf types de commandes (pfaddpfcount,pfmerge,, etc.). | Nombre |
| JsonBasedCmds | Nombre total de commandes basées sur JSON. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs objets de document JSON. | Nombre |
| KeyBasedCmds | Nombre total de commandes basées sur une clé. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs touches dans plusieurs structures de données (delexpire,rename,, etc.). | Nombre |
| ListBasedCmds | Nombre total de commandes basées sur une liste. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs listes (lindex,lrange,lpush,ltrim, etc.). | Nombre |
| PubSubBasedCmds | Nombre total de commandes pour les pub/sub fonctionnalités. Ceci est dérivé des commandstats statistiques en additionnant toutes les commandes utilisées pour les pub/sub fonctionnalités :psubscribe,publish,pubsub, punsubscribesubscribe, etunsubscribe. | Nombre |
| SearchBasedCmds | Le nombre total de commandes d'index et de recherche secondaires, y compris les commandes de lecture et d'écriture. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de recherche qui agissent sur les index secondaires. | Nombre |
| SearchBasedGetCmds | Nombre total de commandes d'index et de recherche secondaires en lecture seule. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes d'index secondaire et de recherche. | Nombre |
| SearchBasedSetCmds | Nombre total de commandes d'écriture et d'index secondaires. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de l'index secondaire et du set de recherche. | Nombre |
| SearchNumberOfIndexes | Nombre total d'index. | Nombre |
| SearchNumberOfIndexedKeys | Nombre total de clés indexées | Nombre |
| SearchTotalIndexSize | Mémoire (octets) utilisée par tous les index. | Octets |
| SetBasedCmds | Nombre total de commandes basées sur un ensemble. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs ensembles (scard,sdiff,sadd,sunion, etc.). | Nombre |
| SetTypeCmds | Le nombre total de commandes de type write. Ceci est dérivé de la commandstats statistique en additionnant tous les mutative types de commandes qui opèrent sur les données (sethset,sadd,lpop,, etc.) | Nombre |
| SortedSetBasedCmds | Nombre total de commandes qui sont triées en fonction d'un ensemble. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs ensembles triés (zcount,zrange,zrank,zadd, etc.). | Nombre |
| StringBasedCmds | Nombre total de commandes basées sur une chaîne. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs chaînes (strlen,setex,setrange, etc.). | Nombre |
| StreamBasedCmds | Nombre total de commandes basées sur un flux. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs types de données de flux (xrange,xlen,xadd,xdel, etc.). | Nombre |
# Quelles métriques dois-je surveiller ?
Les CloudWatch mesures suivantes offrent un bon aperçu des performances de MemoryDB. Dans la plupart des cas, nous vous recommandons de définir des CloudWatch alarmes pour ces mesures afin de pouvoir prendre des mesures correctives avant que des problèmes de performances ne surviennent.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [Moteur CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Mémoire](#metrics-memory)
+ [Réseau](#metrics-network)
+ [Latence](#metrics-latency)
+ [Réplication](#metrics-replication)
## CPUUtilization
Il s'agit d'une métrique au niveau de l'hôte représentée en pourcentage. Pour de plus amples informations, veuillez consulter [Métriques au niveau de l'hôte](metrics.HostLevel.md).
Pour les types de nœuds plus petits avec 2 V CPUs ou moins, utilisez la `CPUUtilization ` métrique pour surveiller votre charge de travail.
En général, nous vous suggérons de définir votre seuil à 90 % de votre UC disponible. Valkey et Redis OSS étant monothread, la valeur de seuil réelle doit être calculée en tant que fraction de la capacité totale du nœud. Supposons par exemple que vous utilisiez un type de nœud comportant deux cœurs. Dans ce cas, le seuil CPUUtilization serait de 90/2, soit 45 %. Pour connaître le nombre de cœurs (vCPUs) de votre type de nœud, consultez la section Tarification de [MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps).
Vous devrez déterminer votre propre seuil, en fonction du nombre de cœurs du nœud que vous utilisez. Si vous dépassez ce seuil et que votre charge de travail principale provient des demandes de lecture, agrandissez votre cluster en ajoutant des répliques de lecture. Si la charge de travail principale provient de demandes d'écriture, nous vous recommandons d'ajouter des partitions supplémentaires afin de répartir la charge de travail d'écriture sur un plus grand nombre de nœuds principaux.
**Astuce**
Au lieu d'utiliser la métrique Host-Level`CPUUtilization`, vous pouvez peut-être utiliser la métrique`EngineCPUUtilization`, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
Pour les types de nœuds plus grands avec 4 V CPUs ou plus, vous pouvez utiliser la `EngineCPUUtilization` métrique, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## Moteur CPUUtilization
Pour les types de nœuds plus grands avec 4 V CPUs ou plus, vous pouvez utiliser la `EngineCPUUtilization` métrique, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
Il s'agit d'une métrique au niveau de l'hôte, publiée en octets. Pour de plus amples informations, veuillez consulter [Métriques au niveau de l'hôte](metrics.HostLevel.md).
Si la `FreeableMemory` CloudWatch métrique est proche de 0 (c'est-à-dire inférieure à 100 Mo) ou si elle est supérieure à la `SwapUsage` `FreeableMemory` métrique, il se peut qu'un nœud soit soumis à une pression de mémoire.
## Evictions
Il s'agit d'une métrique du moteur. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application.
## CurrConnections
Il s'agit d'une métrique du moteur. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application.
Un nombre croissant de *CurrConnections*chiffres peut indiquer un problème avec votre application ; vous devrez étudier le comportement de l'application pour résoudre ce problème.
## Mémoire
La mémoire est au cœur de Valkey et de Redis OSS. Il est nécessaire de comprendre l'utilisation de la mémoire de votre cluster afin d'éviter la perte de données et de tenir compte de la croissance future de votre jeu de données. Les statistiques relatives à l'utilisation de la mémoire d'un nœud sont disponibles dans la section mémoire de la commande [INFO](https://valkey.io/commands/info).
## Réseau
L'un des facteurs déterminants de la capacité de bande passante réseau de votre cluster est le type de nœud que vous avez sélectionné. Pour plus d'informations sur la capacité réseau de votre nœud, consultez la tarification d'[Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).
## Latence
Les métriques `SuccessfulWriteRequestLatency` de latence `SuccessfulReadRequestLatency` mesurent le temps total nécessaire à MemoryDB pour le moteur Valkey pour répondre à une demande.
**Note**
Des valeurs `SuccessfulWriteRequestLatency` et des `SuccessfulReadRequestLatency` métriques gonflées peuvent survenir lors de l'utilisation du pipeline Valkey avec CLIENT REPLY activé sur le client Valkey. Le pipeline Valkey est une technique permettant d'améliorer les performances en émettant plusieurs commandes à la fois, sans attendre la réponse à chaque commande individuelle. Pour éviter les valeurs exagérées, nous vous recommandons de configurer votre client Redis pour qu'il achemine les commandes avec [CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/)
## Réplication
Le volume de données en cours de réplication est visible via le métrique `ReplicationBytes`. Vous pouvez effectuer une surveillance `MaxReplicationThroughput` par rapport au débit de la capacité de réplication. Il est recommandé d'ajouter des partitions supplémentaires lorsque le débit de capacité de réplication maximal est atteint.
`ReplicationDelayedWriteCommands`peut également indiquer si la charge de travail dépasse le débit maximal de capacité de réplication. Pour plus d'informations sur la réplication dans MemoryDB, voir [Comprendre](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html) la réplication MemoryDB
# Choix des périodes et des statistiques de métriques
Bien que CloudWatch vous puissiez choisir n'importe quelle statistique et période pour chaque métrique, toutes les combinaisons ne seront pas utiles. Par exemple, les statistiques moyenne, minimale et maximale pour CPUUtilization sont utiles, mais pas la statistique Sum.
Tous les exemples de MemoryDB sont publiés pour une durée de 60 secondes pour chaque nœud individuel. Pour toute période de 60 secondes, une métrique de nœud ne contiendra qu'un seul échantillon.
# CloudWatch Métriques de surveillance
MemoryDB et CloudWatch sont intégrés afin que vous puissiez collecter une variété de métriques. Vous pouvez surveiller ces indicateurs à l'aide de CloudWatch.
**Note**
Les exemples suivants nécessitent les outils de ligne de CloudWatch commande. Pour plus d'informations sur CloudWatch les outils de développement et pour les télécharger, consultez la [page CloudWatch du produit](https://aws.amazon.com/cloudwatch).
Les procédures suivantes vous montrent comment collecter des statistiques CloudWatch d'espace de stockage pour un cluster au cours de la dernière heure.
**Note**
Les `EndTime` valeurs `StartTime` et fournies dans les exemples suivants sont fournies à titre indicatif. Assurez-vous de remplacer les valeurs d'heure de début et de fin appropriées pour vos nœuds.
Pour plus d'informations sur les limites de MemoryDB, voir Limites de [AWS service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) pour MemoryDB.
## CloudWatch Métriques de surveillance (console)
**Pour recueillir des statistiques d'utilisation du processeur pour un cluster**
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. Sélectionnez les nœuds pour lesquels vous souhaitez consulter les métriques.
**Note**
L'affichage des métriques sur la console est désactivé si vous sélectionnez plus de 20 nœuds.
1. Sur la page **Clusters** de la console de AWS gestion, cliquez sur le nom d'un ou de plusieurs clusters.
La page détaillée du cluster s'affiche.
1. Cliquez sur l'onglet **Nodes** en haut de la fenêtre.
1. Dans l'onglet **Nœuds** de la fenêtre détaillée, sélectionnez les nœuds pour lesquels vous souhaitez consulter les métriques.
La liste des CloudWatch métriques disponibles apparaît en bas de la fenêtre de console.
1. Cliquez sur la métrique **CPU Utilization**.
La CloudWatch console s'ouvre et affiche les statistiques que vous avez sélectionnées. Vous pouvez utiliser les zones de liste déroulantes **Statistic** et **Period** et l'onglet **Time Range** pour modifier les métriques affichées.
## Surveillance des CloudWatch métriques à l'aide de la CloudWatch CLI
**Pour recueillir des statistiques d'utilisation du processeur pour un cluster**
+ Utilisez la CloudWatch commande **aws cloudwatch get-metric-statistics** avec les paramètres suivants (notez que les heures de début et de fin ne sont indiquées qu'à titre d'exemple ; vous devrez les remplacer par vos propres heures de début et de fin appropriées) :
Pour Linux, macOS ou Unix :
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
Pour Windows :
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## Surveillance des CloudWatch métriques à l'aide de l' CloudWatch API
**Pour recueillir des statistiques d'utilisation du processeur pour un cluster**
+ Appelez l' CloudWatch API `GetMetricStatistics` avec les paramètres suivants (notez que les heures de début et de fin ne sont indiquées qu'à titre d'exemple ; vous devrez les remplacer par vos propres heures de début et de fin appropriées) :
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```
# Surveillance des événements MemoryDB
Lorsque des événements importants se produisent pour un cluster, MemoryDB envoie une notification à une rubrique Amazon SNS spécifique. Les exemples incluent des éléments tels que l'échec d'ajout d'un nœud, l'ajout réussi d'un nœud, la modification d'un groupe de sécurité, etc. En surveillant les événements principaux, vous pouvez connaître l'état actuel de vos clusters, et, selon l'événement, prendre des actions correctives.
**Topics**
+ [Gestion des notifications Amazon SNS de MemoryDB](mdbevents.sns.md)
+ [Affichage des événements MemoryDB](mdbevents.viewing.md)
+ [Notifications d'événements Amazon SNS](memorydbsns.md)
# Gestion des notifications Amazon SNS de MemoryDB
Vous pouvez configurer MemoryDB pour envoyer des notifications pour les événements importants du cluster à l'aide d'Amazon Simple Notification Service (Amazon SNS). Dans ces exemples, vous allez configurer un cluster avec l'Amazon Resource Name (ARN) d'une rubrique Amazon SNS pour recevoir des notifications.
**Note**
Cette rubrique suppose que vous êtes inscrit à Amazon SNS, que vous avez souscrit à une rubrique Amazon SNS et que vous l'avez configurée. Pour plus d'informations sur Amazon SNS, veuillez consulter le [Guide du développeur d'Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
## Ajout d'une rubrique Amazon SNS
Les sections suivantes expliquent comment ajouter une rubrique Amazon SNS à l'aide de la AWS console, de l'API MemoryDB ou de l' AWS CLI API MemoryDB.
### Ajout d'une rubrique Amazon SNS (console)
La procédure suivante vous indique comment ajouter une rubrique Amazon SNS pour un cluster.
**Note**
Ce processus permet également de modifier la rubrique Amazon SNS.
**Pour ajouter ou modifier une rubrique Amazon SNS pour un cluster (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 **Clusters**, choisissez le cluster pour lequel vous souhaitez ajouter ou modifier un ARN de rubrique Amazon SNS.
1. Sélectionnez **Modifier**.
1. Dans **Modify Cluster (Modifier le cluster)** sous **Topic for SNS Notification (Rubrique pour notification SNS)**, choisissez la rubrique SNS que vous voulez ajouter ou choisissez **Manual ARN input (Saisie d'ARN manuelle)** et tapez l'ARN de la rubrique Amazon SNS.
1. Sélectionnez **Modifier**.
### Ajout d'une rubrique Amazon SNS (CLI)AWS
Pour ajouter ou modifier une rubrique Amazon SNS pour un cluster, utilisez la AWS CLI commande. `update-cluster`
L'exemple de code suivant ajoute un ARN de rubrique Amazon SNS à *my-cluster*.
Pour Linux, macOS ou Unix :
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Pour Windows :
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Pour plus d’informations, consultez [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
### Ajout d'une rubrique Amazon SNS (API MemoryDB)
Pour ajouter ou mettre à jour une rubrique Amazon SNS pour un cluster, lancez l'`UpdateCluster`action avec les paramètres suivants :
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
Pour ajouter ou mettre à jour une rubrique Amazon SNS pour un cluster, lancez l'`UpdateCluster`action.
Pour de plus amples informations, veuillez consulter [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Activation et désactivation des notifications Amazon SNS
Vous pouvez activer ou désactiver les notifications pour un cluster. Les procédures suivantes vous expliquent comment désactiver les notifications Amazon SNS.
### Activation et désactivation des notifications Amazon SNS (console)
**Pour désactiver les notifications Amazon SNS à l'aide du AWS Management 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. Cliquez sur le bouton radio situé à gauche du cluster pour lequel vous souhaitez modifier la notification.
1. Sélectionnez **Modifier**.
1. Dans **Modifier le cluster** sous **Rubrique pour notification SNS**, choisissez *Désactiver les notifications*.
1. Sélectionnez **Modifier**.
### Activation et désactivation des notifications Amazon SNS (CLI)AWS
Pour désactiver les notifications Amazon SNS, utilisez la commande `update-cluster` avec les paramètres suivants :
Pour Linux, macOS ou Unix :
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
Pour Windows :
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Activation et désactivation des notifications Amazon SNS (API MemoryDB)
Pour désactiver les notifications Amazon SNS, appelez l'action `UpdateCluster` avec les paramètres suivants :
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
Cet appel vous renvoie des informations semblables à ce qui suit :
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# Affichage des événements MemoryDB
MemoryDB enregistre les événements liés à vos clusters, groupes de sécurité et groupes de paramètres. Ces informations comprennent la date et l'heure de l'événement, le nom et le type de la source de l'événement, ainsi qu'une description de cet événement. Vous pouvez facilement récupérer les événements du journal à l'aide de la console MemoryDB, de la AWS CLI `describe-events` commande ou de l'action de l'API MemoryDB. `DescribeEvents`
Les procédures suivantes vous montrent comment afficher tous les événements MemoryDB des dernières 24 heures (1440 minutes).
## Affichage des événements MemoryDB (console)
La procédure suivante affiche les événements à l'aide de la console MemoryDB.
**Pour afficher les événements à l'aide de la console MemoryDB**
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, sélectionnez **Events**.
L'écran *Événements* affiche la liste de tous les événements disponibles. Chaque ligne de la liste représente un événement et affiche la source de l'événement, le type d'événement (tel que cluster, groupe de paramètres, acl, groupe de sécurité ou groupe de sous-réseaux), l'heure GMT de l'événement et la description de l'événement.
A l'aide du **Filtre**, vous pouvez choisir d'afficher tous les événements ou uniquement ceux d'un type spécifique dans la liste des événements.
## Affichage des événements MemoryDB (CLI)AWS
Pour générer une liste d'événements MemoryDB à l'aide de AWS CLI, utilisez la commande. `describe-events` Vous pouvez utiliser des paramètres facultatifs pour contrôler le type et la période des événements répertoriés, le nombre maximal d'événements à répertorier, etc.
Le code suivant répertorie jusqu'à 40 événements de cluster.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
Le code suivant répertorie tous les événements qui ont eu lieu au cours des dernières 24 heures (1 440 minutes).
```
aws memorydb describe-events --duration 1440
```
La sortie de la commande `describe-events` ressemble à ceci.
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
Pour plus d'informations, notamment sur les paramètres disponibles et les valeurs de paramètre autorisées, consultez [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## Affichage des événements MemoryDB (API MemoryDB)
Pour générer une liste d'événements MemoryDB à l'aide de l'API MemoryDB, utilisez l'action. `DescribeEvents` Vous pouvez utiliser des paramètres facultatifs pour contrôler le type et la période des événements répertoriés, le nombre maximal d'événements à répertorier, etc.
Le code suivant répertorie les 40 événements -cluster les plus récents.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
Le code suivant répertorie les événements du cluster survenus au cours des dernières 24 heures (1 440 minutes).
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
Les actions ci-dessus doivent produire un résultat similaire à ce qui suit :
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
Pour plus d'informations, notamment sur les paramètres disponibles et les valeurs de paramètre autorisées, consultez [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Notifications d'événements Amazon SNS
MemoryDB peut publier des messages à l'aide d'Amazon Simple Notification Service (SNS) lorsque des événements importants se produisent sur un cluster. Cette fonctionnalité peut être utilisée pour actualiser les listes de serveurs sur les machines clientes connectées aux points de terminaison des nœuds individuels d'un cluster.
**Note**
Pour plus d'informations sur Amazon Simple Notification Service (SNS), y compris des informations sur la tarification et des liens vers la documentation Amazon SNS, veuillez consulter [Page produit Amazon SNS](https://aws.amazon.com/sns).
Les notifications sont publiées sur une *rubrique* Amazon SNS spécifiée. Ci-après les exigences concernant les notifications :
+ Un seul sujet peut être configuré pour les notifications MemoryDB.
+ Le AWS compte propriétaire de la rubrique Amazon SNS doit être le même que celui qui possède le cluster sur lequel les notifications sont activées.
## Evénements MemoryDB
Les événements MemoryDB suivants déclenchent les notifications Amazon SNS :
| Nom de l'événement | Message | Description |
| --- | --- | --- |
| Base de données de mémoire : AddNodeComplete | "Modified number of nodes from %d to %d" | Un nœud a été ajouté au cluster et est prêt à être utilisé. |
| MemoryDB : AddNodeFailed en raison d'un nombre insuffisant d'adresses IP libres | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | Impossible d'ajouter un nœud car il n'y a pas suffisamment d'adresses IP disponibles. |
| Base de données de mémoire : ClusterParametersChanged | "Updated parameter group for the cluster" Dans le cas d'une création, envoyez également `"Updated to use a ParameterGroup %s"` | Un ou plusieurs paramètres de cluster ont été modifiés. |
| Base de données de mémoire : ClusterProvisioningComplete | "Cluster created." | Le provisionnement d'un cluster est terminé et les nœuds du cluster sont prêts à être utilisés. |
| MemoryDB : ClusterProvisioningFailed en raison d'un état réseau incompatible | "Failed to create cluster due to incompatible network state. %s" | Une tentative a été faite pour lancer un nouveau cluster dans un cloud privé virtuel (VPC) inexistant. |
| Base de données de mémoire : ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | MemoryDB n'a pas pu remplir le cluster avec des données de capture instantanée. Cela peut être dû à un fichier instantané inexistant dans Amazon S3 ou à des autorisations incorrectes sur ce fichier. Si vous décrivez le cluster, son statut sera`restore-failed`. Vous devrez supprimer le cluster et recommencer à zéro. Pour de plus amples informations, veuillez consulter [Création d'un nouveau cluster avec un instantané créé en externe](snapshots-seeding-redis.md). |
| Base de données de mémoire : ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Mise à l'échelle pour que le cluster soit terminé avec succès. |
| Base de données de mémoire : ClusterScalingFailed | `"Failed applying modification to node type to %s."` | L'opération de mise à l'échelle sur le cluster a échoué. |
| Base de données de mémoire : NodeReplaceStarted | "Recovering node %s" | MemoryDB a détecté que l'hôte exécutant un nœud est dégradé ou inaccessible et a commencé à remplacer le nœud. L'entrée DNS du nœud remplacé n'est pas modifiée. Dans la plupart des cas, vous n'aurez pas besoin d'actualiser la liste des serveurs pour vos clients lorsque cet événement se produit. Cependant, certaines bibliothèques clientes peuvent cesser d'utiliser le nœud même après que MemoryDB l'ait remplacé ; dans ce cas, l'application doit actualiser la liste des serveurs lorsque cet événement se produit. |
| Base de données de mémoire : NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB a détecté que l'hôte exécutant un nœud est dégradé ou inaccessible et a terminé de remplacer le nœud. L'entrée DNS du nœud remplacé n'est pas modifiée. Dans la plupart des cas, vous n'aurez pas besoin d'actualiser la liste des serveurs pour vos clients lorsque cet événement se produit. Cependant, certaines bibliothèques clientes peuvent cesser d'utiliser le nœud même après que MemoryDB l'ait remplacé ; dans ce cas, l'application doit actualiser la liste des serveurs lorsque cet événement se produit. |
| Base de données de mémoire : CreateClusterComplete | "Cluster created" | Le cluster a été créé avec succès. |
| Base de données de mémoire : CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." et "Deleting all nodes belonging to this cluster." | Le cluster n'a pas été créé. |
| Base de données de mémoire : DeleteClusterComplete | "Cluster deleted." | La suppression d'un cluster et de tous les nœuds associés est terminée. |
| Base de données de mémoire : FailoverComplete | `"Failover to replica node %s completed"` | Basculement vers un nœud du réplica réussi. |
| Base de données de mémoire : NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | Le remplacement d'un nœud de votre cluster qui était prévu a été annulé. |
| Base de données de mémoire : NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | Le remplacement d'un nœud de cluster a été reprogrammé dans le créneau indiqué dans la notification. Pour plus d'informations sur les actions que vous pouvez effectuer, consultez [Remplacement de nœuds](nodes.nodereplacement.md). |
| Base de données de mémoire : NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | Un nœud du cluster doit être remplacé pendant le créneau décrit dans la notification. Pour plus d'informations sur les actions que vous pouvez effectuer, consultez [Remplacement de nœuds](nodes.nodereplacement.md). |
| Base de données de mémoire : RemoveNodeComplete | "Removed node %s" | Un nœud a été supprimé du cluster. |
| Base de données de mémoire : SnapshotComplete | "Snapshot %s succeeded for node %s" | Un instantané s'est terminé avec succès. |
| Base de données de mémoire : SnapshotFailed | "Snapshot %s failed for node %s" | Un instantané a échoué. Consultez les événements du cluster pour une cause plus détaillée. Si vous décrivez l'instantané, consultez [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html), l'état sera `failed`. |
# Journalisation des appels d'API MemoryDB avec AWS CloudTrail
MemoryDB est intégré à AWS CloudTrail un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans MemoryDB. CloudTrail capture tous les appels d'API pour MemoryDB sous forme d'événements, y compris les appels depuis la console MemoryDB et les appels de code vers les opérations de l'API MemoryDB. Si vous créez un suivi, vous pouvez activer la diffusion continue d' CloudTrail événements vers un compartiment Amazon S3, y compris des événements pour MemoryDB. Si vous ne configurez pas de suivi, vous pouvez toujours consulter les événements les plus récents dans la CloudTrail console dans **Historique des événements**. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite à MemoryDB, l'adresse IP à partir de laquelle la demande a été faite, qui a fait la demande, quand elle a été faite et des détails supplémentaires.
Pour en savoir plus CloudTrail, consultez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informations MemoryDB dans CloudTrail
CloudTrail est activé sur votre AWS compte lorsque vous le créez. **Lorsqu'une activité se produit dans MemoryDB, cette activité est enregistrée dans un CloudTrail événement avec d'autres événements de AWS service dans l'historique des événements.** Vous pouvez consulter, rechercher et télécharger les événements récents dans votre AWS compte. Pour plus d'informations, consultez la section [Affichage des événements à l'aide de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Pour un enregistrement continu des événements de votre AWS compte, y compris des événements relatifs à MemoryDB, créez une trace. Un suivi permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Par défaut, lorsque vous créez un journal d’activité dans la console, il s’applique à toutes les régions. Le journal enregistre les événements de toutes les régions de la AWS partition et transmet les fichiers journaux au compartiment Amazon S3 que vous spécifiez. En outre, vous pouvez configurer d'autres AWS services pour analyser plus en détail les données d'événements collectées dans les CloudTrail journaux et agir en conséquence. Pour plus d’informations, consultez les ressources suivantes :
+ [Vue d’ensemble de la création d’un journal d’activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Services et intégrations pris en charge](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuration des notifications Amazon SNS pour CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Réception de fichiers CloudTrail journaux de plusieurs régions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) et [réception de fichiers CloudTrail journaux de plusieurs comptes](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Toutes les actions de MemoryDB sont enregistrées par. CloudTrail Par exemple, les appels au`CreateCluster`, `DescribeClusters` et les `UpdateCluster` actions génèrent des entrées dans les fichiers CloudTrail journaux.
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l’identité permettent de déterminer les éléments suivants :
+ Si la demande a été effectuée avec des informations d’identification d’utilisateur root ou IAM.
+ Si la demande a été effectuée avec des informations d’identification de sécurité temporaires pour un rôle ou un utilisateur fédéré.
+ Si la demande a été faite par un autre AWS service.
Pour plus d’informations, consultez la section [Élément userIdentity CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Comprendre les entrées du fichier journal MemoryDB
Un suivi est une configuration qui permet de transmettre des événements sous forme de fichiers journaux à un compartiment Amazon S3 que vous spécifiez. CloudTrail les fichiers journaux contiennent une ou plusieurs entrées de journal. Un événement représente une demande unique provenant de n'importe quelle source et inclut des informations sur l'action demandée, la date et l'heure de l'action, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics, ils n'apparaissent donc pas dans un ordre spécifique.
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`CreateCluster`action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`DescribeClusters`action. Notez que pour tous les appels MemoryDB Describe et List (`Describe*`et`List*`), la `responseElements` section est supprimée et apparaît sous la forme. `null`
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
L'exemple suivant montre une entrée de CloudTrail journal qui enregistre une `UpdateCluster` action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`CreateUser`action. Notez que pour les appels MemoryDB contenant des données sensibles, ces données seront supprimées lors de l' CloudTrail événement correspondant, comme indiqué dans la `requestParameters` section ci-dessous.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
# Validation de conformité pour MemoryDB
Des auditeurs tiers évaluent la sécurité et la conformité de MemoryDB dans le cadre de plusieurs programmes de AWS conformité. Cela consiste notamment à :
+ Norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS). Pour de plus amples informations, consultez [PCI DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/).
+ Loi sur la transférabilité et l'imputabilité de l'assurance maladie Accord de partenariat (HIPAA BAA). Pour de plus amples informations, consultez [Conformité à la loi HIPAA](https://aws.amazon.com/compliance/hipaa-compliance).
+ Contrôles du système et de l’organisation (SOC) 1, 2 et 3. Pour de plus amples informations, consultez [SOC](https://aws.amazon.com/compliance/soc-faqs).
+ Programme fédéral de gestion des risques et des autorisations (FedRAMP) modéré. Pour plus d’informations, consultez [FedRAMP](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/).
+ ISO/IEC 27001:2013, 27017:2015, 27018:2019 et 9001:2015. ISO/IEC Pour plus d'informations, consultez les [certifications et services AWS ISO et CSA STAR](https://aws.amazon.com/compliance/iso-certified/).
Pour une liste des AWS services concernés par des programmes de conformité spécifiques, voir [AWS Services concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Votre responsabilité en matière de conformité lors de l'utilisation de MemoryDB est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise et les lois et réglementations applicables. AWS fournit les ressources suivantes pour faciliter la mise en conformité :
+ [Guides démarrage rapide de la sécurité et de la conformité](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance). Ces guides de déploiement traitent des considérations architecturales et fournissent des étapes pour déployer des environnements de base axés sur la sécurité et la conformité sur AWS.
+ AWS Ressources de [https://aws.amazon.com/compliance/resources/](https://aws.amazon.com/compliance/resources/) de conformité — Cette collection de classeurs et de guides peut s'appliquer à votre secteur d'activité et à votre région.
+ [Évaluation des ressources à l’aide de règles](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) dans le *Guide du développeur AWS Config * : AWS Config évalue dans quelle mesure vos configurations de ressources sont conformes aux pratiques internes, aux directives sectorielles et aux réglementations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Ce AWS service fournit une vue complète de l'état de votre sécurité interne, AWS ce qui vous permet de vérifier votre conformité aux normes et aux meilleures pratiques du secteur de la sécurité.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) : ce AWS service vous aide à auditer en permanence votre AWS utilisation afin de simplifier la gestion des risques et la conformité aux réglementations et aux normes du secteur.
# Sécurité de l'infrastructure dans MemoryDB
En tant que service géré, MemoryDB est protégé par les procédures de sécurité du réseau AWS mondial décrites dans le livre blanc [Amazon Web Services : présentation des processus de sécurité](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Vous utilisez des appels d'API AWS publiés pour accéder à MemoryDB via le réseau. Les clients doivent prendre en charge le protocole TLS (Transport Layer Security) 1.2 ou version ultérieure. Nous recommandons TLS 1.3 ou version ultérieure. Les clients doivent aussi prendre en charge les suites de chiffrement PFS (Perfect Forward Secrecy) comme Ephemeral Diffie-Hellman (DHE) ou Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, les demandes doivent être signées à l'aide d'un ID de clé d'accès et d'une clé d'accès secrète associée à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.
# 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) |
# Mises à jour du service dans MemoryDB
MemoryDB surveille automatiquement votre parc de clusters et de nœuds pour appliquer les mises à jour de service dès qu'elles sont disponibles. Généralement, vous configurez une fenêtre de maintenance prédéfinie afin que MemoryDB puisse appliquer ces mises à jour. Cependant, dans certains cas, vous pouvez trouver cette approche trop rigide et susceptible de limiter vos flux commerciaux.
Avec[Mises à jour du service dans MemoryDB](#service-updates), vous pouvez contrôler quand et quelles mises à jour sont appliquées. Vous pouvez également suivre en temps réel la progression de ces mises à jour sur le cluster MemoryDB sélectionné.
# Gestion des mises à jour du service
Les mises à jour du service MemoryDB sont publiées régulièrement. Si vous disposez d'un ou de plusieurs clusters éligibles pour ces mises à jour de service, vous recevez des notifications par e-mail, via les réseaux sociaux, le Personal Health Dashboard (PHD) et les CloudWatch événements Amazon lorsque les mises à jour sont publiées. Les mises à jour sont également affichées sur la page **Service Updates** de la console MemoryDB. En utilisant ce tableau de bord, vous pouvez consulter toutes les mises à jour du service et leur statut pour votre parc MemoryDB.
Vous contrôlez le moment où vous devez appliquer une mise à jour avant qu'une mise à jour automatique ne démarre. Nous vous recommandons vivement d'appliquer les mises à jour de type **security-update** dès que possible afin de vous assurer que les correctifs de sécurité actuels sont toujours up-to-date présents dans votre base de données MemoryDB.
Les sections suivantes décrivent ces options en détail :
**Topics**
+ [Présentation de la maintenance gérée et des mises à jour de service Amazon MemoryDB](#managing-updates-maintenance)
## Présentation de la maintenance gérée et des mises à jour de service Amazon MemoryDB
Nous mettons fréquemment à niveau notre parc MemoryDB, les correctifs et les mises à niveau étant appliqués aux instances de manière fluide. Pour ce faire, nous utilisons l'une des deux méthodes suivantes :
1. Maintenance gérée en continu.
1. Mises à jour du service.
Ces mises à jour de maintenance et de service sont nécessaires pour appliquer des mises à niveau qui renforcent la sécurité, la fiabilité et les performances opérationnelles.
La maintenance gérée continue a lieu de temps à autre et directement dans vos fenêtres de maintenance sans que vous n'ayez à intervenir. Il est important de noter que les fenêtres de maintenance sont obligatoires pour tous les clients et que vous n'avez pas la possibilité de vous désinscrire. Nous recommandons vivement d'éviter toute activité critique ou importante pendant ces périodes de maintenance établies. Sachez également que les mises à jour critiques ne peuvent pas être ignorées afin de garantir la sécurité et les performances optimales du système.
Les mises à jour de service vous permettent de les appliquer vous-même. Ils sont chronométrés et peuvent être placés dans la fenêtre de maintenance pour être appliqués par nos soins après l'expiration de leur date d'échéance.
Vous pouvez gérer les mises à jour en les appliquant dès que possible ou en remplaçant les nœuds, car les mises à jour sont automatiquement appliquées lors du remplacement. Il n'y aura aucune activité de mise à jour pendant les fenêtres de maintenance entrantes si les mises à jour ont été appliquées à tous les nœuds précédents.
### Mises à jour de service
[Mises à jour du service dans MemoryDB](service-updates.md)vous permettre d'appliquer certaines mises à jour du service à votre discrétion. Ces mises à jour peuvent être des types suivants : correctifs de sécurité ou mises à jour logicielles mineures. Ces mises à jour permettent de renforcer la sécurité, la fiabilité et les performances opérationnelles de vos clusters.
L'avantage de ces mises à jour de service réside dans le fait que vous pouvez contrôler à quel moment appliquer la mise à jour (par exemple, vous pouvez retarder l'application des mises à jour de service en cas d'événement commercial important nécessitant la disponibilité 24 heures sur 24, 7 jours sur 7 des clusters MemoryDB).
Si vous disposez d'un ou de plusieurs clusters éligibles pour ces mises à jour de service, vous recevez des notifications par e-mail, via [Amazon SNS](mdbevents.sns.md), le [AWS Health tableau de bord](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) et les [ CloudWatch événements Amazon Events](monitoring-cloudwatch.md) lorsque les mises à jour sont publiées. Les mises à jour sont également affichées sur la page **Service Updates** de la console MemoryDB. En utilisant ce tableau de bord, vous pouvez consulter toutes les mises à jour du service et leur statut pour votre parc MemoryDB.
Vous contrôlez le moment où vous devez appliquer une mise à jour avant qu'une mise à jour automatique ne démarre. Nous vous recommandons vivement d'appliquer les mises à jour de type security-update dès que possible afin de vous assurer que les correctifs de sécurité actuels sont toujours up-to-date présents dans votre base de données MemoryDB.
Votre cluster fait peut-être partie de différentes mises à jour de service. La plupart des mises à jour ne nécessitent pas que vous les appliquiez séparément. L'application d'une mise à jour à votre cluster marquera les autres mises à jour comme terminées, le cas échéant. Vous devrez peut-être appliquer plusieurs mises à jour au même cluster séparément si le statut ne passe pas automatiquement à « terminé ».
#### Impact des mises à jour du service et temps d'arrêt
Lorsque vous ou Amazon MemoryDB appliquez une mise à jour de service à un ou plusieurs clusters MemoryDB, la mise à jour est appliquée à un seul nœud à la fois dans chaque partition jusqu'à ce que tous les clusters sélectionnés soient mis à jour. Les nœuds en cours de mise à jour connaîtront un temps d'arrêt de quelques secondes, tandis que le reste du cluster continuera à servir le trafic.
+ Il n'y aura aucun changement dans la configuration du cluster.
+ Vous constaterez un retard dans vos CloudWatch statistiques, qui vous permettront de rattraper votre retard dès que possible.
**Quel est l'impact du remplacement d'un nœud sur mon application ?** - Pour les nœuds MemoryDB, le processus de remplacement est conçu pour garantir la durabilité et la disponibilité. Pour les clusters MemoryDB à nœud unique, MemoryDB lance dynamiquement une réplique, restaure les données de nos composants de durabilité, puis bascule vers celle-ci. Pour les groupes de réplication composés de plusieurs nœuds, MemoryDB remplace les répliques existantes et synchronise les données de nos composants de durabilité avec les nouvelles répliques. MemoryDB n'est multi-AZ que lorsqu'il y a plus d'un nœud. Dans ce scénario, le remplacement du nœud principal déclenche un basculement vers une réplique en lecture. Les remplacements de nœuds prévus sont terminés pendant que le cluster traite les demandes d'écriture entrantes. S'il n'y a qu'un seul nœud, MemoryDB remplace le nœud principal puis synchronise les données de nos composants de durabilité. Le nœud principal n'est pas disponible pendant cette période, ce qui entraîne une interruption d'écriture plus longue.
**Quelles sont les meilleures pratiques à suivre pour une expérience de remplacement fluide et pour minimiser les pertes de données ?** - Dans MemoryDB, les données sont très durables et aucune perte de données n'est attendue, même dans les implémentations à nœud unique. Il est toutefois recommandé de mettre en œuvre des stratégies multi-AZ et de sauvegarde afin de minimiser les risques de perte dans le cas peu probable d'une panne. Pour une expérience de remplacement fluide, nous essayons de remplacer juste assez de nœuds d'un même cluster à la fois pour maintenir la stabilité du cluster. Vous pouvez provisionner des répliques principales et des répliques en lecture dans différentes zones de disponibilité en activant le mode multi-AZ. Dans ce cas, lorsqu'un nœud est remplacé, le rôle principal bascule vers une réplique dans le shard. Cette partition servira désormais au trafic, et les données seront restaurées à partir de ses composants durables. Si votre configuration ne comprend qu'une seule réplique principale et une seule réplique par partition, nous vous recommandons d'ajouter des répliques supplémentaires avant l'application des correctifs. Cela permettra d'éviter une réduction de la disponibilité pendant le processus d'application des correctifs. Nous recommandons de planifier le remplacement pendant une période où le trafic d'écriture entrant est faible.
**Quelles meilleures pratiques de configuration client dois-je suivre pour minimiser les interruptions des applications pendant la maintenance ?** - Dans MemoryDB, la configuration du mode cluster est toujours activée, ce qui garantit la meilleure disponibilité lors d'opérations gérées ou non gérées. Les points de terminaison individuels des nœuds répliqués peuvent être utilisés pour toutes les opérations de lecture. Dans MemoryDB, le basculement automatique est toujours activé dans le cluster, ce qui signifie que le nœud principal peut changer. Par conséquent, l'application doit confirmer le rôle du nœud et mettre à jour tous les points de terminaison de lecture pour s'assurer que vous n'entraînez pas de charge importante sur le nœud principal. De même, évitez de surcharger les répliques avec des demandes de lecture pendant les fenêtres de maintenance. L'un des moyens d'y parvenir est de vous assurer que vous disposez d'au moins deux répliques de lecture afin d'éviter toute interruption de lecture pendant la maintenance.
Il est important de tester les applications clientes pour confirmer qu'elles sont conformes au protocole Redis/Valkey Cluster, et les demandes peuvent être correctement redirigées entre les nœuds. Il est conseillé de mettre en œuvre des stratégies de sauvegarde et de réessai pour éviter de surcharger les nœuds MemoryDB lors des activités de maintenance et de remplacement.
**Replanification : vous pouvez différer la** [mise à jour du service en modifiant la fenêtre de maintenance.](maintenance-window.md) La mise à jour planifiée ne sera appliquée au cluster que si la date planifiée correspond à la fenêtre de maintenance du cluster. Une fois que vous avez modifié la fenêtre de maintenance et que la date planifiée est dépassée, la mise à jour du service sera reprogrammée à la nouvelle fenêtre spécifiée dans les semaines suivantes. Vous recevrez une nouvelle notification une semaine avant que la nouvelle date ne soit atteinte.
La sécurité chez AWS est une responsabilité partagée. Nous vous recommandons vivement d'appliquer la mise à jour au plus tôt.
**Refus de recevoir les mises à jour de service** : vous pouvez déterminer si vous pouvez vous désinscrire d'une mise à jour de service en vérifiant la valeur de l'attribut « Date de début de mise à jour automatique ». Si la valeur de l'attribut « Date de début de mise à jour automatique » d'une mise à jour de service est définie, MemoryDB planifiera la mise à jour du service sur tous les clusters restants pour la prochaine fenêtre de maintenance, et il n'est pas possible de se désinscrire. Néanmoins, si vous appliquez la mise à jour du service aux clusters restants avant la fenêtre de maintenance, MemoryDB ne réappliquera pas la mise à jour du service pendant la fenêtre de maintenance. Pour de plus amples informations, veuillez consulter [Application des mises à jour de service](applying-updates.md).
**Pourquoi les mises à jour du service ne peuvent-elles pas être appliquées directement par MemoryDB pendant les fenêtres de maintenance ?** - Veuillez noter que le but des mises à jour de service est de vous donner une certaine flexibilité quant au moment de les appliquer. Les clusters qui ne participent pas aux programmes de [conformité](memorydb-compliance.md) pris en charge par MemoryDB peuvent choisir de ne pas appliquer ces mises à jour ou de les appliquer à une fréquence réduite tout au long de l'année. Il est toutefois recommandé d'appliquer les mises à jour pour rester en conformité avec les réglementations. Cela n'est vrai que lorsque la valeur de l'attribut « Date de début de mise à jour automatique » d'une mise à jour de service n'est pas présente. Pour de plus amples informations, veuillez consulter [Validation de conformité pour MemoryDB](memorydb-compliance.md).
**En quoi les mises à jour appliquées dans la fenêtre de maintenance sont-elles différentes des mises à jour de service ?** - Les mises à jour appliquées via une maintenance gérée continue sont directement planifiées dans vos fenêtres de maintenance sans qu'aucune action de votre part ne soit nécessaire. Les mises à jour du service sont chronométrées et vous permettent de choisir le moment où vous souhaitez présenter votre demande avant la « date de début de mise à jour automatique ». Si elles ne sont toujours pas appliquées d'ici là, MemoryDB peut planifier ces mises à jour dans votre fenêtre de maintenance.
### Mises à jour de maintenance gérées en continu
Ces mises à jour sont obligatoires et appliquées directement dans vos fenêtres de maintenance sans qu'aucune action de votre part ne soit nécessaire. Ces mises à jour sont distinctes de celles proposées par les mises à jour de service.
#### Impact continu de la maintenance et temps d'arrêt
**Combien de temps prend le remplacement d'un nœud ?** - Un remplacement est généralement effectué dans les 30 minutes. Le remplacement peut prendre plus de temps dans certaines configurations et modèles de trafic.
**Quel est l'impact du remplacement d'un nœud sur mon application ?** - Les mises à jour de maintenance gérées en continu sont appliquées de la même manière que les « mises à jour de service », par le biais du remplacement des nœuds. Reportez-vous à la section sur l'impact des mises à jour du service et les interruptions de service ci-dessus pour plus de détails.
**Comment gérer moi-même les remplacements de nœuds ?** - Vous avez la possibilité de gérer vous-même ces remplacements à tout moment avant la période de remplacement des nœuds planifiée. Si vous choisissez de gérer vous-même le remplacement, vous pouvez effectuer différentes actions en fonction de votre cas d'utilisation.
+ [Remplacer un nœud du cluster par une ou plusieurs partitions](nodes.nodereplacement.md) [: vous pouvez utiliser la [sauvegarde et la restauration](snapshots-restoring.md) ou le scale-out suivi d'un scale-in pour remplacer les nœuds.](cluster-resharding-online.md)
+ [Modifier votre fenêtre de maintenance](maintenance-window.md) : vous pouvez également modifier la fenêtre de maintenance de votre cluster. Pour modifier votre fenêtre de maintenance à un moment plus pratique plus tard, vous pouvez utiliser l'[UpdateCluster API](clusters.modify.md), la [CLI update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) ou cliquer sur [Modifier](clusters.modify.md) dans la console de gestion MemoryDB. Une fois que vous aurez modifié votre fenêtre de maintenance, MemoryDB planifiera la maintenance de votre nœud pendant la nouvelle fenêtre spécifiée.
Pour voir comment cela fonctionne dans la pratique, supposons que nous sommes actuellement le jeudi 11 septembre à 15 heures et que le prochain créneau de maintenance soit le vendredi 11 octobre à 17 heures. Voici 3 scénarios :
+ Vous modifiez votre fenêtre de maintenance au vendredi à 16 h (après la date et heure actuelles et avant la prochaine fenêtre de maintenance planifiée). Le nœud sera remplacé le vendredi 10 novembre à 16 h 00.
+ Vous modifiez votre fenêtre de maintenance au samedi à 16 h (après la date et l'heure actuelles et après la prochaine fenêtre de maintenance planifiée). Le nœud sera remplacé le samedi 11 novembre à 16 h 00.
+ Vous modifiez votre fenêtre de maintenance au mercredi à 16 h (plus tôt dans la semaine que la date et l'heure actuelles). Le nœud sera remplacé le mercredi suivant, le 15 novembre à 16 h 00.
Pour de plus amples informations, veuillez consulter [Gestion de la maintenance](maintenance-window.md).
Notez que les nœuds de différents clusters provenant de différentes régions peuvent être remplacés en même temps, à condition que votre fenêtre de maintenance pour ces clusters soit configurée de manière à être la même.
**Comment puis-je me renseigner sur les prochains remplacements prévus ?** - Vous devriez recevoir une notification de santé sur le tableau de bord de AWS santé. Vous pouvez également trouver l'état des différentes mises à niveau des services avec DescribeServiceUpdates l'API. Veuillez noter que nous mettons tout en œuvre pour informer les clients de manière proactive des remplacements prévisibles. Cependant, dans des cas exceptionnels tels que des pannes imprévisibles, il peut y avoir des remplacements inopinés.
**Puis-je modifier la maintenance planifiée à un moment plus opportun ?** - Oui, vous pouvez reporter la maintenance planifiée à un moment plus approprié en modifiant la [fenêtre de maintenance](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html).
**Pourquoi effectuez-vous ces remplacements de nœuds ?** - Ces remplacements sont nécessaires pour appliquer les mises à jour logicielles obligatoires à votre hôte sous-jacent. Les mises à jour contribuent à renforcer notre sécurité, notre fiabilité et nos performances opérationnelles.
**Ces remplacements affectent-ils mes nœuds situés dans plusieurs zones de disponibilité et mes clusters provenant de différentes régions en même temps ?** - Les remplacements peuvent être exécutés dans plusieurs zones de disponibilité ou régions en parallèle, en fonction de la période de maintenance des clusters.
# Application des mises à jour de service
Vous pouvez commencer à appliquer les mises à jour de service à votre flotte à partir du moment où les mises à jour ont un statut **available** (disponible). Les mises à jour de service sont cumulatives. En d'autres termes, toutes les mises à jour que vous n'avez pas encore appliquées sont incluses dans votre dernière mise à jour.
Si la mise à jour automatique est activée pour une mise à jour de service, vous pouvez choisir de ne prendre aucune mesure lorsqu'elle devient disponible. **MemoryDB planifiera d'appliquer la mise à jour pendant la fenêtre de maintenance de vos clusters après la date de début de la mise à jour automatique.** Vous recevrez des notifications associées pour chaque étape de la mise à jour.
**Note**
Vous pouvez appliquer uniquement les mises à jour de service qui ont un statut **available** (disponible) ou **scheduled** (planifié).
Pour plus d'informations sur la révision et l'application de mises à jour spécifiques à un service aux clusters MemoryDB applicables, consultez. [Application des mises à jour du service à l'aide de la console](#applying-updates-console-APIReferenceconsole)
Lorsqu'une nouvelle mise à jour de service est disponible pour un ou plusieurs de vos clusters MemoryDB, vous pouvez utiliser la console MemoryDB, l'API ou AWS CLI pour appliquer la mise à jour. Les sections suivantes décrivent les options dont vous disposez pour appliquer les mises à jour.
## Application des mises à jour du service à l'aide de la console
Pour afficher la liste des mises à jour de service disponibles, ainsi que d'autres informations, accédez à la page **Service Updates** (Mises à jour de service) dans la 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 panneau de navigation, choisissez **Service Updates** (Mises à jour des services).
Sous **Détails de la mise à jour du service**, vous pouvez consulter les informations suivantes :
+ **Nom de la mise à jour de service** : le nom unique de la mise à jour de service
+ **Description de la mise à jour** : informations détaillées sur la mise à jour du service
+ **Date de début de mise à jour automatique** : si cet attribut est défini, MemoryDB commencera à planifier la mise à jour automatique de vos clusters dans les fenêtres de maintenance appropriées après cette date. Vous recevrez des notifications à l'avance sur la période de maintenance planifiée exacte, qui peut ne pas être celle qui suit immédiatement la **date de début de la mise à jour automatique**. Vous pouvez toujours appliquer la mise à jour à vos clusters à tout moment. Si l'attribut n'est pas défini, la mise à jour du service n'est pas activée et MemoryDB ne mettra pas automatiquement à jour vos clusters.
Dans la section **Cluster update status** (Statut de mise à jour des clusters), vous pouvez afficher une liste des clusters où la mise à jour de service n'a pas été appliquée ou vient de l'être récemment. Pour chaque cluster, vous pouvez afficher les éléments suivants :
+ **Nom du cluster** : le nom du cluster
+ **Nœuds mis à jour :** ratio des nœuds individuels d'un cluster spécifique qui ont été mis à jour ou qui restent disponibles pour la mise à jour d'un service spécifique.
+ **Type de mise à jour** : le type de la mise à jour de service, qui est soit **security-update** (mise à jour de sécurité), soit **engine-update** (mise à jour du moteur)
+ **Statut** : le statut de la mise à jour de service sur le cluster, qui est l'un des suivants :
+ *disponible* : la mise à jour est disponible pour le cluster requis.
+ *en cours d'application* : la mise à jour est en cours d'application à ce cluster.
+ *scheduled (planifiée)* : la date de mise à jour a été programmée.
+ *complete (achevée)* : la mise à jour a été correctement effectuée. Le cluster dont le statut est complet sera affiché pendant 7 jours après son achèvement.
Si vous choisissez l'un ou l'ensemble des clusters ayant le statut **available** (disponible) ou **scheduled** (planifié), puis choisissez **Apply now** (Appliquer maintenant), la mise à jour commencera à être appliquée à ces clusters.
## Appliquer les mises à jour du service à l'aide du AWS CLI
Après avoir reçu la notification indiquant que les mises à jour du service sont disponibles, vous pouvez les inspecter et les appliquer à l'aide de la AWS CLI :
+ Pour afficher une description des mises à jour de service disponibles, exécutez la commande suivante :
`aws memorydb describe-service-updates --status available`
Pour de plus amples informations, veuillez consulter [describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html).
+ Pour appliquer une mise à jour de service à une liste de clusters, exécutez la commande suivante :
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
Pour de plus amples informations, veuillez consulter [batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html).