What is Multi-Tenancy?

When I discuss multi-tenancy, I often encounter the question: "What exactly is a tenant?"

There’s no one-size-fits-all answer. For our team, a tenant referred to a paying customer, while for others, it might have a different connotation. This variation reflects how we chose to implement segmentation in our application.

A tenant can be defined as a group of users who share access to a specific set of data. In a multi-tenant system, numerous groups of users share the same application instance but have access only to their designated data.

This model is advantageous for larger applications, simplifying release management since you don’t need to deploy a separate instance for every customer. However, this setup carries risks; if one tenant encounters an issue, it could potentially affect all users.

Implementing Multi-Tenancy in a Serverless Environment

To clarify these concepts, I'll showcase a GitHub repository containing a fully functional multi-tenant application designed to manage state parks.

Each defined role in the system grants access to various endpoints, and users can hold multiple roles, expanding their access to different features. Although users can belong to multiple tenants, they can only have one "active" tenant at a time, which streamlines authentication and maintains data boundaries.

By switching tenants, users change the data they can access. In our reference application, the roles assigned to users are based on their active tenant, allowing for varied access control.

Authorization Strategies

While Amazon Cognito offers various multi-tenancy options, our example focuses on a request-based Lambda authorizer that assesses the caller's identity and identifies their active tenant. This authorizer operates in front of an API gateway, evaluating the provided authentication token and returning an IAM policy for the user.

To visualize the authorizer's flow:

Our example leverages the authorizer context to enrich data passed to downstream services. The context includes user details and can look like this:

{

"userId": "testuserid",

"tenantId": "texas",

"email": "[email protected]",

"roles": "["admin"]",

"firstName": "Test",

"lastName": "User"

}

The operational flow of our Lambda authorizer involves several key steps:

1. Validate JWT: The workflow authenticates the JWT from the Authorization header.
2. Load User Details: User information, including the active tenant and roles, is retrieved from DynamoDB.
3. Determine Access Policy: Based on the roles of the active tenant, an IAM policy is constructed for allowed endpoints.
4. Build Authorizer Context: A data object containing user information is created for downstream services.
5. Return Policy and Context: The access policy is sent back to the API Gateway for endpoint access evaluation.

Implementing this authorizer context enhances security in multi-tenant environments, ensuring that malicious users cannot manipulate tenant information.

Data Access Control in Multi-Tenant Applications

The primary goal of multi-tenancy is to ensure that users cannot access data from other tenants. Strong data isolation is essential to prevent unauthorized access.

To achieve this, all indexes should be prefixed with the tenant ID. For example, consider a dataset of state parks:

In this dataset, parks belong to three tenants: Texas, Washington, and Colorado. Both the primary key and GSI should include the tenant ID prefix.

This approach guarantees that requests include the tenant ID, ensuring that data retrieved belongs solely to that tenant. However, be cautious: this method becomes ineffective during table scans.

Scaling Infrastructure and Managing Service Limits

As your application scales to accommodate more tenants, your serverless infrastructure will evolve. However, certain components require careful consideration during the initial design phase.

In a previous discussion on avoiding serverless service limits, I highlighted the discrepancy between the number of SNS topics and subscription filters in AWS accounts. You can create 100,000 SNS topics, but only 200 subscription filters, which are soft limits but crucial to consider in multi-tenant applications.

Instead of static SNS topics, consider creating topics dynamically based on tenant and event type. This approach allows you to scale without the worry of hitting service limits.

As your infrastructure grows, the architecture shifts from synchronous REST API paradigms to batching, caching, and queuing mechanisms. Maintaining the tenant ID during these processes is vital to prevent data mishaps.