Architecting resilient authentication with Amazon Cognito multi-Region replication

What it is

A detailed architectural and operational guide for Amazon Cognito multi-Region replication (MRR), published on the AWS Security Blog. It goes beyond the feature overview to specify the exact mechanics of replica user pools, the two supported OIDC issuer URL formats, and concrete failover configuration using Route 53, Application Recovery Controller (ARC), and AWS Fault Injection Service (FIS).

How it works

Cognito MRR creates a replica user pool in a second Region sharing the same user pool ID; the primary remains authoritative for writes, while the replica supports sign-in, token generation/revocation, and read-only config/user lookups. Write operations against the replica return OperationNotEnabledException (SDK) or an "Action temporarily unavailable" error (managed login). JWTs and refresh tokens are interoperable across Regions. Two issuer URL formats exist: the original https://cognito-idp.<region>.amazonaws.com/<userpool_id> (Region-pinned, OIDC discovery/JWKS tied to one Region) and the new multi-Region "updated" issuer https://issuer-cognito-idp.<region>.amazonaws.com/<userpool_id> (discovery/JWKS available regardless of which Region is active). Issuer type can be changed at any time; newly issued/refreshed tokens pick up the current format, while old tokens remain valid until expiry.

Preconditions / Affected

• User pool must be on the Essentials or Plus feature plan.
• MRR requires a symmetric multi-Region AWS KMS customer managed key (only one replica key needed, since MRR supports a single additional replica Region).
• TOTP MFA is not supported in replica user pools — users on TOTP must authenticate via the primary Region only.
• Replica Regions get fresh default service quotas; previously raised quota increases in the primary do not carry over.
• Dependent regional services (Lambda triggers, WAF web ACLs, SNS origination identities/spending limits, SES verified domains, CloudWatch alarms) must each be independently configured in the replica Region — none of this is automatic.

What to do

• Scope the KMS key policy to the user pool using kms:EncryptionContext:aws:cognito-idp:<userpool-arn>.
• Adopt the updated issuer type; if using aws-jwt-verify, upgrade to v5.2.1 or later to support it.
• If you can't migrate off the original issuer (e.g., third parties hard-code the iss format), implement a JWKS caching layer that respects Cache-Control headers so token verification survives a regional outage.
• Use infrastructure-as-code (CloudFormation/CDK) to keep Lambda triggers, WAF ACLs, SNS, and SES configs identical across primary/replica, and monitor for drift.
• Build the Route 53 health check as: a CloudWatch Synthetics canary exercising a real auth flow (e.g., /oauth2/token client-credentials request or AdminInitiateAuth) → a CloudWatch alarm on SuccessPercent (e.g., alarm below 90% for 3 consecutive periods) → a Route 53 health check tied to that alarm → attach via UpdateUserPoolDomain.
• For full-stack failover (Lambda triggers hitting regional DynamoDB tables, regional event buses, etc.), use ARC's routing controls, readiness checks, and Region switch to fail over Cognito together with dependent infrastructure as one recovery group.
• Test failover by enabling "Invert health check status" in the Route 53 console during a maintenance window, validating sign-in/token refresh/federation against the replica, then disabling the inversion.
• Graduate to AWS FIS experiments that block network access or inject latency into primary-Region Cognito dependencies, with FIS stop conditions as guardrails.

Caveats

The post explicitly scopes itself to architecture patterns and assumes familiarity with MRR basics from two prior linked posts — it does not re-explain baseline MRR setup. It does not give concrete RTO/RPO numbers, deferring to a separate "Establishing RPO and RTO Targets" post for that methodology.