Cognito Multi-Region: Migrating Identity to High Availability

In financial systems, the Cognito User Pool carries far more than credentials. It stores custom attributes that map to risk profiles, groups that control downstream authorization scopes, and Lambda triggers that execute business logic — CPF validation, claim enrichment with compliance data, audit logging for regulatory requirements. When that pool fails in a Region, the impact is not just "users can't log in": the entire authorization chain breaks, APIs protected by Cognito Authorizer in API Gateway return 401, and onboarding flows get stuck in inconsistent states.

The pattern I saw frequently before native replication was a combination of two independent pools with eventual synchronization via EventBridge and Lambda — what we called internally a "Cognito Bridge". The problem is that this pattern has at least three blind spots: race conditions during password synchronization (the bcrypt hash changes on every reset), custom attributes that silently diverge between regions, and Lambda triggers that need to be kept in manual sync. The operational cost was high and confidence in consistency was low. Native replication solves exactly that layer of accidental complexity.

The target architecture that emerges from this migration has three distinct layers. The first is the identity data plane: primary Cognito User Pool in us-east-1 with an active replica in us-west-2, both using the same KMS MRK, with synchronous replication of users, groups, and credentials managed by the service. The second is the trigger execution plane: Lambda functions mirrored in both regions, with access to DynamoDB Global Tables (configured with tables in both regions and automatic replication), Secrets Manager with secret replication enabled, and RDS Proxy pointing to Aurora Global Database with a promotable read replica.

The third layer — frequently neglected — is the identity observability plane. Critical metrics to monitor in both regions: SignInSuccesses, SignInThrottles, TokenRefreshSuccesses, and the custom metric IdentityPlaneRPO that measures replication lag in seconds. The latter should have an SLO of < 30 seconds RPO under normal conditions, with an alarm at 60 seconds and PagerDuty at 120 seconds. Cross-region observability is implemented via CloudWatch Cross-Account Cross-Region dashboards — a single panel that aggregates identity metrics from both regions, with automatic annotations when failover is detected.

A detail that frequently escapes multi-Region Cognito migration discussions is JWT token behavior after failover. Tokens issued by the primary pool are signed with the primary pool's RSA key — the primary pool's JWKS endpoint (https://cognito-idp.<region>.amazonaws.com/<pool-id>/.well-known/jwks.json) is the source of truth for validation. After failover to the replica, the replica pool has its own JWKS endpoint.

This creates a transition window: tokens issued before failover, still valid by expiration time (typically 1h for access tokens), need to be validated against the primary pool's JWKS — which may be unavailable precisely because we are in failover. The correct solution is to implement token validation with JWKS caching at multiple layers: the API Gateway Lambda Authorizer must cache public keys from both regions and attempt validation against both JWKS before rejecting the token. The cache should have a 10-minute TTL with asynchronous refresh — never fetch JWKS at request time, as this creates a synchronous cross-region dependency.

For systems that use long-lived tokens (refresh tokens with 30-day validity are common in mobile banking), the token replication strategy is even more critical. Cognito replicates refresh tokens as part of session replication — but the app client ID and client secret need to be identical in both pools (or managed via Secrets Manager with replication enabled) for the refresh flow to work in the secondary region without forcing user re-authentication.

In regulated financial institutions in Brazil — subject to BACEN, LGPD, and for open finance, Joint Resolution 1 — the identity plane has governance requirements that go beyond technical availability. Cognito stores personal data (name, email, CPF in a custom attribute) and authentication data — both classified as sensitive data under LGPD. Multi-Region replication immediately raises the question of data residency: if the replica is in us-west-2 (Oregon), data of Brazilian citizens is being replicated outside Brazil.

The architectural answer to this is not to avoid replication, but to document it properly in the Record of Processing Activities (ROPA) and ensure that security controls are equivalent in both regions. Encryption with KMS MRK satisfies the requirement that data at rest be encrypted with keys under organizational control — as long as the key policy does not allow third-party access. CloudTrail with replication to S3 in both regions (with Object Lock for immutability) ensures the audit trail required by BACEN for authentication systems.

A frequently neglected point: the Pre-Token-Generation trigger that adds claims to the JWT is, in practice, an extension of the authorization plane. If this trigger fails silently (timeout, Lambda throttle), the token is issued without the compliance claims — and downstream, APIs that depend on those claims for authorization decisions make incorrect decisions. Configure TokenValidityUnits and implement mandatory claim validation in the API Gateway Lambda Authorizer as an additional line of defense.