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.
AppSync doesn’t allow unauthenticated API calls. To allow users to call your API without first authenticating themselves, you must mimic the behaviour using one of the available authorization methods [1]. In this post, let’s look at three ways to implement unauthenticated GraphQL operations with AppSync and their pros & cons. API Keys To use API keys, you need to: Add an API Key in AppSync. Pass the API Key in the x-api-key header. That’s it! It’s the easiest and most common way to implement...
A common challenge when building APIs is supporting multiple live versions without letting the system turn into an unmaintainable mess. You need to keep older versions running for existing clients, roll out new versions safely, and avoid breaking changes that might take down production. And you need to do all that without duplicating too much infrastructure or introducing spaghetti logic inside your code. There’s no official pattern for versioning APIs in API Gateway + Lambda. API Gateway...
I recently shared six event versioning strategies for event-driven architectures [1]. In response to this, Marty Pitt reached out and showed me how Orbital [2] and Taxi [3] use semantic tags to eliminate schema coupling in event-driven architectures and simplify the schema management. It's a novel way to manage schema evolution, and I want to share what I learnt with you. Problems with Schema Coupling In an event-driven architecture, event consumers are typically coupled to the schema of the...