Skip to main content

AWS Solutions Library

Guidance for Multi-Tenant Architectures on AWS

Overview

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.

How it works

These technical details feature an architecture diagram to illustrate how to effectively use this solution. The architecture diagram shows the key components and their interactions, providing an overview of the architecture's structure and functionality step-by-step.

Download the architecture diagram

Well-Architected Pillars

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 »

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.