This Guidance shows customers three different models for handling multi-tenancy in the database tier, each offering a trade-off between tenant isolation and cost and complexity. Tenant isolation is fundamental to the design and development of multi-tenancy applications, particularly software as a service (SaaS) applications. In a multi-tenant architecture, multiple instances of an application operate in a shared environment to achieve cost and operational efficiency. An application operator must safeguard tenant data by making sure it is accessible only to that particular tenant. By offering three models of tenant isolation at the database-level, this Guidance allows customers to choose the right architecture that meets their risk and cost requirements.
Architecture Diagram
Step 1
In the Silo Model, each tenant interacts with an entire application stack dedicated to that tenant. The application stack runs on Amazon Elastic Compute Cloud (Amazon EC2) compute instances. Traffic and data do not cross tenant boundaries.
Step 2
Each tenant's data is stored in an Amazon Relational Database Service (Amazon RDS) database instance dedicated to that tenant. A tenant's data does not mix with other tenants' data.
Step 3
In the Bridge Model, tenants share the complete application stack, reducing cost and complexity.
Step 4
Tenants share the same RDS instance, but each have a dedicated schema.
Step 5
In the Pool Model, tenants share the entire application stack, just as in the Bridge Model.
Step 6
Tenants share the same database instance and objects. Database tables contain data for multiple tenants. Tenant isolation is provided by row-level security features in the database.
Step 1
In the Silo Model, each tenant interacts with an entire application stack dedicated to that tenant. The application stack runs on Amazon Elastic Compute Cloud (Amazon EC2) compute instances. Traffic and data do not cross tenant boundaries.
Step 2
Each tenant's data is stored in an Amazon Relational Database Service (Amazon RDS) database instance dedicated to that tenant. A tenant's data does not mix with other tenants' data.
Step 3
In the Bridge Model, tenants share the complete application stack, reducing cost and complexity.
Step 4
Tenants share the same RDS instance, but each have a dedicated schema.
Step 5
In the Pool Model, tenants share the entire application stack, just as in the Bridge Model.
Step 6
Tenants share the same database instance and objects. Database tables contain data for multiple tenants. Tenant isolation is provided by row-level security features in the database.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
Amazon RDS emits performance and utilization metrics to Amazon CloudWatch. Amazon RDS Performance Insights provides additional visibility through database load data for performance monitoring. Amazon RDS Enhanced Monitoring provides metrics for the operating system of your database instance.
-
SecurityRead the Security whitepaper
Tenant data is isolated from access by other tenants in the following ways: the Silo Model separates tenant data into a database instance per tenant; the Bridge Model isolates tenant data into a dedicated schema per tenant; the Pool Model uses the row-level security features of the database engine.
-
ReliabilityRead the Reliability whitepaper
Amazon RDS creates automated database backups daily and saves them for a defined retention period. You may also create your own database snapshots in Amazon RDS and manage the snapshot lifecycles. In addition, you can still create and manage backups using native and third-party database backup tools. Amazon Aurora, one of the database engines that Amazon RDS supports, stores six copies of data across three Availability Zones. In Aurora, compute is decoupled from storage. Aurora storage also identifies and repairs errors automatically.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
SaaS customers may employ a hybrid architecture, allocating siloed infrastructure to high-traffic customers while co-locating quieter customers in a Bridge or Pool Model. If you have a highly variable workload, you may use Aurora Serverless. Database instances are scaled-to-fit workloads and may be adjusted over time. You may also add read replicas to shift read traffic away from busy writer nodes.
-
Cost OptimizationRead the Cost Optimization whitepaper
Each of the architectural models presented in this Guidance offer a trade-off between tenant isolation and cost. The Silo Model, for example, provides the strongest tenant isolation but incurs the most cost and complexity. Inversely, the Pool Model offers the least tenant isolation but costs the least. SaaS providers may choose hybrid architectures to manage costs and may even offer end users service tiers to allow them to make their own trade-off decisions.
-
SustainabilityRead the Sustainability whitepaper
Tenants in the Silo Model with variable workloads can use Aurora Serverless so that hardware is only applied to their workload when query activity is occurring. Bridge Model and Pool Model tenants minimize hardware provisioning by sharing database instances across tenants, maximizing use of the compute resource.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.