Architectural Design Patterns for Multi Tenancy on AWS.

Architecting Multi-tenant SaaS Application

The cloud industry will grow very fast throughout 2022. And its market size is going to be three times that of any other IT services. Now suppose we have software. And it requires different users need tenancy based on different policies. It’s what we know as the multi-tenancy. And, all the cloud service provider supports it at all the layer where it is possible. It is at the account level. It supports at the network level or the data level. It also supports at compute level. The multi-tenancy gets supported by all. Also, it caters to us the storage and backup capabilities. Also, it caters to us the security and IAM. It also ensures the best application performance and tenant-level customization. As well it supports analytics, forecasting, and provides the best support for financials. It does that through the subscription option at the account level. Various cross-cutting concerns, like tenant-aware monitoring and logging, get done. Also, it ensures load balancing, endpoint registration, dynamic instance creation, and service discovery. These are a few of the primary concerns for an application. And we need them served for different tenants. We are going to discuss all this in this article. We will discuss all the factors mentioned above. These are a concern while designing certain multi-tenant SaaS applications. And if you want to learn all this, you can contact Naresh I Technologies. We provide complete training for all various certifications related to computer technologies. Naresh I Technologies also is the number one computer training institute in Hyderabad and among the top five computer training institutes in India.

Multi-tenancy on AWS

We need to solve many customer requirements. Like we need to achieve our economic goals at the largest scale possible. We need to create a shared environment for such a model. The increasing ecosystem of the Software as a service requires first the multi-tenancy. And it’s a challenge that’s countered like this.

The prime concern is how well we put in place it. We need a multi-tenant application. And those that share resources, for ensuring secure and state-independent sharing. The two tenants must not be state-dependent. That means coupling is the least. And they should be cohesive like all the software. Yet, there should be zero state dependency. Or else the architecture will be a failure in all the use cases where we deal with the multi-tenancy.

We can have many use cases with multi-tenancy requirements. Like we can have a set of tenants in various geographies. Some can be in the US, and some from India, and some from Russia, with a bunch of such coming from the UK or any country. Yet, different geographies need different facilities and a different set of subscriptions. Some features will not be available in India, some not in Russia, and some in the US. Yet, above all, we need to ensure:

•Greatest resource use
• Best efficiency
• Least cost
• Easy configuration, maintenance, and simplified scaling

And each region can be under a supervisor. The supervisor then handles the customer data via the multi-tenancy account. And they all get created within the application.

Architecting a typical multi-tenant SaaS application

The first need is scaling. The application should grow at a record scale without affecting the tenancy subscription. The architecture should as such it ensures multi-tenancy at scale. For that, we need to ensure compute isolation, network isolation, and data isolation. And we need storage and backup capabilities. Also, we need security and IAM, and various that we discussed above in the introduction.

AWS ensures compute isolation. Though it provides both the shared architecture and the dedicated architecture. The tenants in the shared architecture share the same compute. Though they get isolated at the network level. And their account data remains secure and private to each account holder. Out of them what we need to discuss in detail are as below:

Storage & Backup capabilities :

The database, as well as the object storage, are most essential for all the tenants. AWS leverage the tenants with the ability to separate the object data within a bucket through S3. And in RDS through Data Storage via various mechanisms for schema design. The block storage and database backups get supported by the AMI. As well as the snapshots for the data backup in various tenant account supports it.

Security and IAM :

Multi-tenancy in general needs user identity management. And it needs the authentication to be configurable and maintainable for each tenant. It’s possible through IAM, SSO, or single sign-on. And we have others like AWS Cognito, Federated Identity Integration, and the OpenID.

We need also to secure the tenant data and ensure proper protocols and the mechanism. And this leverages the tenants in:
• Keeping the data private and ensure protection at the storage/network layer
• Encrypt the data during transit as well as during the rest
• Rotate and manage certificates and keys
• Manage the security constructs at the application level
• AWS provides various tools like AWS Cloud Trail, VPC, AWS Inspector, CloudHSM, and CloudWatch.

This architecture also demands high reliability, high availability, and scalability. And for that internal isolation of both the dynamic and the static data is essential. And hence security account analytics shared compute resources. Reporting and billing for the organization as a whole are essential. For ensuring these demands we have the services like AWS EC2, Auto scaling groups, and AWS Lambda. And we have the containerization tools like ECR, ECS, and the EKS.

Tenant Customization:

Facility for customization of all sorts to each tenant is the priority. And we have the customization from UI/UX perspective like the theme. It is the right of each tenant and requires fulfillment. This is essential for the localization of the services in a certain country or area.

We also need to ensure the tenant aware of logging and monitoring. Also, we need to ensure dynamic instance creation. And, also ensure service discovery, load balancing, and endpoint registration. And these we know as the cross-cutting concern.

Analytics:

We need shared analytics, and it’s essential for forecasting and reporting. We have the tools for this like AWS Kinesis and DynamoDB streams.

Forecasting:

Load forecasting is essential. It needs careful planning, analysis, news, trends, and business decisions. It’s for ensuring the proper handling.

Economics:

A proper subscription model for each tenant is a must, and it should be at the organizational level.

It’s a cake piece, and there is a lot more to consider for ensuring this sort of architecture. There are various architectural design patterns for such a multi-tenancy model on AWS. Let’s discuss them now!

Multi-Tenancy Architectural Design Patterns On AWS

We discussed above the factors for designing a multi-tenant application, SaaS. And we now look at various architectural design patterns, for the multi-tenancy on the AWS. And we find their good and bad points.

We can go for a full shared tenancy model, or we can opt for an isolated multi-tenant deployment model. The relationship between the components in such a model plays an essential role. AWS leverages us with various cloud-based solutions. We can use them for this SaaS deployment model.

The first solution is the Governance model. We can have all accounts come under the organization account or a master. And that manages all the accounts under it. It ensures isolated resource sharing within the organization. As well as it ensures account and group formation. We have the payment method for each owner’s accounts. As well as cost reports get generated for each account.

Through the governance model, the resources get shared across the accounts. And there is the effective use of services.

The resources get shared by accounts and with the best usage of the services.

The owner has a complete report of each tenant’s expenses.

The organizational level isolation is for the greatest level, the customer. It’s applied only to the top-level customers.

Yet, it’s not that scalable as each root has an organization level limit.

Also, the impact on the shared services affects each of the tenants. Though individual services for each account does not get affected.

And it’s quite expensive on the economic scale. It includes the applicable limit for the greatest OU at the root level.

Tenant isolation at the AWS account level:

In this model, each of the tenants has different AWS accounts, which gets isolated to some extent. We can treat it as the managed solution on AWS. We have hence, the account level isolation. That covers resource isolation and metrics, and secure billing. And, we can deploy the marketplace solution on each of the AWS account. It is an excellent example of this model.

The account level isolation ensures complete isolation which is best for security. It ensures deployment-specific configuration for the tenant the customization of the solution. As well as it follows the same standards. Also, the data remains completely isolated for each, and it’s a secure sort of deploying. Each tenant gets the bill at the individual level. And different such don’t have access to each other’s information. Hence, there is no volume discount or resource sharing effective use for each tenant. That leads to higher costs. The increasing number of tenants makes complex operation management for each such accounts. And it’s then management in the air.

Isolation at VPC layer

This requires tenant deployments within one AWS account. Though, the level of separation is at the VPC layer. We have separate VPC for each tenant. And that leads to logical boundaries amid tenants. Proper isolation through VPC uses better EC2 instances. All the pricing rules apply to one AWS account. Yet, consolidated billing and separate account billing for each VPC is not possible.

We see above the simplified management and deployment of the setup. And we deal with one account within one VPC. And there is a better use of reserved instances as all those are inside one AWS account.

Cons:

For each of the regions, the Amazon VPC limits need monitoring at the tenant level. The VPC on-premise network connectivity makes managing one such a big challenge.

Isolation at VPC subnet level

In this, there is one AWS account and one VPC, and all the tenant deployment gets done within it. You can see the isolation at the subnet level. Each of the tenants owns a different application or solution version. And there is no sharing between the two tenants. There is no need for VPC peering or simplification of the VPN. As well as we don’t need the AWS Direct Connect connectivity on the premises site. There is one limitation. The Network access control lists and the security groups need very careful management.

Above all the tenants can have their subnets both public and private. And that with proper security for each resource that we deploy within the subnets.

There is no need of creating the VPC peering for the communications among the tenants. And it’s easy hence to manage the resources inside the VPC.

And, its single account multi-subnet deployment. The cost hence is much less through shared resources, and wherever it’s possible.

Yet, the above isolation is tedious for management due to many NACLs and security groups.

The amendment of the VPC settings like the DHCP options set affects tenants in the same manner. And it does not count isolated deployment.

On-premises connectivity can be complex. It’s because of the large count of the VPC that need connectivity.

Isolation at the container layer

The containerization platforms like Docker or Kubernetes applies the containers. It’s for isolating the app and data inside its context. Remember all the deployments are in one AWS account. Yet, the separation level is at the namespace level. The workload shares one cluster. And there is some degree of physical and logical separation among them.

Such isolation is possible through namespaces. The separate namespace for each tenant deployment is by the SELinux runtime environment. This stack comprises Kubernetes operators as the runtime, for managing the application. It also manages the database customized resource instance. And also, the application customized custom resource instance.

The ECS, EKS, and the Fargate ensure containerization. The multi-tenancy (in the Kubernetes) gets ensured through namespaces and platform as code. It helps in building the multi-tenant SaaS solution on the Kubernetes cluster. That provides orchestration power to the Kubernetes in physical isolation. And it leverages the isolation at runtime. It does that through the namespace for building the secure multi-tenant platform. The Rancher or the multi-tenant Kubernetes as a service is a perfect replica of that sort of service. We can make use of the Rancher for deploying many containers. They get isolated by namespaces. It’s as such as the application groups and databases get included in each service. It’s a unique design pattern and very useful.

The advantage of the above is that we can have any number of namespaces. And hence, it’s very scalable for the owner. The customization of each application is tenant-specific. And it remains independent with others as the data of each tenant gets separate. And it remains private to that tenant. The AWS EKS ensures the RBAC implementation. That provides the IAM users the access control over all isolation layer. And the complexity increases due to a lot of namespaces. The multi-tenants share the one worker node. That amplifies the attack vector surface region targeted by the hackers. It’s hard hence to keep the worker and the master nodes secure. The traffic is the security loophole among the namespaces in network communication.

Isolation at the Data Layer

The isolation at the database level is also possible. The applications above can adopt the here mentioned database architectures. Suppose we have a 3-tier application with shared web and application layers. A small variation is possible database layers. there is a list of computes and database services for the above purpose.

Instance isolation:

There is complete isolation of the application compute instance and the associated database. It requires most computing and storage. And we can customize the security policies, database designs, and user interfaces. The compliance and the security requirements are the issues. And that makes the co-hosting tenants with varied security profiles not workable. It’s what AWS caters to us by design with its present contributions through web services.

Different Database for one instance:

The different database ensures the best level of isolation. At the application level, we pick the right database with tenant requests. We hence need metadata maintenance in a separate store like AWS DynamoDB. And this is where the management of the tenant to the database happens.

Separate tables and schemas in one database:

We can have all the tenant’s data in one database with different tables/schemas though. And that ensures the level of isolation among the data of each tenant.

Shared table and Schemas in one database:

This is possible through a unique tenant ID for each tenant. And this happens to be the cheapest method though it is tough to architect it. Yet, if architected it turns out to be most cheap and is easier to maintain and provision. It’s a cheaper tenancy model, and the components get shared. The limitations are exposure and inefficiency to avoid shared attack surfaces. This reduces environmental control. As well as it ensures customization, and in case of failure, all get affected.

The most important advantage is the design. It ensures the best economics of the scale, and it’s the cheapest for operating on the largest scale. We can manage it, maintain and rollback as there is one deployment. It’s the case both when there are separate schema and shared schema in one database. And this involves one VPC design. Though, with many deployments of VPC, they get limited only in number. This is for the multitenant application. And it’s for those who don’t need such need re-architecture. There can be some security concerns as a completely different implementation gets mandated. And then it’s hard to use this architecture style.

Conclusion

The multi-tenancy architecture serves the customers in the best manner. The customers can be a small enterprise or a large enterprise. Hence, scalability is always a concern. Some of the other concerns are software development and maintenance costs. Few more are like how to reduce expenditure and ensure saving through the best use of the resources. May it be computing, database, storage, network, or any of the factors from the architecture. All units should be best utilized. And the privacy and security of each tenant get ensured. The owner’s profit gets ensured as well.

This concept is vast, and a topic of research for the SaaS service providers. The topic becomes more complex in the case of B2B and B2C multi-tenant architecture. Such architecture over the cloud is even more fruitful. It is as compared to the internet and on premises-based implementation. It is since all the cloud features make multi-tenant architecture more fruitful. And at scale, this is what all the organization wants in their software architecture.

The organization, yet, must do enough research to understand their requirements. As well as it should understand customer’s need. It’s must before pick one design pattern from those mentioned above. Different design patterns are useful in the case of different use cases. It’s an essential part of the SaaS, yet, the multitenancy architecture.

You can contact Naresh I Technologies for your online training in various computer technologies. We provide training in Hyderabad and USA, and in fact, you can contact us from any part of the world through our phone or online form on our site. Just fill it and submit it, and one of our customer care executives will be contacting you. And what else you get:

You have the freedom to choose from online training and classroom training.
Chance to study from one of the best faculties and one of the best computer training institutes in India
Nominal fee affordable for all
Complete training
You get training for tackling all the nitty-gritty of various computer technologies.
Both theoretical and practical training.
And a lot more is waiting for you.
You can contact us anytime for your training and from any part of the world. Naresh I Technologies caters to one of the best computer training in India.