Guidance Required for Cognito DR Architecture with Full Functionality During Regional Outage

Your observation about MRR is correct, and AWS documents the limitation explicitly. But the conclusion you're drawing from it — that independent pools with synchronisation is the alternative — leads somewhere worse. Let me address that first, because it's the most important part.

Independent user pools cannot work for your requirement

Cognito does not expose password hashes. There is no API to extract them and no mechanism to write them into another pool. This isn't a gap in tooling; it's deliberate.

The consequence: you can synchronise usernames, attributes, and group memberships between two independent pools, but you cannot synchronise credentials. Users failing over to the DR pool would be unable to sign in at all — a total outage of authentication, not a degradation of it.

The usual workaround is the UserMigration trigger, which migrates a user lazily on their first sign-in by validating against the source directory. That requires the source directory to be reachable, which by definition it isn't during a regional outage.

MFA secrets have the same problem. So do refresh tokens issued by the primary pool.

So independent pools plus synchronisation is strictly worse than MRR, not better. Worth ruling out before you invest further in evaluating it.

What MRR actually does and doesn't cover

Replicated automatically: user profiles, credentials, MFA secrets, and pool configuration. Both regional endpoints stay active at all times, and tokens issued by either region are recognised by the other — so active sessions survive a failover without forced password resets.

The limitation you noticed is real and stated plainly in AWS's own announcement: while authentication continues without interruption, operations like new user registration or profile updates are not available during failover. The docs put it structurally — the primary pool is the authoritative source for administrative configuration and write operations such as password resets and user sign-up; secondary pools cannot create users.

This is architectural, not a configuration gap. There is no setting that makes a replica accept writes.

Lambda triggers

Trigger configuration replicates, but the functions don't. AWS's guidance is that when you use Lambda functions for custom authentication flows or SMS/email notifications, you must deploy and configure those resources in the new Region yourself. The same applies to log streaming and WAF.

The failure mode here deserves emphasis: a failover to a region without matching triggers skips custom authentication logic silently — MFA prompts, pre-token enrichment, post-authentication hooks — without obvious errors. That's a security regression that won't surface in a smoke test.

Audit your full trigger list and deploy every function in the secondary region before enabling replication.

Answering your actual question

There is no AWS-native architecture that delivers signup, forgot-password, and profile updates during a complete primary-region outage while Cognito remains the credential store. If "no feature degradation" is a hard requirement, Cognito cannot meet it.

The architecturally honest options:

Accept partial degradation. MRR keeps sign-in, token issuance, MFA, and session continuity working. Signup and password reset queue or fail gracefully during the outage window. For most applications this is the right trade — existing users keep working; new registrations wait. Design the UI to communicate this rather than erroring opaquely.

Move the credential store outside Cognito. Federate Cognito to an external OIDC/SAML IdP that you run multi-region (or a SaaS IdP with its own availability guarantees). Cognito then holds no passwords, and your DR problem becomes the IdP's DR problem — which you control. This is the only route to genuine full functionality, and it's a significant re-architecture.

Replace Cognito. If auth is critical enough to justify the requirement, a self-managed multi-region IdP or a third-party provider with a contractual multi-region SLA is the direct answer.

Practical checks before you go further

Confirm MRR is available on your pool. It requires the modern Cognito infrastructure; some existing pools are still on the previous infrastructure and will be upgraded by AWS before the feature unlocks. Eligible pools show the configuration options in the console; ineligible ones show an exception message. Check ap-south-1 specifically — verify the region pair you need is supported.

Prerequisites: Essentials or Plus feature plan (not Lite), and a multi-region customer-managed KMS key configured before you enable replication.

Failover mechanics: you configure a Route 53 health check and set the Routing field on your user pool domain, with SecondaryRegion and PrimaryRoute53HealthCheckId. You define what constitutes unhealthy. Note that you can't configure a different custom domain on the replica.

IaC gap: MRR is configurable via API/CLI/SDK but not fully through CloudFormation yet. Expect post-deployment scripts or a Lambda-backed custom resource.

Reframing for your stakeholders

The requirement as written ("no feature degradation") is likely stricter than the business actually needs. It's worth separating:

• Existing users must be able to sign in — MRR delivers this
• New users must be able to register during a regional outage — no Cognito-based design delivers this

If the second is genuinely non-negotiable, the decision is about replacing or federating away from Cognito, not about configuring it differently. Getting that clarified early will save considerable evaluation effort.