Q : En quoi consiste Amazon ElastiCache pour Redis ?

Amazon ElastiCache pour Redis est un service Web qui simplifie le déploiement et l'exécution de nœuds de serveur compatibles avec le protocole Redis dans le cloud. Ce service permet de gérer, surveiller et exécuter un nœud Redis. Ainsi, la création, la suppression et la modification d'un nœud peuvent s'effectuer via la console ElastiCache, l'interface de ligne de commande ou les API du service Web. Amazon ElastiCache pour Redis prend en charge la réplication maître/esclave Redis.

Q : La version Amazon ElastiCache pour Redis est-elle compatible avec le protocole du système Redis à code source libre ?

Oui, la version Amazon ElastiCache pour Redis est compatible avec le protocole du système Redis à code source libre. Le code, les applications, les pilotes et les outils actuellement utilisés par un client dans son magasin de données Redis autonome existant continuent de fonctionner avec ElastiCache pour Redis et aucune modification ne doit être apportée au code pour les déploiements Redis actuels lors de leur migration vers ElastiCache pour Redis, sauf indication contraire. Nous prenons actuellement en charge Redis 2.6.13, 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23, 2.8.24, 3.2.4, 3.2.6 et 3.2.10.

Q : Combien coûte Amazon ElastiCache for Redis ?

Pour obtenir des informations sur la tarification actuelle, consultez la page de tarification.

Q : En quoi consistent les nœuds de cache, les clusters et les groupes de réplications d'Amazon ElastiCache pour Redis ?

Un nœud Amazon ElastiCache pour Redis constitue le bloc de construction le plus petit au sein d'un déploiement Amazon ElastiCache pour Redis. Chaque nœud ElastiCache pour Redis prend en charge le protocole Redis et possède un nom DNS et un port DNS qui lui sont propres. Plusieurs types de nœuds ElastiCache pour Redis sont pris en charge, chacun ayant des quantités variables de capacité CPU et de mémoire associées. Un nœud ElastiCache pour Redis peut endosser le rôle de nœud principal ou de réplica en lecture. Un nœud principal peut être répliqué en divers nœuds de réplica en lecture. Un cluster ElastiCache pour Redis regroupe un ou plusieurs nœuds ElastiCache pour Redis endossant le même rôle : le nœud principal figurera dans le cluster principal et le nœud de réplica en lecture, dans le cluster des réplicas en lecture. A l'heure actuelle, un cluster ne peut contenir qu'un seul nœud. Ce nombre sera revu à la hausse par la suite. Un cluster gère un espace de clés logiques, au sein duquel chaque nœud est responsable d'une partie de l'espace de clés. La plupart des opérations de gestion sont effectuées au niveau du cluster. Un groupe de réplications ElastiCache pour Redis regroupe le cluster principal et les clusters de réplicas en lecture d'une installation Redis. Un groupe de réplications contient un seul cluster principal et peut inclure plusieurs clusters de réplicas en lecture (ou aucun). Tous les nœuds au sein d'un groupe de réplications (et, donc, d'un cluster) sont du même type et possèdent la même configuration au niveau des paramètres et du groupe de sécurité.

Q : La version Amazon ElastiCache for Redis prend-elle en charge la persistance du système Redis ?

Oui, vous pouvez obtenir la persistance en réalisant un instantané de vos données Redis à l'aide de la fonctionnalité Sauvegarde et restauration. Cliquez ici pour en savoir plus.

Q : Comment passer d'Amazon ElastiCache pour Memcached à Amazon ElastiCache pour Redis et inversement ?

Nous ne prenons actuellement pas en charge la migration automatique entre Memcached et Redis. Toutefois, vous pouvez utiliser un client Memcached pour lire à partir d'un cluster Memcached et un client Redis pour écrire sur un cluster Redis. De même, vous pouvez lire à partir d'un cluster Redis à l'aide d'un client Redis et utiliser un client Memcached pour écrire sur un cluster Memcached. Assurez-vous de prendre en compte les différences de format de données entre les deux moteurs, ainsi que la configuration des clusters.

Q : La version Amazon ElastiCache pour Redis permet-elle un fonctionnement multi-AZ ?

Oui, avec Amazon ElastiCache pour Redis, vous pouvez créer un réplica en lecture dans une autre zone de disponibilité AWS. En cas de panne du nœud principal, nous mettons en service un nouveau nœud principal. Dans le cas où il est impossible de mettre en service le nœud principal, vous pouvez décider quel réplica en lecture promouvoir en tant que nouveau nœud principal. Pour en savoir plus sur la prise en charge des pannes de nœud, cliquez ici.

Q : Quelles sont les options fournies par Amazon ElastiCache pour Redis en cas de panne sur un nœud ?

Amazon ElastiCache pour Redis répare le nœud en acquérant de nouvelles ressources de service et redirige ensuite le nom DNS existant du nœud afin qu'il pointe vers ces nouvelles ressources de service. Ainsi, le nom DNS du nœud Redis reste constant, mais son adresse IP peut changer. En cas de panne, si vous disposez d'un groupe de réplication composé d'un ou plusieurs réplicas en lecture et que Multi-AZ est activé, ElastiCache détectera automatiquement la panne, choisira un réplica et le définira comme le nouveau nœud principal. Il propagera également le DNS, afin que vous puissiez continuer à utiliser le point de terminaison principal. Une fois le nouveau nœud défini, le DNS redirigera vers celui-ci. Pour plus de détails, consultez la section Multi-AZ de cette FAQ. En cas de panne du nœud principal, si l'option de réplication Redis est sélectionnée, mais que Multi-AZ est désactivé, vous pourrez choisir de lancer un basculement vers un nœud de réplica en lecture. La cible du basculement peut figurer dans la même zone ou dans une zone différente. Pour un basculement vers la zone d'origine, vous devez promouvoir le réplica en lecture au sein de la zone d'origine en tant que nœud principal. Vous pouvez opter pour une architecture de votre application qui oblige la bibliothèque du client Redis à se reconnecter au nœud de serveur Redis réparé. Cela peut être utile, car certaines bibliothèques Redis cessent définitivement d'utiliser un serveur dès lors qu'elles rencontrent des erreurs ou des dépassements de délais de communication.

Q : Comment le basculement fonctionne-t-il ?

Pour les groupes de réplication pour lesquels Multi-AZ est activé, le comportement de basculement est décrit dans la section Multi-AZ de cette FAQ.

Si vous choisissez de ne pas activer Multi-AZ, Amazon ElastiCache surveille le nœud principal. Si le nœud n'est plus disponible ou ne répond plus, Amazon ElastiCache pour Redis répare alors le nœud en acquérant de nouvelles ressources de service, puis redirige le nom DNS existant du nœud afin qu'il pointe vers ces nouvelles ressources de service. Ainsi, le nom DNS du nœud Redis reste constant, mais son adresse IP peut changer. Cependant, si le nœud principal ne peut pas être réparé (et si votre Multi-AZ est désactivé), vous pouvez décider de promouvoir un des réplicas en lecture en tant que nouveau nœud principal. Pour en savoir plus sur la sélection du nouveau nœud principal, cliquez ici. L'enregistrement DNS du point de terminaison du nœud principal est alors mis à jour afin de pointer vers le nœud de réplica en lecture promu. Un nœud de réplica en lecture est créé au sein de la zone de disponibilité d'origine du nœud principal en tant que réplica en lecture dans le groupe de réplications et suit les modifications apportées au nouveau nœud principal. 

Q : Mes réplicas en lecture sont-ils disponibles en cas de panne du nœud principal ?

Oui, en cas de panne du nœud principal, les réplicas en lecture continuent de répondre aux requêtes. Toutefois, une fois le nœud principal restauré (soit après réparation, soit par promotion d'un réplica en lecture), les réplicas en lecture ne peuvent répondre à aucune requête durant un court laps de temps pendant lequel ils synchronisent les informations de cache à partir du nœud principal.

Q : Comment configurer les paramètres de mes nœuds Amazon ElastiCache pour Redis ?

Vous pouvez configurer votre installation Redis à l'aide d'un groupe de paramètres de cache, que vous devez obligatoirement spécifier pour un cluster Redis. Tous les clusters de réplicas en lecture utilisent le groupe de paramètres de leur cluster principal. Un groupe de paramètres Redis agit en tant que « conteneur » pour les valeurs de configuration Redis qui peuvent être appliquées à un ou plusieurs clusters principaux Redis. Si vous créez un cluster principal Redis sans spécifier de groupe de paramètres de cache, celui par défaut est utilisé. Ce groupe par défaut contient les valeurs par défaut pour le type de nœud que vous souhaitez exécuter. Toutefois, si vous voulez que votre cluster principal Redis soit exécuté avec des valeurs de configuration spécifiques, il vous suffit de créer un nouveau groupe de paramètres de cache et de modifier les paramètres souhaités ainsi que le cluster Redis principal pour utiliser le nouveau groupe de paramètres.

Q : Puis-je accéder à Redis via la console Amazon ElastiCache ?

Oui, Redis figure comme une option de moteur dans la console ElastiCache. Vous pouvez créer un cluster de cache Redis avec l'assistant Launch Wizard en sélectionnant le moteur Redis. Vous pouvez également modifier ou supprimer un cluster Redis existant à partir de la console ElastiCache.

Q : Est-il possible de créer des clusters Amazon ElastiCache pour Redis dans un VPC Amazon ?

Oui. Si votre compte correspond à un compte VPC par défaut, vos clusters Redis sont créés au sein du VPC par défaut associé à votre compte. A partir de la console ElastiCache, vous pouvez spécifier un autre VPC lorsque vous créez votre cluster.

Q : La fonctionnalité Redis de gestion des mots de passe est-elle prise en charge par Amazon ElastiCache pour Redis ?

Non, Amazon ElastiCache pour Redis ne prend pas en charge les mots de passe Redis. Cela s'explique par les limitations inhérentes aux mots de passe stockés dans un fichier de configuration. Au lieu de se baser sur les mots de passe Redis, les clusters ElastiCache pour Redis sont associés à un groupe de sécurité EC2 et seuls les clients figurant au sein d'un groupe de sécurité ont accès au serveur Redis.

Q : Comment passer à une version plus récente du moteur ?

Vous pouvez facilement passer à une version plus récente du moteur à l'aide des API ModifyCacheCluster ou ModifyReplicationGroup et en spécifiant votre version préférée du moteur pour le paramètre EngineVersion. Dans la console ElastiCache, vous pouvez sélectionner un cluster de cache ou un groupe de réplications et cliquer sur « Modify ». Dans la fenêtre « Modify Cache Cluster » ou « Modify Replication Group », sélectionnez votre version préférée du moteur dans les options disponibles. Le processus de mise à niveau du moteur met tout en œuvre pour conserver vos données existantes et nécessite, pour ce faire, l'option de réplication Redis. Cliquez ici pour en savoir plus.

Q : Puis-je revenir à une ancienne version du moteur ?

Non. Il est impossible de revenir à une version précédente du moteur.

Q : Comment passer à un type de nœud d'une taille supérieure ?

Vous pouvez facilement passer à un type de nœud d'une taille supérieure à l'aide des API ModifyCacheCluster ou ModifyReplicationGroup et en spécifiant votre type de nœud préféré moteur pour le paramètre CacheNodeType. Dans la console ElastiCache, vous pouvez sélectionner un cluster de cache ou un groupe de réplications et cliquer sur « Modify ». Dans la fenêtre « Modify Cache Cluster » ou « Modify Replication Group », sélectionnez votre type de nœud préféré dans les options disponibles. Le processus de mise à l'échelle met tout en œuvre pour conserver vos données existantes et nécessite, pour ce faire, l'option de réplication Redis. Cliquez ici pour en savoir plus.

Q : Puis-je passer à un type de nœud d'une taille inférieure ?

Il est actuellement impossible de passer à un type de nœud d'une taille inférieure.


Q : En quoi consiste l'exécution d'un nœud de cache Redis en tant que réplica en lecture ?

Dans Redis, les réplicas en lecture sont utilisés de deux manières :

  • gestion des pannes
  • dimensionnement en lecture

Lorsque vous exécutez un nœud de cache avec un réplica en lecture, le « nœud principal » sert à la fois pour la lecture et l'écriture. Le réplica en lecture sert de nœud de « secours », qui est « promu » dans le cadre des scénarios de basculement. Après le basculement, le nœud de secours devient le nœud principal et accepte vos opérations de cache. Les réplicas en lecture facilitent également la mise à l'échelle élastique au-delà des contraintes de capacité d'un seul nœud de cache, afin d'exécuter les charges de travail du cache qui nécessitent de très nombreuses lectures.

Q : Quand envisager l'utilisation d'un réplica en lecture Redis ?

Il existe divers scénarios où le déploiement d'un ou plusieurs réplicas en lecture pour un nœud principal donné est recommandé. Les principales raisons d'un déploiement de réplica en lecture sont les suivantes :

  • Le dimensionnement au-delà de la capacité de calcul ou d'E/S d'un seul nœud principal pour des charges de travail à forte densité de lectures. Ce trafic en lecture excessif peut alors être dirigé vers un ou plusieurs réplicas en lecture.
  • La prise en charge du trafic en lecture en cas d'indisponibilité du nœud principal. Si votre nœud principal ne peut pas prendre en charge les demandes d'E/S (par ex. en raison de la suspension des E/S à des fins de sauvegarde ou de maintenance planifiée), vous pouvez diriger le trafic en lecture vers vos réplicas en lecture. Dans ce type de cas d'utilisation, gardez à l'esprit le fait que les données sur le réplica en lecture peuvent être « périmées », étant donné que le nœud principal est indisponible. Le réplica en lecture peut aussi servir à relancer un préchauffage du nœud principal en échec.
  • A des fins de protection des données et dans le cas peu probable d'une défaillance du nœud principal ou d'une indisponibilité de la zone de disponibilité dans laquelle réside votre nœud principal, vous pouvez promouvoir, en tant que nouveau nœud principal, un réplica en lecture figurant dans une autre zone de disponibilité.

Q : Comment déployer un nœud de réplica en lecture pour un nœud de cache principal spécifique ?

Vous pouvez créer un réplica en lecture en quelques minutes au moyen de l'API CreateReplicationGroup ou en quelques clics sur la console de gestion d'Amazon ElastiCache. Lorsque vous créez un groupe de réplications, vous spécifiez la valeur MasterCacheClusterIdentifier. Cette valeur MasterCacheClusterIdentifier est l'identifiant du cluster de cache « principal », à partir duquel vous souhaitez effectuer la réplication. Vous pouvez ensuite créer le cluster des réplicas en lecture au sein du même groupe de réplications en appelant l'API CreateCacheCluster et en spécifiant les valeurs ReplicationGroupIdentifier et CacheClusterIdentifier du cluster maître. De même que pour un cluster de cache standard, vous pouvez également définir la zone de disponibilité. Lorsque vous lancez la création d'un réplica en lecture, Amazon ElastiCache prend un instantané de votre cluster de cache principal et commence la réplication. En conséquence, vous rencontrerez une brève suspension des E/S sur votre cluster de cache principal au moment où l'instantané est pris. Cette suspension des E/S ne dure généralement qu'une minute environ.

Les réplicas en lecture sont aussi faciles à supprimer qu'à créer : il vous suffit d'utiliser la console de gestion d'Amazon ElastiCache ou d'appeler l'API DeleteCacheCluster (en spécifiant la valeur CacheClusterIdentifier du réplica en lecture que vous souhaitez supprimer).

Q : Puis-je créer simultanément un nœud principal et des réplicas en lecture ?

Oui. Vous pouvez créer un cluster de cache et des réplicas en lecture en quelques minutes à l'aide de l'API CreateReplicationGroup ou de l'assistant « Launch Cache Cluster » et de l'option « Multi-AZ Replication » sur ElastiCache Management Console. Lors de la création du groupe de réplications, spécifiez l'identifiant de celui-ci, le nombre total de clusters souhaités dans le groupe de réplications et des paramètres de création de cache tels que le type de nœud de cache, la version du moteur de cache, etc. Vous pouvez également spécifier la zone de disponibilité de chaque cluster du groupe de réplications.

Q : Comment puis-je me connecter à mes réplicas en lecture ?

Vous pouvez vous connecter à un réplica en lecture de la même manière qu'à un nœud de cache principal, en utilisant l'API DescribeCacheClusters ou AWS Management Console pour récupérer votre/vos point(s) de terminaison vers votre/vos réplica(s) en lecture. Si vous avez plusieurs réplicas en lecture, c'est votre application qui détermine comment le trafic en lecture sera distribué entre eux.

Q : Combien de réplicas en lecture puis-je créer pour un nœud de cache principal donné ?

A l'heure actuelle, Amazon ElastiCache vous permet de créer jusqu'à cinq (5) réplicas en lecture pour un nœud de cache principal donné.

Q : Qu'advient-il des réplicas en lecture en cas de basculement ?

En cas de basculement, tout réplica en lecture associé et disponible doit reprendre la réplication automatique une fois le basculement terminé (avec acquisition des mises à jour depuis le réplica en lecture nouvellement promu).

Q : Puis-je créer un réplica en lecture d'un autre réplica en lecture ?

La création du réplica en lecture d'un autre réplica en lecture n'est pas prise en charge.

Q : Puis-je transformer mon réplica en lecture en nœud de cache principal « autonome » ?

Non, cette fonctionnalité n'est pas prise en charge. En revanche, vous pouvez prendre un instantané de votre nœud ElastiCache pour Redis (vous pouvez sélectionner le nœud principal ou l'un de ses réplicas en lecture). Vous pouvez ensuite utiliser cet instantané (snapshot) pour créer un nouveau nœud principal Amazon ElastiCache pour Redis.

Q : Mon réplica en lecture sera-t-il tenu à jour par rapport à son nœud de cache principal ?

Les mises à jour appliquées au nœud de cache principal sont immédiatement répliquées sur les réplicas en lecture associés. Toutefois, avec la technologie de réplication asynchrone de Redis, un réplica en lecture peut prendre du retard par rapport à son nœud de cache principal pour diverses raisons. Les raisons typiques incluent :

  • Le volume des E/S en écriture sur le nœud de cache principal est supérieur au rythme auquel les modifications peuvent être appliquées sur le réplica en lecture
  • Des partitions ou des temps de latence réseau entre le nœud de cache principal et un réplica en lecture

Les réplicas en lecture sont sujets aux forces et aux faiblesses de la réplication Redis. Si vous utilisez des réplicas en lecture, vous devez être conscient du risque de retard entre un réplica en lecture et son nœud de cache principal ou d'une « incohérence » possible. Pour des instructions sur la détection d'une telle « incohérence » sur votre réplica en lecture, cliquez [ici].

Q : Comment gagner en visibilité sur les réplicas en lecture actifs ?

Vous pouvez utiliser l'API DescribeCacheClusters standard pour renvoyer la liste de tous les clusters de cache que vous avez déployés (y compris les réplicas en lecture), ou cliquer simplement sur l'onglet « Cache Clusters » d'Amazon ElastiCache Management Console.

Amazon ElastiCache surveille le statut de réplication de vos réplicas en lecture et met à jour le champ Replication State avec la valeur Error si la réplication est interrompue pour une raison quelconque. Vous pouvez consulter les détails de l'erreur en question, renvoyée par le moteur Redis, dans le champ Replication Error et, ainsi, effectuer l'opération de récupération appropriée. Pour en savoir plus sur la résolution des problèmes de réplication, consultez la section Troubleshooting a Read Replica problem du manuel Amazon ElastiCache User Guide. Lorsqu'une erreur de réplication est résolue, le champ Replication State présente la valeur Replicating.

Amazon ElastiCache vous permet de voir à quel point un réplica en lecture a pris du retard par rapport au nœud principal par le biais de la mesure Amazon CloudWatch (« Replica Lag ») accessible à partir d'AWS Management Console ou des API Amazon CloudWatch.

Q : Mon réplica en lecture a pris beaucoup de retard par rapport à son nœud de cache principal. Que dois-je faire ?

Comme évoqué dans les questions précédentes, une « incohérence » ou un retard entre un réplica en lecture et son nœud de cache principal est courant avec la réplication asynchrone Redis. Si un réplica en lecture a pris beaucoup trop de retard et ne satisfait plus à vos exigences, vous pouvez le redémarrer. Gardez également à l'esprit le fait que le retard du réplica peut augmenter et diminuer naturellement avec le temps, en fonction du modèle d'utilisation continue de votre nœud de cache principal.

Q : Comment supprimer un réplica en lecture ? Sera-t-il supprimé automatiquement si son nœud de cache principal est supprimé ?

Vous pouvez facilement supprimer un réplica en lecture en quelques clics sur AWS Management Console ou en transmettant l'identifiant de son cluster de cache à l'API DeleteCacheCluster. Si vous souhaitez supprimer le réplica en lecture en plus du nœud de cache principal, vous devez utiliser l'API DeleteReplicationGroup ou AWS Management Console.

Q : Combien coûtent les réplicas en lecture ? Quelles sont les dates de début et de fin de facturation ?

Un réplica en lecture est facturé comme un nœud de cache standard et aux mêmes tarifs. Comme pour un nœud de cache standard, le tarif par « heure de nœud de cache » pour un réplica en lecture est déterminé par sa classe de nœud de cache ; consultez la page de présentation d'Amazon ElastiCache pour connaître les derniers tarifs en vigueur. Les frais de transfert lors de la réplication des données entre votre nœud de cache principal et le réplica en lecture ne vous sont pas facturés. La facturation du réplica en lecture débute dès sa création (c.-à-d. lorsque le statut indiqué est « active »). Le réplica en lecture continuera de vous être facturé aux tarifs horaires d'un nœud de cache Amazon ElastiCache standard jusqu'à ce que vous exécutiez une commande pour le supprimer.

Q : Que se passe-t-il au cours du basculement et combien de temps cela dure-t-il ?

Le basculement initié est pris en charge par Amazon ElastiCache afin que vous puissiez reprendre les opérations de cache aussi rapidement que possible. Lors du basculement, Amazon ElastiCache modifie simplement l'enregistrement DNS de votre nœud de cache afin qu'il pointe vers le réplica en lecture, lequel est alors promu comme nouveau nœud principal. Nous vous encourageons à suivre les bonnes pratiques et à implémenter une nouvelle tentative de connexion au nœud de cache au niveau de la couche applicative. Du début à la fin, le basculement dure généralement trois à six minutes.

Q : Puis-je créer un réplica en lecture dans une région différente de celle de mon nœud principal ?

Non. Votre réplica en lecture peut uniquement être mis en service au sein d'une zone de disponibilité (identique ou non) appartenant à la même région que celle de votre nœud de cache principal.

Q : Puis-je voir dans quelle zone de disponibilité mon nœud principal est situé actuellement ?

Oui, vous pouvez avoir accès à l'emplacement du nœud principal actuel en utilisant AWS Management Console ou l'API DescribeCacheClusters.

Après un basculement, mon instance principale se trouve désormais dans une zone de disponibilité différente de mes autres ressources AWS (par ex. instances EC2).

Q : Dois-je m'inquiéter des temps de latence ?

Les zones de disponibilité sont conçues pour fournir une connectivité de réseau à faible latence vers les autres zones de disponibilité dans la même région. En outre, vous pourriez envisager d'avoir une architecture avec redondance pour votre application et d'autres ressources AWS parmi des zones de disponibilité multiples, afin que votre application soit résiliente en cas de défaillance d'une zone de disponibilité.


Q : Qu'est-ce que la fonction multi-AZ pour un groupe de réplications ElastiCache pour Redis ?

Un groupe de réplications ElastiCache pour Redis est composé d'un nœud principal et d'un maximum de cinq réplicas en lecture. Redis réplique de manière asynchrone les données du nœud principal vers les réplicas en lecture. Lors de certains types de maintenance planifiée ou dans le cas peu probable d'une panne de nœud ElastiCache ou d'une défaillance de zone de disponibilité, Amazon ElastiCache détecte automatiquement la panne d'un nœud principal, sélectionne un réplica en lecture et le promeut en tant que nœud principal. ElastiCache propage également les modifications DNS du réplica en lecture promu. Si votre application effectue des opérations en écriture sur le point de terminaison du nœud principal, aucune modification du point de terminaison n'est donc nécessaire.

Q : Quels sont les avantages de l'utilisation de la fonction multi-AZ ?

Les principaux avantages de l'exécution d'ElastiCache pour Redis en mode multi-AZ résident dans l'amélioration de la disponibilité et des tâches d'administration moins nombreuses. Si un nœud principal ElastiCache pour Redis tombe en panne, l'impact sur les opérations en lecture/écriture sur le nœud principal est limité à la durée de mise en place du basculement automatique. Lorsque la fonction multi-AZ est activée, le basculement de nœud ElastiCache est automatique et ne nécessite pas d'administration. Vous n'avez plus besoin de surveiller vos nœuds Redis et de lancer une récupération manuelle en cas de défaillance de nœud principal.

Q : Comment la fonction multi-AZ fonctionne-t-elle ?

Vous pouvez avoir recours à la fonction multi-AZ si vous utilisez ElastiCache pour Redis et disposez d'un groupe de réplications composé d'un nœud principal et d'un ou plusieurs réplicas en lecture. En cas de défaillance du nœud principal, ElastiCache détecte automatiquement la panne, sélectionne un réplica en lecture parmi ceux disponibles et le promeut en tant que nouveau nœud principal. ElastiCache propage les modifications DNS du réplica promu pour que votre application puisse continuer à effectuer des opérations en écriture sur le point de terminaison du nœud principal. ElastiCache fait également tourner un nouveau nœud pour remplacer le réplica en lecture promu dans la même zone de disponibilité que le nœud principal défaillant. En cas de défaillance du nœud principal en raison d'une indisponibilité temporaire de la zone de disponibilité, le nouveau réplica est lancé une fois la zone de disponibilité remise en service.

Q : Des réplicas peuvent-ils se trouver dans la même zone de disponibilité que le nœud principal ?

Oui. Le placement du nœud principal et du ou des réplicas dans une même zone de disponibilité ne permet toutefois pas de rendre votre groupe de réplications ElastiCache pour Redis résilient en cas de défaillance d'une zone de disponibilité.

Q : A la suite de quels événements Amazon ElastiCache procède-t-il au basculement vers un réplica en lecture ?

Amazon ElastiCache procède au basculement vers un réplica en lecture dès lors qu'un des événements suivants se produit :

  • Perte de disponibilité dans la zone de disponibilité du nœud principal
  • Perte de connectivité réseau avec le serveur principal
  • Échec d'unité de calcul sur le serveur principal

Q : Dans quel cas dois-je utiliser la fonction multi-AZ ?

L'utilisation conjointe de la réplication Redis et de la fonction multi-AZ améliore la disponibilité et la tolérance aux pannes. Les déploiements de ce type constituent un choix naturel pour les environnements de production.

Q : Comment puis-je créer un groupe de réplications ElastiCache pour Redis avec la fonction multi-AZ activée ?

Vous pouvez créer un nœud principal ElastiCache pour Redis et des réplicas en lecture en cliquant sur Launch Cache Cluster dans ElastiCache Management Console. Vous pouvez également appeler l'API CreateReplicationGroup. Pour les groupes de réplication existants (Redis 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23 et 2.8.24), vous pouvez activer la fonction multi-AZ en procédant comme suit : sélectionnez un groupe de réplications et cliquez sur « Modify » dans la console de gestion d'Amazon ElastiCache, ou utilisez l'API ModifyReplicationGroup. Faire basculer un groupe de réplication vers Multi-AZ ne perturbe pas vos données Redis et n'interfère pas avec la capacité de vos nœuds à répondre aux demandes.

Q : En cas de défaillance du nœud principal, quel réplica en lecture est promu ?

S'il existe plusieurs réplicas en lecture, c'est celui dont le retard de réplication asynchrone est le plus court sur le nœud principal qui est promu.

Q : Que coûte l'utilisation de la fonction multi-AZ ?

La fonction multi-AZ est gratuite. Vous ne payez des frais que pour les nœuds ElastiCache que vous utilisez.

Q : Quelles sont les répercussions de la fonction multi-AZ sur les performances ?

ElastiCache utilise actuellement la réplication asynchrone native du moteur Redis et profite de ses points forts, mais subit aussi ses limites. En particulier, lorsqu'un réplica en lecture se connecte à un nœud principal pour la première fois, ou si le nœud principal change, le réplica en lecture effectue une synchronisation complète des données du nœud principal, imposant ainsi la charge au nœud principal et à lui-même. Pour obtenir des informations supplémentaires au sujet de la réplication Redis, cliquez ici

Q : Quels types de nœuds de cache prennent en charge la fonction multi-AZ ?

Tous les types de nœuds de cache disponibles dans ElastiCache prennent en charge la fonction multi-AZ, à l'exception des familles T1 et T2.

Q : Serai-je averti lorsqu'un basculement automatique a lieu ?

Oui, Amazon ElastiCache crée un événement pour vous informer qu'un basculement automatique a eu lieu. Vous pouvez utiliser l'API DescribeEvents pour renvoyer des informations sur des évènements en rapport à votre nœud ElastiCache, ou cliquer sur la section Events d'ElastiCache Management Console.

Q : Après un basculement, mon instance principale se trouve désormais dans une zone de disponibilité différente de celle de mes autres ressources AWS (instances EC2, par exemple). Dois-je m'inquiéter des temps de latence ?

Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région. Vous pourriez envisager d'adopter une architecture avec redondance sur plusieurs zones de disponibilité pour votre application et d'autres ressources AWS, afin que votre application soit résiliente en cas de défaillance sur une zone de disponibilité spécifique.

Q : Où puis-je trouver des informations supplémentaires sur la fonction multi-AZ ?

Pour plus d'informations sur la fonction multi-AZ, consultez la documentation ElastiCache.


Q : En quoi consiste la fonction de sauvegarde et de restauration ?

La fonction de sauvegarde et de restauration permet aux clients de créer des instantanés de leurs clusters Amazon ElastiCache pour Redis. ElastiCache conserve ces instantanés et les utilisateurs peuvent les exploiter par la suite afin de restaurer leurs clusters Redis.

Q : Qu'est-ce qu'un instantané ?

Un instantané est une copie de l'ensemble de votre cluster Redis à un moment donné.

Q : Quel est l'intérêt des instantanés ?

Il peut être utile de créer des instantanés pour faire face à la perte de données suite à la défaillance d'un nœud ou dans le cas peu probable d'une panne matérielle. Les sauvegardes sont aussi souvent utilisées à des fins d'archivage. Les instantanés sont conservés dans Amazon S3, qui garantit un stockage durable. Cela signifie que, même en cas de panne d'alimentation, vos données ne sont pas perdues.

Q : Que puis-je faire avec un instantané ?

Vous pouvez utiliser des instantanés pour effectuer le démarrage à chaud d'un cluster ElastiCache pour Redis incluant des données préchargées.

Q : Quel est le mode opératoire de la fonction de sauvegarde et de restauration ?

Lorsqu'une sauvegarde est lancée, ElastiCache prend un instantané du cluster Redis spécifié à des fins de restauration ou d'archivage. Vous pouvez lancer une sauvegarde quand vous le souhaitez ou définir une sauvegarde quotidienne récurrente, avec une période de conservation des données de 35 jours maximum.

Une fois que vous avez choisi l'instantané à partir duquel effectuer la restauration, un nouveau cluster ElastiCache pour Redis est créé et alimenté à partir des données de l'instantané. Vous pouvez ainsi créer plusieurs clusters ElastiCache pour Redis à partir d'un même instantané.

Actuellement, ElastiCache utilise le mécanisme natif de Redis pour créer et stocker un fichier RDB en tant qu'instantané.

Q : Où sont stockés les instantanés ?

Les instantanés sont conservés dans Amazon S3.

Q : Comment lancer la fonction de sauvegarde et de restauration ?

Vous pouvez lancer la fonction de sauvegarde et de restauration via AWS Management Console, les API ElastiCache (CreateCacheCluster, ModifyCacheCluster et ModifyReplicationGroup) ou l'interface de ligne de commande. Vous pouvez désactiver et réactiver cette fonction à tout moment.

Q : Comment spécifier le cluster ou le nœud Redis à sauvegarder ?

La fonction de sauvegarde et de restauration crée des instantanés sur la base d'un cluster. Il est possible de définir le cluster ElastiCache pour Redis à sauvegarder à partir d'AWS Management Console, ou en utilisant l'interface de ligne de commande ou l'API CreateSnapshot. Au sein d'un groupe de réplication, vous pouvez choisir de sauvegarder le cluster principal ou l'un des clusters de réplicas en lecture. Nous recommandons d'activer la fonction de sauvegarde sur l'un des réplicas en lecture, afin d'éviter tout impact négatif en termes de temps de latence sur le nœud principal Redis.

Q : Comment préciser quand la sauvegarde doit être lancée ?

Vous pouvez préciser quand lancer une sauvegarde ponctuelle ou une sauvegarde récurrente dans AWS Management Console, ou en utilisant l'interface de ligne de commande ou les API. Voici les différentes opérations possibles :

  • Vous pouvez prendre immédiatement un instantané (bouton Create Snapshot de la console ou API CreateSnapshot).
  • Vous pouvez configurer une sauvegarde quotidienne automatique. La sauvegarde s'effectuera durant la plage de sauvegarde préconisée. Cette option peut être paramétrée lors de la création/modification du cluster via la console ou à l'aide des API CreateCacheCluster, ModifyCacheCluster ou ModifyReplicationGroup.

Q : Qu'est-ce qu'une plage de sauvegarde et pourquoi en ai-je besoin ?

La plage de sauvegarde préconisée est une période définie par l'utilisateur durant laquelle la sauvegarde de votre cluster ElastiCache pour Redis se lance. Elle vous est utile si vous souhaitez que la sauvegarde intervienne à une heure précise ou qu'elle ne se lance pas lors de périodes d'utilisation particulièrement intensive.

Q : Quel est l'impact sur les performances lors de la capture d'un instantané ?

Lors de la capture d'un instantané, il est possible que vous observiez, au niveau du nœud, des temps de latence supérieurs durant un court laps de temps. Les instantanés exploitent la commande BGSAVE intégrée à Redis et profitent donc de ses atouts, mais sont aussi limités par ses faiblesses. Ainsi, le processus Redis se subdivise, le parent continuant à répondre aux requêtes, tandis que l'enfant sauvegarde les données sur le disque avant de se fermer. Cette subdivision augmente l'utilisation de la mémoire durant la génération de l'instantané. Lorsque l'utilisation de la mémoire dépasse la mémoire disponible du nœud de cache, une permutation peut être déclenchée, ralentissant encore davantage le nœud. C'est pourquoi nous recommandons de générer les instantanés à partir de l'un des réplicas en lecture (et non du nœud principal). De plus, nous vous suggérons de définir le paramètre relatif à la mémoire réservée afin de minimiser l'utilisation de la permutation. Cliquez ici pour en savoir plus.

Q : Puis-je créer un instantané à partir d'un réplica en lecture ElastiCache pour Redis ?

Oui. La création d'un instantané à partir d'un réplica en lecture ElastiCache pour Redis est même le meilleur moyen de sauvegarder vos données tout en limitant l'impact sur les performances.

Q : Dans quelles régions la fonction de sauvegarde et de restauration est-elle disponible ?

La fonction de sauvegarde et de restauration est disponible dans toutes les régions où le service ElastiCache est disponible.

Q : Puis-je exporter les instantanés ElastiCache pour Redis vers un compartiment que je possède ?

Oui. Vous pouvez exporter vos instantanés (snapshots) ElastiCache pour Redis vers un bucket (compartiment) S3 autorisé dans la même région que votre cluster. Pour plus d'informations sur l'exportation d'instantanés et la configuration des permissions nécessaires, reportez-vous à cette page.

Q : Puis-je copier des instantanés d'une région vers une autre ?

Oui. Vous devez tout d'abord copier votre instantané (snapshot) vers un bucket (compartiment) S3 autorisé de votre choix dans la même région, puis utiliser l'API S3 PUT object- Copy pour le copier vers un bucket dans une autre région. Pour plus d'informations sur la copie d'objets S3, veuillez consulter cette page.

Q : Je dispose de plusieurs comptes AWS utilisant ElastiCache pour Redis. Puis-je utiliser les instantanés ElastiCache d'un compte pour effectuer le démarrage à chaud d'un cluster ElastiCache pour Redis au sein d'un autre compte ?

Oui. Vous devez d'abord copier votre instantané (snapshot) dans un bucket (compartiment) S3 autorisé dans la même région, puis accorder des permissions de bucket inter-comptes à l'autre compte. Pour plus d'informations sur les permissions S3 inter-comptes, veuillez consulter cette page. Enfin, vous pouvez préciser l'emplacement S3 de votre fichier RDB lors de la création du cluster, via l'assistant Launch Cache Cluster de la console, ou par l'API CreateCacheCluster.

Q : Quel est le coût de la fonction de sauvegarde et de restauration ?

Amazon ElastiCache offre un espace de stockage gratuit pour un instantané de chacun de vos clusters ElastiCache pour Redis actifs. Tout stockage supplémentaire vous est facturé selon l'espace utilisé par les instantanés sur la base de 0,085 USD/Go chaque mois (tarif identique dans toutes les régions). Le transfert des données est gratuit dans le cadre de l'utilisation d'instantanés.

Q : En quoi consiste la période de rétention ?

La période de rétention correspond à la durée pendant laquelle les instantanés automatiques sont conservés. Par exemple, si la période de rétention est définie sur 5, un instantané pris aujourd'hui est conservé durant 5 jours avant d'être supprimé. Vous pouvez choisir de copier un ou plusieurs instantanés automatiques afin de les stocker comme des instantanés manuels qui ne seront pas supprimés à l'issue de la période de rétention.

Q : Comment gérer la rétention de mes instantanés automatiques ?

Vous pouvez utiliser AWS Management Console ou l'API ModifyCluster pour gérer la période pendant laquelle vos sauvegardes automatiques sont conservées via le paramètre RetentionPeriod. Si vous souhaitez désactiver complètement les sauvegardes automatiques, vous pouvez définir la période de rétention sur 0 (bien que cette option ne soit pas recommandée).

Q : Que deviennent mes instantanés si je supprime mon cluster ElastiCache pour Redis ?

Lorsque vous supprimez un cluster Amazon ElastiCache pour Redis, vos instantanés manuels sont conservés. Vous avez également la possibilité de créer un instantané final de votre cluster avant sa suppression. En revanche, les instantanés mis en cache automatiquement ne sont pas conservés.

Q : Quels types de nœud de cache prennent en charge la fonction de sauvegarde et de restauration ?

Hormis les nœuds de type t1.micro et t2, tous les nœuds exécutant une instance ElastiCache pour Redis prennent en charge la fonction de sauvegarde et de restauration :

Nœuds de cache de la génération actuelle :

  • cache.m3.medium
  • cache.m3.large
  • cache.m3.xlarge
  • cache.m3.2xlarge
  • cache.r3.large
  • cache.r3.xlarge
  • cache.r3.2xlarge
  • cache.r3.4xlarge
  • cache.r3.8xlarge

Nœuds de cache de la génération précédente :

  • cache.m1.small
  • cache.m1.medium
  • cache.m1.large
  • cache.m1.xlarge
  • cache.m2.xlarge
  • cache.m2.2xlarge
  • cache.m2.4xlarge
  • cache.c1.xlarge

Q : Puis-je utiliser mes propres instantanés RDB stockés dans S3 pour effectuer le démarrage à chaud d'un cluster ElastiCache pour Redis ?

Oui. Vous pouvez préciser l'emplacement S3 de votre fichier RDB lors de la création du cluster, via l'assistant Launch Cache Cluster de la console, ou par l'API CreateCacheCluster.

Q : Puis-je utiliser la fonction de sauvegarde et de restauration si j'exécute ElastiCache dans un VPC ?

Oui.


Q : Qu'est-ce que le redimensionnement de cluster en ligne ?

Amazon ElastiCache for Redis donne la possibilité d'ajouter et supprimer des fragments de clusters en cours d'exécution. Vous pouvez dimensionner de manière dynamique vos charges de travail de clusters Redis pour les adapter aux fluctuations de la demande. ElastiCache redimensionnera le cluster en ajoutant ou en supprimant des fragments et en redistribuant uniformément des emplacements de hachage sur la nouvelle configuration de fragments, le tout pendant que le cluster reste en ligne et continue d'exécuter des demandes.

Q : Quels sont les avantages du redimensionnement de cluster en ligne ?

La possibilité de redimensionner de manière dynamique un cluster peut vous aider à gérer la variabilité d'une application et répondre aux demandes fluctuantes. Vous pouvez dimensionner correctement vos clusters en ajoutant ou en supprimant des fragments pour adapter les performances et la capacité en mémoire. Cette fonctionnalité élimine le besoin de surapprovisionner des clusters en fonction des pics de demande, aide à améliorer l'efficacité et réduit les coûts.

Q : Comment utiliser le redimensionnement de cluster en ligne ?

Le redimensionnement de cluster en ligne est disponible avec la version 3.2.10 du moteur Redis. Pour refragmenter votre cluster, sélectionnez le cluster et indiquez si vous souhaitez ajouter ou supprimer des fragments. Lorsque vous redimensionnez le cluster pour une augmentation, ElastiCache ajoute des fragments et migre des emplacements depuis les fragments existants de sorte que les emplacements soient uniformément répartis (en nombre) sur les fragments. De la même manière, lors du redimensionnement du cluster pour une diminution, ElastiCache migre des emplacements vers les fragments restants pour distribuer uniformément les emplacements et supprime les fragments spécifiés.

Q : Combien de temps prend le redimensionnement de cluster en ligne ?

Le temps pris par le redimensionnement dépend de plusieurs facteurs, comme le nombre d'emplacements devant être migrés sur les fragments, la taille des données et le taux de demandes entrantes sur le cluster. Toutefois, le flux de travail est optimisé de façon à paralléliser la migration d'emplacements, ce qui réduit le temps nécessaire pour l'ajout de fragments pour l'augmentation du cluster.

Q : Est-ce que le cluster peut être utilisé pendant son redimensionnement ?

Oui. Le cluster reste en ligne continue et d'exécuter les demandes entrantes pendant la refragmentation. Cela dit, la prise d'instantané d'un cluster pendant sa refragmentation n'est pas prise en charge pour éviter toute augmentation de charge sur ce cluster.

Q : Cette opération a-t-elle un impact sur les performances du cluster ?

Le redimensionnement de cluster en ligne permet une augmentation ou une diminution sans temps d'arrêt, il reste une opération exigeante en matière de calcul et peut augmenter la latence de la connexion de votre client. Pour réduire la charge sur le cluster pendant l'opération, nous vous recommandons de suivre les bonnes pratiques (décrites dans la documentation).

Q : Comment suivre la progression d'une refragmentation en ligne ?

Il est possible de suivre une refragmentation en regardant l'état du cluster, des fragments et des nœuds. Pendant l'opération, le cluster, les fragments et les nœuds garderont le statut « en cours de modification ». De la même manière, lorsque les fragments sont créés, supprimés ou participent à la migration d'emplacements, les statuts individuels des fragments reflètent ces statuts pour indiquer la progression. De plus, le statut de l'opération bout en bout peut également être suivi grâce à l'indicateur de progression pour la refragmentation, qui montre le pourcentage d'achèvement et donne des informations sur le temps restant pour l'opération. Enfin, les messages d'événements indiquent la progression en décrivant les actions réalisées (création de fragments, migration d'emplacements, etc.) lors de cette opération.

Q : Quelle est l'opération de rééquilibrage pour le cluster ElastiCache for Redis ?

Le rééquilibrage peut être utilisé pour redistribuer les emplacements parmi les fragments existants pour obtenir une distribution uniforme. Cette opération est utile lorsqu'un cluster est créé avec une distribution des emplacements manuelle inégale ou lorsqu'une opération de dimensionnement laisse le cluster avec une distribution inégale. A supposer que les emplacements sont identiques en mémoire et en exigences E/S, la distribution uniforme d'emplacements par nombre représente un moyen simple d'équilibrer la charge sur les fragments.

Q : Comment fonctionne le balisage lors de l'augmentation d'un cluster ?

Lorsque des nœuds sont ajoutés en vue d'une augmentation d'un cluster, ces derniers portent le même type de balises, commun à tous les nœuds existants. De plus, les utilisateurs peuvent modifier les balises sur tous les nœuds et continuer d'utiliser le même balisage.

Q : Des modifications du côté du client ou de l'application sont-elles nécessaires pour utiliser le redimensionnement de cluster en ligne ?

Non. La distribution d'emplacements améliorée utilisée pour le flux de travail de redimensionnement de cluster est cohérente avec le comportement du client de cluster de Redis et ne requiert aucune modification d'application. ElastiCache conserve les points de terminaison de cluster, ce qui vous permet de continuer d'utiliser les clients existants sans la moindre modification.

Q : Quel est le coût d'utilisation du moteur Redis amélioré ?

L'utilisation du moteur Redis amélioré n'implique aucun coût supplémentaire. Comme toujours, seuls les nœuds utilisés vous seront facturés.

 


Q : Qu'apporte le chiffrement en transit d'ElastiCache for Redis ?

Le chiffrement en transit permet de chiffrer toutes les communications entre les clients et le serveur Redis ainsi qu'entre les serveurs Redis (nœuds primaires et de réplicas en lecture).

Q : Qu'apporte le chiffrement au repos d'ElastiCache for Redis ?

Le chiffrement au repos permet le chiffrement des données lors de la sauvegarde et la restauration. Les données sauvegardées et restaurées sur disque et via Amazon S3 sont chiffrées.

Q : Comment utiliser le chiffrement en transit, au repos et Redis AUTH ?

Le chiffrement en transit, au repos et Redis AUTH sont des fonctionnalités à sélectionner. Au moment de la création des clusters Redis via la console ou l'interface de ligne de commande, vous pouvez spécifier l'activation ou non du chiffrement et de Redis AUTH pour ensuite procéder au provisionnement d'un jeton d'authentification pour la communication avec le cluster Redis. Une fois le cluster configuré et le chiffrement activé, ElastiCache gère en toute transparence l'expiration et le renouvellement des certificats sans nécessiter d'actions supplémentaires de la part de l'application. De plus, les clients Redis doivent prendre en charge TLS pour que le trafic chiffré en transit soit activé.

Q : Existe-t-il un client Amazon ElastiCache for Redis que je dois utiliser lorsque j'utilise le chiffrement en transit ou au repos ?

Non. Le chiffrement en transit nécessite des clients prenant en charge TLS. La plupart des clients Redis populaires (Lettuce, Predis, go-Redis, par exemple) prennent en charge TLS avec certains paramètres de configuration. Vous devez vous assurer que le client Redis que vous choisissez est configuré pour prendre en charge TLS et continuer d'utiliser ElastiCache for Redis comme avant.

Q : Puis-je activer le chiffrement en transit et au repos sur mes clusters ElastiCache for Redis existants ?

Non. La prise en charge du chiffrement en transit et au repos n'est disponible que pour les nouveaux clusters. Il n'est pas pris en charge sur les clusters ElastiCache for Redis existants. ElastiCache for Redis version 3.2.6 est la première version à prendre en charge ces fonctionnalités.

Q : Dois-je faire quelque chose pour renouveler les certificats ?

Non. ElastiCache gère l'expiration et le renouvellement des certificats en arrière-plan. Aucune action de la part de l'utilisateur n'est requise pour la maintenance des certificats en cours.

Q : Puis-je utiliser mes certificats pour le chiffrement ?

Non. Actuellement, ElastiCache ne donne pas la possibilité d'utiliser vos certificats. ElastiCache gère en toute transparence vos certificats.

Q : Quels types d'instances sont pris en charge pour le chiffrement en transit et au repos ?

Toutes les générations d'instances actuelles sont prises en charge pour le chiffrement en transit et au repos.

Q : L'utilisation du chiffrement entraîne-t-elle des frais supplémentaires ?

L'utilisation du chiffrement n'entraîne aucuns frais supplémentaires.

 


Q : Est-ce qu'Amazon ElastiCache for Redis est éligible pour HIPAA ?

Oui. Amazon ElastiCache for Redis est un service éligible HIPAA qui a été ajouté à l'AWS Business Associate Addendum (BAA). Cela signifie que vous pouvez utiliser ElastiCache for Redis pour vous aider à traiter, entretenir et stocker des données de santé protégées (PHI) et des applications de santé d'alimentation.

Q : Que dois-je faire pour utiliser ElastiCache for Redis éligible pour HIPAA ?

Si vous disposez d'un accord de partenariat (BAA) avec AWS, vous pouvez dès à présent utiliser ElastiCache for Redi pour concevoir des applications conformes HIPAA. Si vous n'avez pas de BAA ou si vous avez d'autres questions sur l'utilisation d'AWS avec des applications conformes HIPAA, contactez-nous pour obtenir plus d'informations. Consultez la section Architecting for HIPAA Security and Compliance on Amazon Web Services pour en savoir plus sur la façon de configurer les services Amazon éligibles HIPAA pour le stockage, le traitement et le transfert des PHI.

Q : Quels programmes de conformité sont pris en charge par ElastiCache for Redis ?

ElastiCache for Redis prend en charge des programmes de conformité comme SOC 1, SOC 2, SOC 3, ISO, MTCS, C5 et HIPAA. Consultez la section Services AWS concernés par le programme de conformité pour avoir la liste actuelle des programmes de conformité pris en charge.

Q : L'utilisation des fonctionnalités de conformité entraîne-t-elle des frais supplémentaires ?

Non. Aucun frais supplémentaire ne s'applique à l'utilisation des fonctionnalités de conformité.