Today, most organizations, large or small, are hosting their SaaS application on the cloud using multi-tenant architecture. There are multiple reasons for this, but the most simple and straightforward reasons are cost and scalability. In a multi-tenant architecture, one instance of a software application is shared by multiple tenants (clients). These tenants share various resources such as databases, web servers, computing resources, etc., that make multi-tenant architecture cost-efficient while keeping scalability in mind.

Architecting a Typical Multi-tenant SaaS Application

Let us look at some of the requirements for a typical multi-tenant SaaS application. Apart from the core functional components of a SaaS solution to future-proof an application, creating support components will allow us to scale the application over time.

Compute Isolation – Tenants within a business may have varying requirements for computing resources, depending on the size of their business operations. For a smaller tenant, compute isolation with lower resource usage, and for a larger tenant, compute isolation with higher resource usage needs to be considered to drive down costs that are ultimately handed off to the customer via the tenants.

Networking Isolation – Another consideration is to provide isolation among tenants at the network level. This ensures the compliance of physical and logical security and access parameters. A tenant would never be amenable to having its access and data shared with any other tenant(s). Otherwise, AWS VPC-based isolation would be the best implementation option.

Data Isolation – The foremost requirement is that data for a single tenant should be isolated and not visible to or accessible by another tenant in the group.

Storage & Backup Capabilities – Database and object storage are the main requirements for tenants. AWS provides the ability to separate object data in buckets by using S3 and database storage in RDS through different mechanisms for schema design. For backups of block storage as well as databases, AWS provides AMI creation, snapshots as the means for tenant data backup.

Security and IAM – Multi-tenancy invariably requires user identity management and authentication to be maintainable and configurable, per tenant. To do so, we can use AWS Services like IAM (Identity and Access Management), Federated Identities, SSO (Single sign-on), OpenID, Federated Identity Integration, and Amazon Cognito.

We also need to secure the tenant data and ensure that the necessary protocols and mechanisms are in place. This helps to:

• keep data privacy and protection at the network/storage layer
• encrypt data at rest or in transit
• manage and rotate keys and certificates
• manage application-level security constructs

AWS provides several tools that can help address some of these considerations, such as AWS CloudHSM, AWS CloudTrail, VPC, WAF, Amazon Inspector, and CloudWatch.

Application Performance – High availability, reliability, and scalability are the demands of multi-tenant architecture, considering such applications tend to be multi-regional and require internal isolation of both static and dynamic data. This includes security, shared compute resources, and combined account analytics, billing, reporting for the organization as a whole. AWS provides its compute group to meet these demands with services such as AWS EC2, AWS Lambda, autoscaling groups, as well as for containerization in AWS ECS, ECR, and EKS.

Tenant Customization – Multi-tenant solutions are designed to be highly configurable so that businesses can have their own set of configurations for each tenant in the system. For example, this can allow customizations from a UI/UX perspective and system settings or configuration data. Providing the ability to a tenant to define the styling of their applications is also important to localize the services in a particular country or region.

Cross-cutting Concerns – Multi-tenancy is a common concern in any SaaS application as it affects almost all layers of a typical application. Tenant-aware centralized logging and monitoring, service discovery, dynamic instance creation, endpoint registration, and load balancing are some of the primary impact areas for such an application.

Analytics – Shared analytics across tenant accounts, customers, and internal employees is a crucial requirement for reporting and forecasting. AWS provides several tools to tackle this area, such as Amazon Kinesis and Dynamo DB streams.

Forecasting – One of the most challenging considerations is about forecasting the load so that enough servers could be spawned as fast as possible to handle the load. This requires careful planning and analysis of usage, trends, news, and business decisions to ensure it is handled properly.

Financials – Billing requires an account-wise implementation and a consolidated subscription model to be aware of each tenant’s usage and at the organization level.

The solution can range from a fully isolated tenant deployment to a completely shared tenancy SaaS model, assuming the application itself also supports and incorporates the multi-tenancy components. An ideal architecture depends on its potential impact on the interconnected components, with a multidimensional view on tenancy. To tackle the bull by its horns, AWS provides several cloud-enabled solutions, which in effect, can be utilized as the following SaaS deployment models:

1. Multi-tenancy Isolation Through the Governance Model
2. Tenant Isolation at the AWS Account Level
3. Tenant Isolation at the Amazon VPC Subnet Layer
4. Tenant Isolation at the Container Layer
5. Tenant Isolation at the Data Layer

Let’s deep dive into the above models in Part 2 of this blog.

Continued in Part 2