avatarEric Anicet

Summary

The provided content discusses the implementation of multi-tenancy architecture in a SaaS web application using Amazon Cognito, detailing various models and their respective configurations.

Abstract

The article delves into the concept of multi-tenancy architecture, particularly for SaaS web applications, and outlines how Amazon Cognito can be utilized to facilitate tenant isolation and data layer access. It describes four distinct multi-tenancy models supported by AWS Cognito: user pool-based, application client-based, group-based, and custom attribute-based multi-tenancy. Each model offers different levels of tenant isolation and configuration flexibility, catering to various use cases and tenant requirements. The user pool-based model creates a separate user pool for each tenant, ensuring high isolation and customizable configurations. The application client-based model shares a user pool among tenants but differentiates them through client applications, which is suitable for tenants with similar configurations. Group-based multi-tenancy associates tenants with groups within a user pool, allowing for role-based access control. Lastly, the custom attribute-based model identifies tenants using custom attributes within user profiles. The article emphasizes the importance of selecting a multi-tenancy approach that aligns with specific use cases and considering AWS Cognito's quotas per account and region when planning for tenant volume. The narrative concludes by hinting at a follow-up piece that will demonstrate the user pools-based approach with a Spring Boot Project implementation.

Opinions

  • The author suggests that the choice of multi-tenancy model should be driven by the specific needs of the application and its tenants.
  • It is implied that AWS Cognito's flexibility in supporting different multi-tenancy models is a significant advantage for developers.
  • The article conveys that tenant isolation and data security are critical considerations in multi-tenant SaaS applications.
  • The author recommends that developers be mindful of AWS Cognito's service quotas when designing multi-tenant architectures to avoid limitations as the application scales.
  • The author expresses a preference for the user pool-based multi-tenancy model, as indicated by the choice to expand on this approach in the upcoming second part of the article.

Multi-Tenancy architecture using AWS Cognito : Part 1

In this story, 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-based multi-tenancy

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.

Application client-based multi-tenancy

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)

Group-based multi-tenancy

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-based multi-tenancy

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 🙂.

Aws Cognito
Aws Dynamodb
Spring Boot
Multi Tenant Architecture
Java11
Recommended from ReadMedium