Great question—this is a super common pain point with AWS Cognito since there’s no native cross-region replication built specifically for disaster recovery. Below are several proven approaches to replicate your user pool across regions while keeping the end-user experience smooth and seamless:

方案1：实时用户数据同步（Lambda + Cognito触发器） #

This is the most straightforward approach for keeping two user pools in sync in near-real time. Here’s how to set it up:

• Configure Cognito triggers: Enable post-registration, user-update, and user-delete triggers on your primary user pool. Each trigger fires a Lambda function whenever a user is created, updated, or deleted.
• Build the sync Lambda: Write a Lambda function (Python, Node.js, etc.) that takes the user event data and replicates the action to the secondary region’s user pool using the AWS SDK. Example snippet:

  import boto3
  
  def lambda_handler(event, context):
      target_cognito = boto3.client('cognito-idp', region_name='us-west-2')
      user_attrs = event['request']['userAttributes']
      username = user_attrs['email'] or event['userName']
  
      # Handle user creation
      if event['triggerSource'] == 'PostConfirmation_ConfirmSignUp':
          target_cognito.admin_create_user(
              UserPoolId='TARGET_USER_POOL_ID',
              Username=username,
              UserAttributes=[
                  {'Name': 'email', 'Value': user_attrs['email']},
                  {'Name': 'given_name', 'Value': user_attrs.get('given_name', '')}
                  # Add all required attributes here
              ],
              MessageAction='SUPPRESS'  # Skip welcome email if primary already sent it
          )
      # Handle user updates
      elif event['triggerSource'] == 'PostAuthentication_Authentication':
          target_cognito.admin_update_user_attributes(
              UserPoolId='TARGET_USER_POOL_ID',
              Username=username,
              UserAttributes=[
                  {'Name': 'last_login', 'Value': user_attrs['last_login']}
                  # Sync all updated attributes
              ]
          )
      # Handle user deletion
      elif event['triggerSource'] == 'UserDelete_UserDeleted':
          target_cognito.admin_delete_user(
              UserPoolId='TARGET_USER_POOL_ID',
              Username=username
          )
      return event
  

• Key considerations:
  • Password sync: Cognito doesn’t expose raw passwords, so for failover scenarios, you can either let users reset passwords in the secondary pool or pre-sync temporary passwords (note: password hashes are pool-specific, so direct hash sync won’t work).
  • Conflict resolution: Set a clear priority (e.g., primary pool changes always override secondary) to avoid data inconsistencies.

方案2：定期全量导出 + 实时增量同步 #

Perfect for setting up a secondary pool from scratch and keeping it updated:

• Bulk export/import: Use Cognito’s built-in user export tool to dump all users from the primary pool to an S3 bucket. Then use the Cognito import tool to load this data into the secondary pool. Ensure both pools have identical configurations (attributes, MFA rules, password policies) to avoid import failures.
• Layer on real-time sync: Add the Lambda trigger setup from方案1 to handle new/updated users after the initial bulk import. This keeps the secondary pool current without repeated full exports.

方案3：多区域路由 + 同步用户池（无缝故障切换） #

Pair sync with a routing layer to make failover invisible to users:

• Mirror pool configurations: Copy all settings from the primary to the secondary pool—app clients, domain names, callback URLs, OAuth rules, etc. This ensures the login flow works identically when users are routed to the secondary pool.
• Route traffic with Route 53/CloudFront: Use Route 53 health checks to monitor the primary Cognito endpoint. If it fails, Route 53 automatically routes users to the secondary region’s Cognito domain. CloudFront origin groups work similarly for more granular traffic control.
• Session continuity: Cognito tokens are region-specific, so users will need to re-authenticate after failover. To reduce friction, you can add a cross-region session store (like Redis with global replication) to persist user sessions, though this adds extra complexity.

方案4：自定义用户存储（DynamoDB全局表） #

If you’re open to modifying your auth flow, this avoids Cognito’s native limitations entirely:

• Switch to Cognito custom authentication: Disable Cognito’s native user storage and use its custom auth triggers to pull user data from a DynamoDB global table (which auto-replicates across regions).
• Build custom auth logic: Implement triggers like DefineAuthChallenge, CreateAuthChallenge, and VerifyAuthChallengeResponse to handle login, MFA, and password resets using the DynamoDB table as your single source of truth.
• Benefits: DynamoDB handles cross-region replication automatically, so no custom sync code is needed. Users can authenticate against any region’s Cognito endpoint, and their data is always available.

内容的提问来源于stack exchange，提问作者Pablo Arriola