# Definitions The AWS Well-Architected Framework is based on six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. SaaS adds a new dimension of considerations to each of these pillars. The multi-tenant nature of SaaS applications, requires architects to reconsider how they address security, operational efficiency, stability, and agility of their SaaS environments. In this section, we will present an overview of the SaaS concepts that will be used throughout this document. There are 10 areas you should consider when building a SaaS architecture. **Topics** + [ # Tenant ](tenant.md) + [ # Silo, Pool, and Bridge Models ](silo-pool-and-bridge-models.md) + [ # SaaS Identity ](saas-identity.md) + [ # Tenant Isolation ](tenant-isolation.md) + [ # Data Partitioning ](data-partitioning.md) + [ # Noisy Neighbor ](noisy-neighbor.md) + [ # Tenant Onboarding ](tenant-onboarding.md) + [ # Tenant Tiers ](tenant-tiers.md) + [ # Tenant Activity and Consumption ](tenant-activity-and-consumption.md) + [ # Tenant-Aware Operations ](tenant-aware-operations.md) # Tenant A tenant is the most fundamental construct of a SaaS environment. As a SaaS provider building an application, you are making this application available to your customers. Any customer that you sign up to use your SaaS environment is one of the tenants of your system. The sum total of all the customers using your SaaS environment are the tenants. Imagine, for example, that your organization has created an accounting service that you want to make available to other companies that will use your service to manage their businesses. Each one of these companies would be viewed as a tenant of your system. Upon signing up, a tenant will typically provide user information for the tenant administrator. This tenant administrator can then log into the system and configure it based on the needs of their business. This includes having the ability to add users to a given tenant environment. The software that is provided in this model is referred to as a multi-tenant SaaS system because each of the tenants of the service are consuming a single, shared system that supports the needs of these tenants through a unified experience. An update to the system, for example, would typically be applied to all tenants of that system. # Silo, Pool, and Bridge Models SaaS applications can be built with a variety of different architectural models. Regulatory, competitive, strategic, cost efficiency, and market considerations all have some influence on the shape of your SaaS architecture. At the same time, there are strategies and patterns that are applied when defining the footprint of a SaaS application. These patterns fall into one of three categories—silo, bridge, and pool. The **silo model** refers to an architecture where tenants are provided dedicated resources. Imagine, for example, as SaaS environment where each tenant of your system has a fully independent infrastructure stack. Or, perhaps each tenant of your system has a separate database. When some or all of a tenant’s resources are deployed in this dedicated fashion, we refer to this as a silo model. It’s important to note that—even though the silo has dedicated resources—a silo environment still relies on a shared identity, onboarding, and operational experience where all tenants are managed and deployed via a shared construct. This differentiates SaaS from a managed service model where customers might be running separate versions of your product with separate onboarding, management, and operational experiences. In contrast, the **pool model** of SaaS refers to a scenario where tenants share resources. This is the more classic notion of multi-tenancy where tenants rely on shared, scalable infrastructure to achieve economies of scale, manageability, agility, and so on. These shared resources can apply to some or all of the elements of your SaaS architecture, including compute, storage, messaging, etc. The final pattern is the **bridge model**. *Bridge* is meant to acknowledge the reality that SaaS businesses aren’t always exclusively silo or pool. Instead, many systems have a mixed mode where some of the system is implemented in a silo model and some is in a pooled model. For example, some microservices in your architecture might be implemented with silo and others might use pool. The regulatory profile of a service’s data and its noisy neighbor attributes might steer a microservice to a silo model. Meanwhile the agility, access patterns, and cost profile of another microservice could tip it toward a pool model. # SaaS Identity Most systems already rely on an identity provider for authentication. In the world of SaaS, we need to extend the notion of identity to incorporate tenancy into our definition of identity. This means that, after authenticating a user, we need to know who the user is as well as which tenant that user is associated with. This merging of the user identity with the tenant identity is referred to as a SaaS identity. This concept is a foundational element of a SaaS architecture, providing the tenant context that is used to implement the underlying multi-tenant policies and strategies that are part of a SaaS application. # Tenant Isolation Tenant isolation is one of the foundational topics that every SaaS provider must address. As independent software vendors (ISVs) make the shift toward SaaS and adopt a shared infrastructure model to achieve cost and operational efficiency, they also have to take on the challenge of determining how their multi-tenant environments will ensure that each tenant is prevented from accessing another tenant’s resources. Crossing this boundary in any form would represent a significant and potentially unrecoverable event for a SaaS business. While the need for tenant isolation is viewed as essential to SaaS providers, the strategies and approaches to achieving this isolation are not universal. There are a wide range of factors that can influence how tenant isolation is realized in any SaaS environment. The domain, compliance, deployment model, and the selection of AWS services all bring their own unique set of considerations to the tenant isolation story. Regardless of how the isolation is implemented, each SaaS architecture needs to ensure that it has put in place the constructs that are needed to ensure that each tenant’s resources have been effectively isolated. # Data Partitioning As you look at different architecture patterns for representing multi-tenant data, you must make choices about how that data is organized. Will the data be stored in separate database, for example, or will it be comingled in a shared construct? These multi-tenant storage mechanisms and patterns are typically referred to as data partitioning. # Noisy Neighbor Noisy neighbor is a term that is often applied to general architecture patterns and strategies. The idea behind noisy neighbor is that a user of a system could place load on the system’s resources that could have an adverse effect on other users of the system. The end result could be that one user could degrade the experience of another user. This concept has expanded relevance in a multi-tenant environment where tenants may be consuming shared resources. Adding to the complexity here is that workloads in a multi-tenant environment can be unpredictable. The combination heightens the need for SaaS architectures to employ their own strategies that can manage and minimize the potential impacts of noisy tenants. # Tenant Onboarding SaaS applications rely on a frictionless model for introducing new tenants into their environment. This often requires the orchestration of a number of components to successfully provision and configure all the elements needed to create a new tenant. This process, in SaaS architecture, is referred to as tenant onboarding. It’s important to note that tenant onboarding can be initiated directly by tenants or as part of a provider-managed process. # Tenant Tiers A SaaS application is often architected to support a range of market segments, providing separate pricing and experiences to a spectrum of customer profiles. These profiles are often referred to as tiers. Supporting the varying needs of these different tiers means introducing architectural constructs that can shape the experience of each tier. These tiering models can influence the cost, operations, management, and reliability footprint of a SaaS solution. # Tenant Activity and Consumption In multi-tenant SaaS environments, it’s important to have visibility into how tenants are using your application and imposing load on your system’s architecture. Tracking this information at the tenant level allows you to assess your system’s ability to effectively scale and support the constantly evolving workloads being placed on your environment. The metrics and insights that are collected from a SaaS system are frequently referred to as tenant activity and consumption. ## Metering and Billing SaaS products are often sold in a pay-as-you-go model where the cost of a product is determined based on the consumption profile of a customer. This model allows customers to have a pricing model that is more tightly coupled to the value and load they are placing on a SaaS system. In this mode, SaaS providers will define and introduce metering mechanism that will measure consumption. This metering data is typically sent to a billing system that aggregates the billing information and generates a bill. Consumption-based pricing represents one model for pricing that can be combined with additional pricing strategies (subscription, for example). # Tenant-Aware Operations The operations experience for SaaS environments introduces the need for additional mechanisms and tooling that can be used to create tenant-aware insights into the activity and consumption patterns of individual tenants and tiers. The idea here is that SaaS providers need to be able to view system activity and health through the lens of individual tenants and tenant tiers. This is essential to diagnosing and evaluating the trends and patterns of activity and consumption for individual tenants.