Cognito Finally Grew a Backup Plan: Multi-Region Replication Is Here

For years, Amazon Cognito had one quiet weakness that kept architects up at night. It was a regional service. If the AWS region hosting your user pool had a bad day, your users couldn't log in. Full stop. No sign-ins, no tokens, no access. Your beautifully engineered multi-region app, with its global database and its failover-ready APIs, would fall over at the one door everyone has to walk through: authentication.

The irony was hard to miss. You could replicate your database across the planet, spread your compute across regions, and set up Route 53 to reroute traffic in seconds. And then a single regional hiccup in Cognito would lock every user out anyway. The identity layer was the last stubborn single point of failure in an otherwise resilient stack.

The usual workaround was a mess of duct tape. You'd export users, sync them with post-confirmation Lambda triggers, stand up a second pool in another region, and quietly pray during the switch. Teams poured real engineering hours into building and babysitting these custom replication pipelines. And even after all that effort, one thing refused to cooperate: passwords. AWS doesn't hand out password hashes, so you simply couldn't copy credentials across. A failover meant every single user had to reset their password, then reset it again when the primary came back. Not exactly the smooth disaster recovery story you want to tell your boss at 3 AM.

That's finally over.

What actually changed

Amazon Cognito now offers native multi-Region replication, or MRR. You create a replica user pool in a second region, and Cognito keeps user data, credentials, and pool configuration in sync for you. No custom Lambda glue, no nightly export jobs, no reconciliation runbooks. When your primary region goes dark, users keep signing in with the passwords they already have. No forced resets. That single detail is the headline, because it erases the most painful part of every homegrown solution people cobbled together before.

Here's how it works under the hood. When you enable MRR, Cognito creates separate user pools that share one user pool ID. Your primary pool stays the boss. It's the authoritative source for all the writes: sign-ups, password changes, profile edits, admin configuration. The secondary pool sits in read-only mode, quietly staying up to date. Replication is one-way, primary to secondary, and it's eventually consistent, so expect brief sync delays measured in seconds rather than anything you'd notice day to day.

New replica pools start life in an inactive state. You review the regional settings, configure what needs to differ between regions, and then activate. When trouble hits, you move to failover mode and the secondary pool starts handling sign-ins and token generation. There's a nice touch here for active sessions too: both regions recognize access tokens issued by either side, so users who are already logged in don't get kicked out mid-session during a switch.

The numbers are the fun part. Teams migrating from the old export-and-import approach are seeing authentication recovery times drop from roughly four hours to under two minutes, with data replication lag falling from as much as a full day down to seconds. That's the difference between a genuine outage and a blip most users never notice.

How failover actually happens

The switch itself is DNS-driven, and you own the wiring. You set up a custom domain, create a Route 53 health check against your primary Cognito endpoint, and configure a failover routing policy. When the health check goes unhealthy, traffic automatically routes to the secondary region. No human at a keyboard, no frantic Slack thread, no manual intervention required once it's set up properly.

One subtle thing to understand is token validation after failover. Tokens issued by the primary pool are signed with the primary pool's key, and its JWKS endpoint is the source of truth for verifying them. If you're validating tokens yourself, make sure your setup accounts for both regions' issuer URLs rather than hardcoding one. It's the kind of detail that works fine in testing and then surprises you at the worst possible moment.

The fine print worth reading

This is a real feature, not a magic wand, so a few things genuinely deserve your attention before you assume you're covered.

First, it's active-passive, not active-active. During failover, users can sign in, but new sign-ups, password resets, and profile updates are all paused until you're back to normal operation. For most apps that's a perfectly reasonable trade. Keeping existing users authenticated matters far more than accepting new registrations during a regional outage. Just know the limitation going in.

Second, TOTP-based MFA isn't supported on the secondary pool. If your compliance requirements demand multi-factor everywhere, all the time, this is a hard stop rather than a footnote. Worth flagging early in any planning conversation.

Third, and this is the one that catches people, replication does not copy everything. Lambda triggers, WAF associations, and CloudWatch logging do not replicate automatically. You have to redeploy all of that to the secondary region yourself. This is the most common mistake teams make. Your failover will look perfectly healthy at the DNS level, the traffic will route correctly, and then it'll silently break because your custom authentication flow isn't actually there in the second region. Lockout counters aren't synced across regions either, so keep that in mind for your security posture.

Finally, the setup requirements. You need a multi-Region customer managed KMS key configured before you can enable replication, available in every region that hosts a replica. And your pool has to be on the Essentials or Plus feature plan. Lite pools can't use MRR at all. Replication carries its own additional cost on top of your existing plan, so factor that into the budget conversation.

Should you care?

If authentication is a single point of failure in your architecture, absolutely yes. This closes a gap that made Cognito a genuinely tough sell for anyone building serious high-availability systems, and it brings AWS closer to competitors like Auth0 that have offered multi-region support for a while.

It's a big, welcome step forward, and for a lot of teams it removes an enormous amount of complexity they'd been carrying for years. Just go in clear-eyed about the limitations, redeploy your triggers and rules to the secondary region, and, above all, test your failover before you actually need it.

The worst time to discover a gap in your disaster recovery plan is during an actual disaster.