SaaS Architecture: Multi-tenant with AWS

Software as a Service (SaaS)

Software as a Service (SaaS) is a licensing and delivery model in which the software is licensed on a subscription plan and stored on the vendor's servers.

Through this service, customers use the cloud infrastructure to publish their application and provide access in their environment. The customer is responsible for managing user access, creating accounts, provisioning resources and managing accounts within their application.

Some applications offered as SaaS are Salesforce, Google Suite, Dropbox, Office 365, Zoom, AWS and Slack, among others.

Multi-user or multi-tenant architecture

Multi-tenant architecture means that the same instance of a software and its infrastructure supports multiple users. For a better understanding of this article, the users of this type of architectures will be called tenants.

Each tenant shares the application and may or may not share even the database. As a security measure and to maintain data privacy, each tenant's data is isolated and remains hidden from other tenants.

Principles of a Multiuser Architecture

A Multiuser Architecture must take into account several aspects to ensure a quality service, however, it can be said that the three most important are the following: Isolation, Induction and Identity.

In this article we will talk about Isolation, types that exist and considerations for its implementation.

Strategies to implement Isolation

Implementing an Isolation strategy requires the analysis of some models that may be present in the infrastructure being built. Some of these models are: Tiered Strategy, Noisy Neighbors, Compliance Requirements, Inherited Architecture and Business Opportunity.

• Level Strategy

  The Tiered Strategy is applied in those cases where you have a system that offers different levels of versions for different types of customers, such as basic, advanced and enterprise, for example. In this case each tier will have different levels of isolation and therefore an infrastructure must be developed to support them.

• Noisy Neighbors

  This other model is related to performance, not so much to security. If you have tenants that consider that sharing the environment with other tenants could affect the performance of the system, then to avoid this impact you should develop an isolation strategy that allows them to have access to their own resources and thus avoid this impact.

• Compliance Requirements

  Compliance Requirements are perhaps one of the most common models for implementing isolation strategies. If customers are from companies that must comply with high regulatory standards, such as healthcare or financial services, then very specific isolation strategies must be implemented to meet these needs.

• Inherited Architecture

  If old systems are to be migrated or included to coexist with the new infrastructure then a way must be found to apply an appropriate level of isolation for these systems that may not work with the model to be implemented.

• Business Opportunity

  You can have an infrastructure that has one or several levels of isolation, but you should always be flexible to apply new levels of isolation if you receive a request from a customer who will be willing to pay for it.

Types of Insulation

1. Silo

In this model, each resource is totally isolated from the other resources of the system, therefore the tenants do not share resources. To achieve this, an independent environment must be provided for each tenant, containing all the resources necessary for its activities.

The silo-based model provides the experience of a multi-tenant SaaS environment where each tenant has its own service stack but at the same time there are unified services such as monitoring, development and deployment to manage all tenants in a shared repository.

In the silo type of insulation there are several ways to implement it:

• Account per tenant

  It is a simple way to implement siloed isolation. Basically, each tenant is given a separate account in the AWS environment. It is important to consider factors such as account limits, number of tenants, management and decentralization when selecting this technique to meet the infrastructure and services to be offered.

• NPV (VPC) per tenant

  In this model, all tenants share the account but each has an NPV or VPC for Virtual Private Cloud. AWS will use this type of network construction plus security groups and login control mechanisms to ensure that each tenant uses only its own environment and does not cross the boundaries into another tenant's environment.

• Subnet per tenant

  In this architecture each subnet within the VPC will be an independent tenant. As with all other options, it is important to validate whether this scheme is attractive and useful for the service being offered.

2. Pool

This model consists of sharing resources with all users and policies and other techniques must be implemented to ensure that proper isolation takes place. One technique you can use is a correct definition of the database so that each tenant has a unique identifier and that data is accessed appropriately through this identifier.

3. Access control policies

A very appropriate technique to perform proper isolation management for each tenant is to establish access control policies not only at the access API level, but also at the level of each node or service being used from AWS, such as an S3 or Redshift.

This will make the solution more robust and prevent inappropriate access to resources and information of other tenants.

4. API Access

To improve isolation when accessing via API and if you are using the API Gateway, then it is recommended to use the AWS Custom Authorizer. This service can view the data and apply policies to it that restrict access to other parts of the system.

Challenge

When working with a Multi-user or Multi-tenant architecture, you must be open to apply different types of isolation according to the types of services and clients that are using your system.

Providing security by authentication is not enough to limit access to other points in the system, use access policies where necessary.

Check what other benefits AWS services offer at the time of selection so that you can identify the most appropriate isolation mechanism for your architecture.

Leonardo Delgado

Project Manager