Multi-Region replicación para grupos de usuarios

Con la replicación multirregional (MRR), puede crear una réplica de un grupo de usuarios adicional Región de AWS para proporcionar capacidades de continuidad empresarial y recuperación ante desastres para su infraestructura de autenticación. Con el MRR, los usuarios registrados pueden seguir autenticándose con sus aplicaciones incluso si pierde la conectividad con los recursos de una región, lo que garantiza que sus aplicaciones permanezcan disponibles.

Al configurar MRR, Amazon Cognito crea grupos de usuarios independientes con un ID de grupo de usuarios compartido. Cada grupo de usuarios de réplica aloja los servicios de autenticación para un directorio de usuarios compartido. El grupo de usuarios principal sirve como fuente autorizada para la configuración administrativa y las operaciones de escritura en el directorio de usuarios, como el restablecimiento de contraseñas y el registro de usuarios. Los grupos de usuarios secundarios no pueden crear usuarios, heredan la mayoría de las configuraciones del grupo de usuarios principal y, en estado de conmutación por error, pueden gestionar operaciones de autenticación como el inicio de sesión de los usuarios y la generación de tokens.

importante

Multi-Region La replicación no está disponible para todos los grupos de usuarios en este momento. Multi-Region la replicación requiere la infraestructura moderna de Amazon Cognito con capacidades y escalabilidad mejoradas. Algunos grupos de usuarios aún se encuentran en una infraestructura anterior y se actualizarán AWS a la nueva infraestructura, lo que desbloqueará esta función. En la consola de Amazon Cognito, los grupos de usuarios aptos muestran opciones de configuración de replicación multirregional y los grupos no aptos muestran mensajes de excepción. Para obtener más información, consulte Amazon Cognito que desbloquea capacidades avanzadas con una infraestructura de próxima generación en el blog de seguridad. AWS

Lo que debe saber sobre la replicación multirregional

• Multi-Region la replicación tiene costos adicionales independientes y requiere que su grupo de usuarios esté inscrito en el plan de funciones Essentials o Plus. No puedes habilitar el MRR en grupos de usuarios con el plan de funciones Lite.

• Debe configurar su grupo de usuarios con una clave gestionada por el cliente para varias regiones AWS KMS antes de habilitar la replicación. La clave debe estar disponible en todos los Regiones de AWS que tengan réplicas de grupos de usuarios. Para obtener más información, consulte Cifrado de datos.

• Su grupo de usuarios debe utilizar un emisor de OIDC multirregional para garantizar una validación uniforme de los tokens en todas las regiones. Para obtener más información, consulte Grupos de usuarios de Amazon Cognito como emisor de OIDC.

• Los nuevos grupos de usuarios secundarios comienzan en el estado. INACTIVE Revise y configure los ajustes regionales antes de activar el grupo de usuarios para su uso en producción.

• Las configuraciones regionales pueden diferir entre las réplicas. Puede configurar los siguientes ajustes de forma independiente en las réplicas. Todos los demás ajustes se configuran en el grupo de usuarios principal y se sincronizan automáticamente con el secundario.

  • Configuración del correo electrónico

  • Configuración del correo electrónico para las notificaciones de protección contra amenazas

  • Configuración de SMS

  • Disparadores Lambda

  • Tags

  • Configuración de exportación de registros

  • AWS WAF ACL web

• La replicación de datos entre regiones puede provocar breves retrasos. El grupo de usuarios principal sincroniza la configuración y las actualizaciones del directorio de usuarios con el secundario y, en última instancia, este proceso es coherente.

Limitaciones de la replicación multirregional

• No puede generar nuevos usuarios en grupos de usuarios secundarios, ya sea mediante el registro o mediante la creación por parte del administrador. Los nuevos usuarios federados solo pueden iniciar sesión en un grupo de usuarios secundario en estado de conmutación por error si ya han iniciado sesión en el grupo de usuarios principal.

• Los usuarios no pueden restablecer sus contraseñas ni modificar sus perfiles en los grupos de usuarios secundarios. En estado de conmutación por error, deshabilite estas operaciones en la interfaz de usuario y haga que estén disponibles después de que la comprobación de estado restablezca el acceso al grupo de usuarios principal.

• Puede tener como máximo una réplica secundaria en una región adicional por directorio de usuarios. Cualquier grupo de usuarios puede tener una réplica secundaria.

• El MFA TOTP no se admite en las réplicas secundarias. Los usuarios con el MFA TOTP configurado deben autenticarse cuando el grupo de usuarios de la región principal atienda las solicitudes.

• El recuento de intentos de autenticación mediante contraseña antes del bloqueo no se sincroniza en todas las regiones. Cada réplica mantiene su propio recuento de intentos de autenticación fallidos.

• Solo puede configurar la conmutación por error automática de grupos de usuarios de varias regiones con un dominio personalizado.

Configuración de la replicación multirregional

Antes de poder habilitar la replicación multirregional, asegúrese de que su grupo de usuarios cumpla los requisitos previos: el plan de funciones Essentials o Plus, la clave KMS administrada por el cliente para varias regiones y la configuración del emisor OIDC para varias regiones.

Consola de administración de AWS

Para configurar la replicación multirregional para un grupo de usuarios

1. Inicie sesión en la consola de Amazon Cognito.

2. Elija User pools (Grupos de usuarios).

3. Elija un grupo de usuarios existente de la lista o cree un grupo de usuarios nuevo.

4. Elija la pestaña Settings.

5. En el menú de navegación de la izquierda, elija Multi-Regionla replicación.

6. Elija Crear un grupo de usuarios de réplica.

7. En Región, seleccione la ubicación Región de AWS en la que desea crear el grupo de usuarios de réplica.

8. Revise el resumen de la configuración y elija Crear réplica.

9. Una vez creada la réplica, revise los ajustes de configuración regional en la tabla de comparación. Configure los ajustes específicos de la región, como la configuración del correo electrónico, los ajustes de SMS o los activadores Lambda, según sea necesario para su región de réplica.

10. Para configurar una comprobación de estado de Route 53 para su dominio, vaya al menú de servicios de dominio, edite o añada un dominio personalizado y configure un ID de comprobación de estado de Route 53.

11. Cuando esté listo para usar la réplica para el tráfico de producción, cambie el estado de la réplica de Inactiva a Activa.

API

Para crear un grupo de usuarios de réplica, utilice la CreateUserPoolReplicaoperación. En el siguiente ejemplo, se crea una réplica en la us-west-2 región para un grupo de usuarios principal enus-east-1.

{
   "UserPoolId": "us-east-1_EXAMPLE",
   "RegionName": "us-west-2",
   "UserPoolTags": {
      "Environment": "Production",
      "Application": "MyApp"
   }
}

La respuesta incluye la información de la réplica:

{
   "Replica": {
      "RegionName": "us-west-2",
      "UserPoolArn": "arn:aws:cognito-idp:us-west-2:111122223333:userpool/us-east-1_EXAMPLE",
      "Status": "PENDING_CREATE",
      "Role": "SECONDARY"
   }
}

También debe configurar su dominio para la conmutación por error. Configure un chequeo de estado en Route 53 y aplíquelo a su dominio en una UpdateUserPoolDomainsolicitud:

{
   "CustomDomainConfig": { 
      "CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
   },
   "Domain": "auth.example.com",
   "ManagedLoginVersion": 2,
   "Routing": {
      "Failover": {
         "SecondaryRegion": "us-west-2",
         "PrimaryRoute53HealthCheckId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
      }
   },
   "UserPoolId": "ca-central-1_EXAMPLE"
}

Para activar la réplica para su uso en producción, utilice la siguiente UpdateUserPoolReplicaoperación:

{
   "UserPoolId": "us-east-1_EXAMPLE",
   "RegionName": "us-west-2",
   "Status": "ACTIVE"
}

La respuesta confirma el estado de la réplica actualizada:

{
   "Replica": {
      "RegionName": "us-west-2",
      "UserPoolArn": "arn:aws:cognito-idp:us-west-2:111122223333:userpool/us-east-1_EXAMPLE",
      "Status": "ACTIVE",
      "Role": "SECONDARY"
   }
}

Conmutación por error en grupos de usuarios de varias regiones

La conmutación por error entre dos Regiones de AWS se puede producir para el inicio de sesión gestionado, el inicio de sesión federado y el uso directo de la API con su grupo de usuarios. El inicio de sesión administrado y la federación requieren un dominio personalizado configurado con su grupo de usuarios principal. No puede configurar un dominio personalizado diferente con grupos de usuarios de réplica.

Conmutación por error para el inicio de sesión gestionado, la federación y la autorización de máquina a máquina

La conmutación por error está disponible cuando el grupo de usuarios principal tiene un dominio personalizado. Cuando ambos grupos de usuarios tienen un dominio de prefijo, puede probar manualmente las operaciones en la réplica secundaria accediendo directamente al dominio de prefijo secundario. Los dominios personalizados se pueden ofrecer desde la réplica y la región principales o adicionales.

Se requiere un dominio personalizado porque es el punto final que sirve a los recursos de OAuth 2.0, como los puntos finales de autorización y token, y gestiona la respuesta del IdP de la federación de terceros, incluidos OIDC, SAML y los proveedores sociales.

Para configurar la conmutación por error, configure una comprobación de estado en Route 53. Usted es responsable de lo que determina el estado de esta comprobación de estado. La comprobación de estado no está directamente asociada al registro CNAME de DNS de tu dominio personalizado. Sin embargo, es el indicador que determina si el tráfico de tu dominio personalizado se dirige a tu grupo de usuarios principal o réplica.

El registro DNS de su dominio personalizado puede usar Route 53 o cualquier proveedor de DNS externo. Asegúrese de tener un registro CNAME válido en su proveedor de DNS que apunte a su alias de destino, que es una CloudFront distribución. Puede encontrar el destino del alias en la página del dominio de la consola de Amazon Cognito.

Cuando la comprobación de estado se encuentra en mal estado, Amazon Cognito muestra páginas de inicio de sesión gestionadas y operaciones de autenticación para el dominio personalizado desde el grupo de usuarios de réplica secundario. Cuando la comprobación de estado pasa a un estado correcto, Amazon Cognito comienza a redirigir el tráfico de vuelta a la réplica principal.

Cada grupo de usuarios tiene su propio dominio de prefijo, tal y como se indica a continuación. Region-isolated Aún puede llamar directamente a estos puntos finales para gestionar la autenticación. Sin embargo, si la federación se configura con un tercero IdPs, debe haber dos configuraciones de aplicación para cada punto final de prefijo. Como práctica recomendada, utilice un dominio personalizado para garantizar que Amazon Cognito gestione automáticamente el enrutamiento hacia y desde el inicio de sesión gestionado en función del estado del chequeo de estado de Route 53.

Para actualizar el ID del chequeo de estado en la consola

1. Navegue hasta su grupo de usuarios en la consola de Amazon Cognito.

2. Seleccione Dominio en la sección Marca del menú.

3. En la sección Dominio personalizado, elige la opción de edición y selecciona Editar conmutación por error multirregional.

4. Active la opción Habilitar la conmutación por error en varias regiones.

5. Seleccione su ID de chequeo de estado de Route 53 entre los chequeos de estado disponibles.

6. Seleccione Save changes (Guardar cambios).

Conmutación por error para las API y los SDK de Amazon Cognito

Si usa las API o los SDK de Amazon Cognito, no se utiliza un dominio personalizado y su aplicación es responsable de dirigir el tráfico al punto de enlace regional del servicio Amazon Cognito para gestionar la autenticación y otras llamadas a la API.

Si solo tiene una interfaz de aplicación que utiliza un cliente público, como una aplicación de una sola página (SPA) o una aplicación móvil, su aplicación debe ser dinámica para enrutar las llamadas a la API en consecuencia. Considere la posibilidad de utilizar un backend de aplicaciones sin servidor para determinar por qué región debería empezar la autenticación con Amazon Cognito.

Si tiene una aplicación con un backend, aquí puede determinar la lógica para determinar con qué grupo de usuarios debe autenticarse.

Si utiliza tanto puntos de enlace de inicio de sesión gestionados como API, puede utilizar la misma comprobación de estado de Route 53 como indicador para que su aplicación decida en qué región deben realizarse las llamadas de la API a Amazon Cognito.