Architecture Isolation Models on AWS

When it comes to building and offering a SaaS solution on AWS, one of the most fundamental decisions, for both the business and the end-user, is the isolation model.

There are several key motivators for isolation within a SaaS product:

• Mitigating “noisy neighbours”, where the most active user can impact the experience of other users. This also ties into your billing model where a tiering strategy can be used to fairly distribute resources.
• Preventing cross tenant access. While you can implement a number of security measures to secure data, some clients may require further isolation where data does not reside alongside others.
• Compliance requirements such as PCI or HIPAA.
• Legacy technologies which cannot be deployed in a multi-tenanted way and require a dedicated resource per customer.
• Financial opportunities. A client may come to you and say we love the product, but we need an isolated deployment of it in our own AWS account.

In this article I am going to look at several of the most common isolation patterns utilised by SaaS clients on AWS, and look at each one from the three key perspectives: Onboarding, Provisioning and Billing.

EC2 Full Stack Isolation Model:

The full-stack isolation model is probably the most common. This is where a full set of infrastructure is deployed for each unique tenant of the system. This model has the simplest onboarding process as the AWS account, network, and security controls are already in place. This allows you to move swiftly on to the provisioning stage.

Provisioning should always be handled with automation. Tools such as CloudFormation and Terraform enable us to automate provisioning tasks in a repeatable manner. However, you may find yourself managing numerous versions of this Infrastructure as Code to handle variance in client configurations, and due to the use of a single account, you will need to ensure there is no crossover between resource names.

Billing is where this model becomes a bit more involved as all of your resources will be rolled up into a single bill. You will need to ensure that all resources are tagged appropriately for each client in order to effectively manage spend and bill end users.

Luckily tagging policies can be utilised at an Organization level to enforce tagging standards. Some other considerations for this model are Service Quotas, whereby AWS limits the number of resources, and elastic IP addresses that can be utilised in an account/vpc. These limits are going to be shared by all of your clients. Subnet saturation may also become an issue as you scale.

Account Isolation Model:

The next model we are looking at is the full account isolation model.

This is another very common model and has a similar approach to full stack isolation in that all resources are siloed. This model has a more involved onboarding process as new AWS accounts need to be created, networking and security resources implemented, as well as the initial integration of tooling and management access.

Provisioning would follow the same practice as in the full stack model, but without the need to worry about service limits. However, this stage will be delayed by the onboarding process and ensuring sufficient roles and security mechanisms.

From a billing perspective, this is probably one of the simplest models as each account is billed independently and the resources are dedicated to a single client.

Container Isolation Model:

The container isolation model aims to provide full stack-like isolation with the benefits of a shared control plane. It is also commonly referred to as the “bridge” model.

This approach utilises a shared compute resource (such as ECS) to standardise the onboarding, provisioning and delivery process. You then have the flexibility to provision pooled resources, such as a frontend interface or admin portal, whilst providing dedicated resources for the backend and data storage to each client.

Onboarding and provisioning are straightforward. The accounts and tooling are configured and enabling a new client only requires an additional container deployment. However, billing is once again dependent on a strict tagging policy and lifecycle management.

Serverless Isolation Model:

The serverless isolation model, or Policy-based isolation, is one of the more modern approaches to SaaS delivery and primarily utilises a multi-tenanted philosophy.

Resource access is isolated via the use of IAM policies and access tokens, preventing one tenant from accessing the S3 bucket or schema of another client. AWS provides robust identity and access management allowing muti-layered and least privilege security controls with a high level of granularity. When users login to the system their specific access policy is assigned.

Onboarding and provisioning become automated and part of the application. For example, the creation of a tenant ID in the shared/customer database may be all that is required. You also have a single code base and application version to maintain, which speeds up the delivery of new features and fixes.

Billing for this kind of environment is usually based on usage, rate limits and additional value-added services. This allows you to create a self-service tiered billing model, while also being able to offer dedicated resources for the right price.

The above diagram demonstrates a multi-tenant setup for the majority of clients, while tenant 1 and 2 have some dedicated resources as well.

In Conclusion

When designing a SaaS solution it’s not a one-size-fits-all decision. Different aspects of your architecture can deploy different isolation models. You could use a multi-tenant pool for the frontend web application and a silo model for storing data in S3. When designing a SaaS product you should break down each component and consider what the isolation and tenancy model must be for that part of the stack, taking into account, onboarding, provisioning, compliances and pricing.

If building a new SaaS product on AWS from scratch, a multi-tenanted policy-based model will enable you to scale, innovate and onboard quicker while still being able to provide “Enterprise” dedicated offerings should the right customer come along.

From experience, it is far simpler to deploy a multi-tenant solution for a single user than it is to create a multi-tenant solution from something that has been designed to run as a silo.