Cognito pool per region vs Cognito pool per tenant - amazon-web-services

Question

I am reading about multi-region architecture considerations.
Our reasons for moving to a multi-region architecture are pretty much the same as everyone else's:
Reducing latency for customers that are in different continents (EU, US, Asia, Africa)
Being in compliance with their data storage needs
Enable regional failover
We will be using Cognito pools and dynamo DB for data storage. Global Cognito pools do not seem to be a thing as Global DynamoDB tables. For a multi-tenant system SAAS system with tenants in different continents, Should the user pool be generated per region or per tenant? In this video here, https://www.youtube.com/watch?v=kmVUbngCyOw&feature=emb_logo&ab_channel=AmazonWebServices , it is recommended to have a pool per tenant. I fail to see many advantages for it though.
Is it instead a good idea to have a user pool per region instead?
The video also suggests having identity pools in addition to user pools. Why should that be the case in a multi-tenant system?
if I was to ensure data residency in the same region as the tenants in dynamodb as well, how should that be handled? and how should active-active architecture
We also need to host the application URLs like tenant1.companydomain.com for all of the tenants. what's the best way to go about it?

Answer 1

This question is too large, but anyway.
1. Reducing Latency
Unless you are calling Cognito APIs often Authentication is really the main concern here, but if you are using a long lived refresh token they shouldn't have to authenticate all the time so it wont be a massive problem. However a bigger problem is if you only use the one pool, you will have to consider that you sometimes need some Cognito Integration to be in the same region, such as a Cognito Authorizer on an API gateway. But you could write your own Lambda Authorizer to get around this.
2. Being in compliance with their data storage needs
This may force your hand in the User Pool decision, although you can always do the option of keeping your identity and your details in separate storage, making use of Lambda Triggers in the User Pool to sync data.
3. regional failover
I don't understand this in regards to your question about how many User Pools to use. If you use one in each region, then you will need to duplicate it in another region if you wanted to add your own failover capability. If you had only 1 User Pool you would have to duplicate only 1. I've never heard of anybody duplicating a User Pool to another region, this conflicts with what you wanted in 2.. If you've used integrations too, you cannot default to another User Pool you'd have to default to a whole new instance of the website, not just the User Pool. You'd have to also create your own Triggers which would do this for you.
Should the user pool be generated per region or per tenant?
This honestly is a large question in itself, we build a multi-tenant SAAS platform and I can honestly say User Pool per tenant would be a nightmare. 1 User Pool is easiest (as for example with the API GW Integration you cannot select multi user pools). You can use an app client per tenant and customize the signin for that tenant and give each tenant their own sub-domain.
4. Is it instead a good idea to have a user pool per region instead?
Other more meaningful questions are maybe? Do I want users to have the same identity in different regions? Do I want a user to be able to use more than on region? etc. Think about different websites that have this feature. For example Amazon you have a global identity and you can switch your store you are visiting, you need to specify requirements.
5. The video
Sorry not going to watch the video, but you can have an identity pool select permissions from the token (i.e. the group permissions for that user in Cognito). That covers 99% of use cases start from there.
6. if I was to ensure data residency...
Out of the box this is how the cloud is unless you specify a global resource everything is per region so you do nothing. You cannot have both data residency and regional failover at the same time.