Multi-region Cognito User Pools: can we do it?
|
Cognito doesn't support multi-region user pools (yet), but maybe we can get there ourselves 🤔 Let's do a thought experiment together. Proposed solutionAn API Gateway authorizer has a "ProviderARNs" attribute, where you can reference more than one Cognito User Pools. These are ARNs, so one assumes it can reference a user pool in another region. Cognito's "Post confirmation" hook is fired after a signed-up user confirms their user account. This invokes a Lambda function with the "userAttributes" and "clientMetadata". We can use the information in the payload to create the user in the other region. BUT, we don't have the user's password. If we DON'T use passwords, that will not be a problem. That is, we can go for passwordless authentication. For example, we can use one-time passwords [1] or magic links [2]. If we don't use passwords, we can set a random password when creating the user in the other region. In the front end, the user can log in with either user pool. The user's JWT token can be used to access APIs in either region. Handling failuresWhat if the Cognito service is down in one of the regions? The whole point of going multi-region is to provide higher redundancy, but if Cognito is down in one region, then synchronization is broken. What do we do then? We introduce a fallback. If we can't synchronously add a new user to the other region's user pool, we push a message in a SQS queue. A Lambda function is subscribed to the queue and will retry the failed operation N times before moving the message to a DLQ for further investigation and manual retries. SummaryThis is how the solution will look at a high level. There are a few constraints:
Under these conditions, I think it's a workable solution. Do you think this will work? Do you see any flaws in this solution? And would you like to see a POC for this solution? Links[1] Passwordless Authentication made easy with Cognito: a step-by-step guide​ [2] Implementing Magic Links with Amazon Cognito: A Step-by-Step Guide​ |
Master Serverless
Join 17K readers and level up you AWS game with just 5 mins a week.
Lambda Durable Functions comes with a handy testing SDK. It makes it easy to test durable executions both locally as well as remotely in the cloud. I find the local test runner particular useful for dealing with wait states because I can simply configure the runner to skip time! However, this does not work for callback operations such as waitForCallback. Unfortunately, the official docs didn't include any examples on how to handle this. So here's my workaround. The handler code Imagine you're...
Lambda Durable Functions is a powerful new feature, but its checkpoint + replay model has a few gotchas. Here are five to watch out for. Non-deterministic code The biggest gotcha is when the code is not deterministic. That is, it might do something different during replay. Remember, when a durable execution is replayed, the handler code is executed from the start. So the code must behave exactly the same given the same input. If you use random numbers, or timestamps to make branching...
Hi, I have just finished adding some content around Lambda Managed Instances (LMI) to my upcoming workshop. I put together a cheatsheet of the important ways that LMI is different from Lambda default and thought maybe you'd find it useful too. You can also download the PDF version below. Lambda default vs. Lambda managed instances.pdf