In this post, we will explore how to implement multi-tenancy architecture using Amazon Cognito.
Suppose you are building a Saas web application and would like to share it with all of your customers. Each customer should access only their own data layers.
AWS Cognito Multi-Tenancy Models
AWS Cognito propose different models for building multi-tenant applications.
1. User pool-based multi-tenancy
This design allows a user pool to be created for each tenant. This approach provides a high level of isolation for each tenant and allows different configurations to be implemented for each tenant. This isolation of tenants by User pool allows flexibility in user-tenant mapping.
User-pool multi-tenancy best practices
2. Application client-based multi-tenancy
All tenants share the same user pool. Each tenant is associated with a client application. Which means the tenants have the same configurations. For example, data residency and password policy are the same across all tenants.
App-client multi-tenancy best practices
3. Group-based multi-tenancy
With group-based multi-tenancy, each tenant is associated with an Amazon Cognito user pool. That way you can use additional functionality through role-based access control (RBAC)
User-pool group multi-tenancy best practices
4. Custom attribute-based multi-tenancy
With custom attribute-based multi-tenancy, tenant’s identification data is saved as a custom attribute in a user’s profile like tenant_id.
Custom-attribute multi-tenancy best practices
Each solution approach has its pros and cons. It is recommended to implement an approach according to your use cases.
Amazon Cognito quotas are applied per AWS account and per region. These quotas are shared among all tenants of your application. Therefore, it is very important to ensure that the quotas matches the volume and number of tenants for your use cases.
For part 2 of our story, we chose the multi-tenant approach based on the User pools. To demonstrate this approach, we’ll build it with a Spring Boot Project.
Continue reading
The second part of the story, which explains the implementation with Spring boot of our approach, can be found here.
Happy coding 🙂.
