Amazon Cognito MRR vs Export profile reference architecture
A comparison of the newly announced multi region replication against the existing reference architecture for resilient user pool solution.
AWS on 4 June 2026 made multi region replication (MRR) of Cognito user pool and machine identity data. With this Cognito is trying to close the resiliency gap that was much needed for critical applications. Before MRR was generally available, AWS recommended a reference architecture to export identity information from the primary to secondary region using Step functions, Lambda and DynamoDB.
Without going to deep into either of the solutions, I am trying to compare them to identify when to choose one and the trade offs that come with choosing one over the other.
User Profiles Export – Reference Architecture
The solution involves building a Step functions workflow with Lambda in the primary region to export the user profiles into a DynamoDB Global Table and another workflow in the secondary region to import the profiles into the secondary user pool
Image Courtesy: Amazon Web Services
Limitations of the solution
- Passwords are not copied over. If the application switches over to use the secondary region, the user has to reset their password.
- The solution does not support pools with MFA enabled.
- The “sub” attribute of the user will be different in the secondary pool and if the application relies on “sub” attribute of the token to authorize operations, they will fail.
- Custom attributes from federated logins from the primary are not copied over to the secondary pool.
- User history is not exported from the primary pool.
- If the user pool allows both email and phone number as valid identities, then those user pools are not supported by the solution.
- If there are IAM roles attached to a user group, they are not exported by the solution. Similar roles have to be created in the secondary pool and associated with the replicated group.
Cognito Multi Region Replication (MRR)
Cognito MRR creates a replica user pool in a secondary region of your choice. The replica pool has the same user pool ID as the primary. All of the primary configurations like app clients, client credentials, user data including attributes, hashed credentials (password) and group memberships and external IdP settings are replicated. The replication is eventually consistent.
The user pools are interoperable meaning that the sessions, tokens are valid in both the instances.
Managed login and federation
The following is the flow for managed login. As seen in the figure below, a R53 health check is used to ascertain the health of the primary and if primary is not healthy, the request goes to the secondary. The rest of the flow is handled by the secondary when the switch over happens.
Image Courtesy: Amazon Web Services
M2M architecture
This flow uses the client credentials authorization grant and does not involve a user. The failover is similar to the login flow.
Image Courtesy: Amazon Web Services
Limitations of MRR
- Multi-Region replication has separate add-on costs and requires your user pool to be on the Essentials or Plus. You can't enable MRR on user pools with the Lite feature plan.
- New users cannot be created in the secondary pool and federated users can authenticate only if they had signed in at least once in the primary pool with the federated login.
- Password resets cannot happen in the secondary pool. The option has to be disabled or gracefully handled in the secondary region in the fail over state. It can be enabled once the primary is fully available again.
- Only one replica in an additional region is allowed.
- TOTP MFA is not supported in the secondary region.
- Authentication attempt count is not synchronized between the regions.
How to choose the right solution
Both the solutions have their own limitations and below is a comparison of them to help choose the right one.
| Dimension | Profile replication | MRR |
|---|---|---|
| When cost matters | ✅ | ❌ |
| When seamless login without password reset is required | ❌ | ✅ |
| When new user registration is required | ✅ | ❌ |
| When active-active fail over is required | ❌ | ✅ |
| When seamless login / authorization experience with one shared token is required | ❌ | ✅ |
Conclusion
Cognito MRR is the newer, more complete answer to identity resiliency, and for most workloads it should be the default: it replicates passwords, MFA settings, and group memberships automatically, and keeps tokens interoperable across regions so a failover is close to transparent to the application layer. The profile export pattern hasn't been made obsolete, though it remains the better fit when you need to register new users during a regional outage (MRR blocks this on the secondary pool), when your application authorizes on the "sub" claim and can tolerate reissuing it, or when the added cost of the Essentials/Plus feature plan required for MRR doesn't make sense for the workload. In short: reach for MRR first, and fall back to the export pattern only where MRR's specific constraints : no new registrations, no password reset, single additional region: rule it out.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article