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.
Multi-Region réplication pour les groupes d'utilisateurs
Avec la réplication multirégionale (MRR), vous pouvez créer un pool d'utilisateurs dupliqué dans un groupe d'utilisateurs supplémentaire Région AWS afin de fournir des fonctionnalités de continuité des activités et de reprise après sinistre pour votre infrastructure d'authentification. Avec MRR, les utilisateurs enregistrés peuvent continuer à s'authentifier auprès de vos applications même lorsque vous perdez la connectivité aux ressources d'une région, garantissant ainsi la disponibilité de vos applications.
Lorsque vous configurez MRR, Amazon Cognito crée des groupes d'utilisateurs distincts avec un ID de groupe d'utilisateurs partagé. Chaque groupe d'utilisateurs répliqué héberge des services d'authentification pour un annuaire d'utilisateurs partagé. Le groupe d'utilisateurs principal fait office de source faisant autorité pour la configuration administrative et les opérations d'écriture d'annuaires d'utilisateurs, telles que la réinitialisation des mots de passe et l'inscription des utilisateurs. Les groupes d'utilisateurs secondaires ne peuvent pas créer d'utilisateurs, héritent de la plupart des paramètres du groupe d'utilisateurs principal et, en cas de basculement, peuvent gérer des opérations d'authentification telles que la connexion des utilisateurs et la génération de jetons.
Important
Multi-Region la réplication n'est pas disponible pour tous les groupes d'utilisateurs pour le moment. Multi-Region la réplication nécessite l'infrastructure moderne Amazon Cognito dotée de fonctionnalités et d'évolutivité améliorées. Certains groupes d'utilisateurs utilisent toujours une infrastructure précédente et seront mis à niveau AWS vers la nouvelle infrastructure, qui débloquera cette fonctionnalité. Dans la console Amazon Cognito, les groupes d'utilisateurs éligibles affichent les options de configuration de réplication multirégionale, tandis que les groupes non éligibles affichent des messages d'exception. Pour plus d'informations, consultez Amazon Cognito qui débloque des fonctionnalités avancées grâce à une infrastructure de nouvelle génération
Ce qu'il faut savoir sur la réplication multirégionale
-
Multi-Region la réplication entraîne des coûts supplémentaires distincts et nécessite que votre groupe d'utilisateurs souscrive au plan de fonctionnalités Essentials ou Plus. Vous ne pouvez pas activer le MRR sur les groupes d'utilisateurs avec le plan de fonctionnalités Lite.
-
Vous devez configurer votre groupe d'utilisateurs à l'aide d'une clé gérée par le client dans plusieurs régions AWS KMS avant d'activer la réplication. La clé doit être disponible dans tous ceux Régions AWS qui possèdent des répliques de groupes d'utilisateurs. Pour de plus amples informations, veuillez consulter Chiffrement des données.
-
Votre groupe d'utilisateurs doit utiliser un émetteur OIDC multirégional pour garantir une validation cohérente des jetons dans toutes les régions. Pour de plus amples informations, veuillez consulter Groupes d'utilisateurs Amazon Cognito en tant qu'émetteur OIDC.
-
Les nouveaux groupes d'utilisateurs secondaires démarrent dans
INACTIVEcet État. Vérifiez et configurez les paramètres régionaux avant d'activer le groupe d'utilisateurs pour une utilisation en production. -
Les configurations régionales peuvent différer d'une réplique à l'autre. Vous pouvez configurer les paramètres suivants indépendamment dans les répliques. Tous les autres paramètres sont définis dans le groupe d'utilisateurs principal et automatiquement synchronisés avec le groupe secondaire.
-
Configuration du courrier électronique
-
Configuration du courrier électronique pour les notifications de protection contre les menaces
-
Configuration des SMS
-
Déclencheurs Lambda
-
Étiquettes
-
Configuration de l'exportation des journaux
-
AWS WAF ACL Web
-
-
La réplication des données entre les régions peut entraîner de brefs retards. Le groupe d'utilisateurs principal synchronise les paramètres et les mises à jour du répertoire utilisateur avec le groupe secondaire, et ce processus est finalement cohérent.
Limites de la réplication multirégionale
-
Vous ne pouvez pas générer de nouveaux utilisateurs dans des groupes d'utilisateurs secondaires, que ce soit par inscription ou par création d'un administrateur. Les nouveaux utilisateurs fédérés ne peuvent se connecter à un groupe d'utilisateurs secondaire en état de basculement que s'ils se sont déjà connectés au groupe d'utilisateurs principal.
-
Les utilisateurs ne peuvent pas réinitialiser leur mot de passe ni modifier leur profil dans les groupes d'utilisateurs secondaires. En cas de basculement, désactivez ces opérations dans l'interface utilisateur et rendez-les disponibles une fois que votre bilan de santé aura rétabli l'accès au groupe d'utilisateurs principal.
-
Vous pouvez avoir au plus une réplique secondaire dans une région supplémentaire par annuaire d'utilisateurs. Tout groupe d'utilisateurs peut disposer d'une réplique secondaire.
-
Le MFA TOTP n'est pas pris en charge dans les répliques secondaires. Les utilisateurs dont l'authentification MFA TOTP est configurée doivent s'authentifier lorsque le groupe d'utilisateurs de la région principale traite les demandes.
-
Le nombre de tentatives d'authentification par mot de passe avant le verrouillage n'est pas synchronisé entre les régions. Chaque réplique conserve son propre nombre de tentatives d'authentification infructueuses.
-
Vous ne pouvez configurer le basculement automatique de groupes d'utilisateurs multirégionaux qu'avec un domaine personnalisé.
Configuration de la réplication multirégionale
Avant de pouvoir activer la réplication multirégionale, assurez-vous que votre groupe d'utilisateurs répond aux conditions requises : plan de fonctionnalités Essentials ou Plus, clé KMS gérée par le client multirégion et configuration de l'émetteur OIDC multirégional.
Basculement dans des groupes d'utilisateurs multirégionaux
Un basculement entre les deux Régions AWS peut se produire pour la connexion gérée, la connexion fédérée et l'utilisation directe de l'API avec votre groupe d'utilisateurs. La connexion gérée et la fédération nécessitent un domaine personnalisé configuré avec votre groupe d'utilisateurs principal. Vous ne pouvez pas configurer un autre domaine personnalisé avec des groupes d'utilisateurs répliqués.
Basculement pour la gestion de la connexion, de la fédération et de l'autorisation machine à machine
Le basculement est disponible lorsque votre groupe d'utilisateurs principal possède un domaine personnalisé. Lorsque les deux groupes d'utilisateurs possèdent un domaine de préfixe, vous pouvez tester manuellement les opérations sur le réplica secondaire en accédant directement au domaine de préfixe secondaire. Les domaines personnalisés peuvent être servis à partir de la réplique et de la région principales ou supplémentaires.
Un domaine personnalisé est requis car c'est le point de terminaison qui dessert les ressources OAuth 2.0, telles que les points de terminaison d'autorisation et de jeton, et gère la réponse de l'IdP provenant de fédérations tierces, notamment OIDC, SAML et des fournisseurs sociaux.
Pour configurer le basculement, configurez un contrôle de santé dans Route 53. Vous êtes responsable de ce qui détermine l'état de ce bilan de santé. Le bilan de santé n'est pas directement associé à votre enregistrement DNS CNAME pour votre domaine personnalisé. Toutefois, c'est l'indicateur qui détermine si le trafic vers votre domaine personnalisé est acheminé vers votre groupe d'utilisateurs principal ou vers votre groupe d'utilisateurs répliqués.
L'enregistrement DNS de votre domaine personnalisé peut utiliser Route 53 ou un fournisseur DNS tiers. Assurez-vous de disposer d'un enregistrement CNAME valide dans votre fournisseur DNS pointant vers votre alias cible, qui est une CloudFront distribution. Vous trouverez l'alias cible sur la page Domaine de la console Amazon Cognito.
Lorsque le bilan de santé ne fonctionne pas correctement, Amazon Cognito propose des pages de connexion gérées et des opérations d'authentification pour le domaine personnalisé à partir du pool d'utilisateurs de la réplique secondaire. Lorsque le bilan de santé est rétabli, Amazon Cognito commence à rediriger le trafic vers le réplica principal.
Chaque groupe d'utilisateurs possède son propre domaine de préfixe, en l'état actuel des Region-isolated choses. Vous pouvez toujours appeler directement ces points de terminaison pour gérer l'authentification. Toutefois, si la fédération est configurée avec un tiers IdPs, il doit y avoir deux configurations d'application pour chaque point de terminaison préfixe. Il est recommandé d'utiliser un domaine personnalisé pour garantir qu'Amazon Cognito gère automatiquement le routage vers et depuis la connexion gérée en fonction de l'état du bilan de santé de Route 53.
Pour mettre à jour l'identifiant du bilan de santé dans la console
-
Accédez à votre groupe d'utilisateurs dans la console Amazon Cognito.
-
Dans le menu, sélectionnez Domaine sous Branding.
-
Dans la section Domaine personnalisé, choisissez l'option de modification, puis sélectionnez Modifier le basculement multirégional.
-
Activez l'option Activer le basculement multirégional.
-
Sélectionnez votre identifiant de bilan de santé Route 53 parmi les bilans de santé disponibles.
-
Sélectionnez Enregistrer les modifications.
Failover pour les API et SDK Amazon Cognito
Si vous utilisez les API ou les SDK Amazon Cognito, aucun domaine personnalisé n'est utilisé et votre application est chargée d'acheminer le trafic vers le point de terminaison régional du service Amazon Cognito afin de gérer l'authentification et les autres appels d'API.
Si vous ne disposez que d'une interface d'application utilisant un client public, telle qu'une application monopage (SPA) ou une application mobile, votre application doit être dynamique pour acheminer les appels d'API en conséquence. Envisagez un backend d'application sans serveur pour déterminer par quelle région l'authentification avec Amazon Cognito doit commencer.
Si vous avez une application dotée d'un backend, la logique permettant de déterminer le groupe d'utilisateurs auprès duquel s'authentifier peut être déterminée ici.
Si vous utilisez à la fois des points de terminaison de connexion gérés et des API, vous pouvez utiliser le même bilan de santé Route 53 comme indicateur permettant à votre application de décider de la région pour laquelle les appels d'API à Amazon Cognito doivent être effectués.
