Amazon Web Services Feed
Explore SaaS Tenant Isolation Strategies in New SaaS Whitepaper
By Tod Golding, Principal Partner Solutions Architect at AWS
Tenant isolation is fundamental to the design and development of software-as-a-service (SaaS) systems. It enables SaaS providers to reassure customers that—even in a multi-tenant environment—their resources cannot be accessed by other tenants.
While the importance of isolation is well understood, the strategies for realizing a robust isolation model vary significantly based on the design of your SaaS application and the services it uses.
As a Partner Solutions Architect for AWS SaaS Factory, I have worked with organizations that have a wide range of isolation needs. Based on these experiences, we have created a new SaaS Tenant Isolation Strategies whitepaper that assembles a collection of best practices and considerations that often shape your approach to implementing isolation in a SaaS environment.
In this post, I will provide a high-level view of the core concepts covered in the whitepaper. We’ll look at the terminology used to classify and characterize the various isolation models, and we’ll touch on themes associated with implementing these isolation models with different Amazon Web Services (AWS) constructs.
Read the SaaS Tenant Isolation Strategies whitepaper >>
The Isolation Mindset
Before we take a high-level look at what’s covered in the whitepaper, let’s start by looking at some of the key themes that shape any isolation strategy.
As a general rule of thumb, most SaaS providers are likely to agree on the importance and value of protecting and isolating tenant resources. However, as you dig into the details of implementing an isolation strategy, you’ll often find that each SaaS ISV has their own definition of what is enough isolation.
Given these varying perspectives, the whitepaper outlines some fundamental tenets that will guide your overall value system for tenant isolation. Every SaaS provider should establish a clear set of high-level isolation requirements that will guide their teams as they define the isolation footprint of their SaaS environment.
Following are some key tenets that are included in the whitepaper:
- Isolation is not optional – Isolation is a foundational element of SaaS, and every system that delivers a solution in a multi-tenant model should ensure their systems take measures to ensure that tenant resources are isolated.
. - Authentication and authorization are not equal to isolation – While it’s expected you will control access to your SaaS environments through authentication and authorization, getting beyond the entry points of a login screen or API does not mean you have achieved isolation. This is just one piece of the isolation puzzle and is not enough on its own.
. - Isolation enforcement should not be left to service developers – While developers are never expected to introduce code that might violate isolation, it’s unrealistic to expect they will never un-intentionally cross a tenant boundary. To mitigate this, scoping of access to resources should be controlled through some shared mechanism that’s responsible for applying isolation rules (outside the view of developers).
. - If there’s not an out-of-the box isolation solution, you may have to build it yourself – There are a number of security mechanisms such as AWS Identity and Access Management (IAM) that can simplify the path to tenant isolation. These tools, and their integration with a broader security scheme, often make isolation a somewhat seamless experience.
.
However, there may be scenarios where your isolation model is not directly addressed by a corresponding tool or technology. The absence of a clear solution should not represent an opportunity to lower your isolation requirements—even if that means building something of your own.
- Isolation is not a resource-level construct – In the world of multi-tenancy and isolation, some view isolation as a way to draw a hard boundary between concrete infrastructure resources. This often translates into an isolation model where you have separate databases, compute instances, accounts, or virtual private clouds (VPCs) for each tenant. While these are common forms of isolation, they are not the only way to isolate tenants.
.
Even in scenarios where resources are shared—in fact, especially in environments where resources are shared—there are ways to achieve isolation. In this shared resource model, isolation can be a logical construct that is enforced by run-time applied policies. The key point here is that isolation should not be equated to having siloed resources.
- Domains may impose specific isolation requirements – While there are many approaches to achieving tenant isolation, the realities of a given domain may impose constraints requiring specific flavor of isolation. Some high compliance industries, for example, will require that every tenant have its own database. In these cases, the shared, policy-based approaches to isolation may not be adequate.
Isolation Models
To understand isolation, you must first have a good grasp of the different isolation models of SaaS environments. Since there’s no one-size-fits-all SaaS architecture, the whitepaper first outlines the fundamental terminology used to identify common SaaS architecture patterns.
The following section provides a brief overview of the common patterns that are covered in more depth in the whitepaper.
The Silo Isolation Model
While SaaS providers are often focused on the value of sharing resources, there are still scenarios where a SaaS provider may choose a model where tenants have dedicated resources for some (or all) of their environment.
The whitepaper looks at a full-stack silo isolation model where each tenant has its own full stack of resources. Some might challenge whether this represents a true SaaS environment.
However, if you’ve surrounded these separate stacks with shared identity, onboarding, metering, metrics, deployment, analytics, and operations, then we’d still say this is still a valid variant of SaaS that trades economies of scale and operational efficiency for compliance, business, or domain considerations. With this approach, isolation is an end-to-end construct that spans an entire customer stack.
The whitepaper also looks at more granular variations of silo model where storage or individual services of your application are siloed for specific tenants. This strategy lets you target isolation based on specific business or technical needs.
The Pool Isolation Model
It’s pretty easy to see how the silo model of isolation maps nicely for many SaaS companies. At the same time, many companies that are moving to SaaS seek out the efficiency, agility, and cost benefits of being able to have their tenants share some or all of their underlying infrastructure.
While this shared infrastructure approach, which is referred to as a pool model, has lots of upside, you can imagine how placing tenants in shared infrastructure adds new levels of complexity to your tenant isolation model.
The Bridge Model
You can see the the silo and pool models take very different approaches to isolation. The reality is, though, that the isolation landscape for many SaaS providers is less absolute. As you look at real application problems and decompose our systems into smaller services, you will often discover your solution requires a mix of the silo and pool models.
This mixed model is what we would refer to as a bridge model of isolation. This is where the whitepaper examines what it means to implement a mix of isolation strategies based on how your SaaS environment is decomposed.
Identity and Isolation
As part of looking at isolation, the whitepaper also covers the role of identity in the isolation equation. The reality is, if you are planning to isolate tenants, you must have some way to represent and identify the tenant that is currently accessing the resources of your SaaS environment. In many cases, identity will be used in combination with other constructs to acquire the policies and scoping rules that are at the core of an isolation scheme.
How these policies are defined and applied will vary for each of the isolation models and services you’re consuming. Understanding how tenant are connected to policies, how they’re provisioned, and how this flows seamlessly through your application is key to building an isolation story that’s woven into the fabric of your system.
Implementing Isolation Models
After outlining the core concepts of isolation, the whitepaper shifts its attention to the constructs used to implement these models on AWS.
The following section highlights some of the areas that are covered in greater depth in the whitepaper.
Implementing Full Stack Isolation
The first model we’ll look at is full stack silo isolation. In this scenario, where a SaaS ISV requires all of the resources of a tenant to be fully isolated, you will rely on more coarse-grained AWS constructs to isolate your tenants.
Here, we’ll look at the common factors that lead providers to a full stack isolation model.
The whitepaper examines how accounts, VPCs, and subnets can be used to deploy tenants in a full stack isolation model, highlighting the pros and cons of each of these mechanisms. This includes looking at how these different architectural models influence the operational footprint, cost, and overall agility of a SaaS organization.
In addition to full stack silo isolation, the whitepaper also looks at how silo isolation can be applied in a much more granular fashion where selective elements of your SaaS solution are deployed in a silo model.
Here, we look at how you might apply different isolation strategies based on the specific security and noisy neighbor considerations of individual services. This more targeted approach often provides SaaS providers with a mix of approaches that more selectively addresses the needs of each resource that needs to be isolated.
Implementing Pool Isolation
The pool model is often the most appealing to SaaS providers. The efficiency, agility, and cost profile of pool is frequently what motivates providers to deliver in this model. Of course, as we move resources into a shared model, we have a much more challenging isolation story to tell.
There is often a fundamental mismatch between the tools and mechanisms that provide isolation and the nature of tenants consuming a shared resource. This is further complicated by the fact that each resource we need to isolate in the pool model may require a different approach to enforcing isolation.
While these challenges are real, they should not represent an opportunity to somehow relax your isolation requirements. This just means you’ll have to work a bit harder to find the right combination of tools and constructs to isolate some resources in a pooled model.
The whitepaper covers a range of different strategies for implementing on a range of AWS services and SaaS architecture models. It looks into how policies can be used to acquire and apply isolation with IAM. It also explores alternate considerations for scenarios where IAM may not be able to cover the more granular needs of the pooled model.
Coverage of the pooled model also looks at the operational considerations associated using a pooled model, with emphasis on the operational efficiency and agility that comes naturally with having share infrastructure.
Exploring the Whitepaper
This post provides a high-level view of some of the fundamental topics covered by the new SaaS Tenant Isolation Strategies whitepaper. The paper itself provides a much deeper coverage of isolation topics that should equip SaaS developers and architects with a clearer picture of the options you have when designing your overall SaaS isolation strategy.
The key takeaway is that every SaaS application requires a robust approach to isolation. It should be clear from the whitepaper that there is not a one-size-fits-all approach to isolating SaaS environments. It becomes your job to look at the entire footprint of your application, the personas of your tenants, and the tiers of your offering to figure out how you will choose to isolate the moving parts of your system.
You may also discover that your isolation story can be continually evolving. The strategy that works on day one may change as you better understand how tenants are consuming resources and imposing load on your system. The real challenge is to figure out which flavors of isolation best align with the compliance, business, operational, performance, and agility of your SaaS organization.
To further explore the details highlighted here, take a look at the new SaaS Tenant Isolation Strategies whitepaper.
Learn More About AWS SaaS Factory
AWS Technology Partners are encouraged to reach out to their AWS Partner Network (APN )representative to inquire about working with the AWS SaaS Factory team. Additional technical and business best practices can be accessed via the AWS SaaS Factory website.
ISVs that are not AWS Partners can subscribe to the SaaS on AWS email list to receive updates about upcoming events, content launches, and program offerings.