Scaling Multi-Tenant SaaS Identity with AWS Cognito

When building multi-tenant SaaS applications, managing user identity and authentication efficiently for numerous tenants is a critical design challenge. Amazon Cognito, while a common choice for AWS users, presents a significant hurdle with its default 1,000 User Pool Limit per account. This limit forces architects to rethink their identity management strategy as their platform scales beyond a small number of tenants.

The Challenge of Siloed Identity Architectures

The 'one user pool per tenant' or siloed model offers strong isolation but quickly becomes unmanageable and unscalable due to several factors:

• Infrastructure Management Overhead: Provisioning and managing hundreds or thousands of Cognito User Pools (via CloudFormation or Terraform) is complex and resource-intensive.
• Global Configuration Changes: Applying a simple password policy update or feature across all tenants requires thousands of API calls, leading to operational inefficiencies.
• Cross-Tenant Features: Building functionalities like a global admin dashboard that spans multiple tenants is difficult and requires custom logic.
• Hard AWS Limits: The strict 1,000 user pool limit per AWS account necessitates complex multi-account strategies that only defer the problem.

Scaling Patterns for Multi-Tenant Identity

To overcome the limitations of the siloed model, the article introduces three progressive patterns:

1. Shared User Pool (Custom Attributes): All tenants share a single User Pool. Tenant differentiation and isolation are achieved by storing a `custom:tenant_id` attribute in user profiles and enforcing it in the application layer (e.g., via a Lambda Authorizer checking JWT claims). This is simple but lacks customization per tenant.
2. Hybrid Model (App Clients & Identity Providers): This pattern refines the shared user pool by leveraging App Clients (up to 1,000 per User Pool) to provide per-tenant customization. Each tenant gets their own App Client, allowing specific Identity Providers (SAML, OIDC, Social) and potentially different password policies to be associated with them. Tenant subdomains can be mapped to specific client IDs for routing.
3. Cell-Based Identity Architecture: For very large-scale SaaS (tens of thousands of tenants), this model groups tenants into 'cells.' Each cell is an independent unit of infrastructure, containing its own User Pool. A 'Global Router' (e.g., DynamoDB + Lambda) maps a tenant's identifier (like `tenant_id` or `email_domain`) to the correct User Pool and Client ID, directing users to their respective identity cell.

Security Considerations: Preventing Tenant Data Leaks