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

Download the architecture diagram PDF 

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.

  • 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.

    Read the Operational Excellence 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.

    Read the Security 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.

    Read the Reliability 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.

    Read the Performance Efficiency 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.

    Read the Cost Optimization 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.

    Read the Sustainability whitepaper 

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.

AWS Architecture


This post demonstrates how...


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.

Was this page helpful?