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.
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.
Step 1
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.
»
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.
»
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.
»
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.
»
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.
»
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.
»