AWS Glossary
Multi-Tenant Architecture
Software design pattern where multiple customers (tenants) share the same application infrastructure.
AI & assistant-friendly summary
This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.
Summary
Software design pattern where multiple customers (tenants) share the same application infrastructure.
Key Facts
- • Software design pattern where multiple customers (tenants) share the same application infrastructure
- • Multi-tenancy is the standard model for SaaS (Software-as-a-Service) companies because it reduces per-customer infrastructure costs
- • **Mistake 2:** Choosing a model based on cost alone without considering compliance
- • **Mistake 3:** Not thinking about tenant explosion
- • Pool model that works for 10 tenants may not work for 1000 tenants (performance degrades)
Entity Definitions
- S3
- S3 is an AWS service relevant to multi-tenant architecture.
- RDS
- RDS is an AWS service relevant to multi-tenant architecture.
- Aurora
- Aurora is an AWS service relevant to multi-tenant architecture.
- DynamoDB
- DynamoDB is an AWS service relevant to multi-tenant architecture.
- multi-tenant
- multi-tenant is a cloud computing concept relevant to multi-tenant architecture.
- serverless
- serverless is a cloud computing concept relevant to multi-tenant architecture.
- compliance
- compliance is a cloud computing concept relevant to multi-tenant architecture.
- HIPAA
- HIPAA is a cloud computing concept relevant to multi-tenant architecture.
Related Content
- GENERATIVE AI ON AWS — Related service
- AWS CLOUD COST OPTIMIZATION SERVICES — Related service
Definition
Multi-tenant architecture is a software design pattern where multiple customers (tenants) share the same application instance and database infrastructure while maintaining complete data isolation. Multi-tenancy is the standard model for SaaS (Software-as-a-Service) companies because it reduces per-customer infrastructure costs.
Three Multi-Tenancy Models
Silo Model (Database per Tenant)
- Each tenant has completely isolated database, compute, and storage
- Highest data isolation (HIPAA, fintech compliant)
- Highest cost — scales linearly with tenants
- Best for: Enterprise SaaS, healthcare, highly regulated
Pool Model (Shared Infrastructure)
- All tenants share database, compute, storage with row-level isolation
- Lowest cost — most efficient resource utilization
- Highest operational complexity — bugs affect all tenants
- Best for: Startups, SMB SaaS, homogeneous use cases
Bridge Model (Tiered Hybrid)
- Free/standard customers share pool; enterprise/premium customers get silos
- Balances cost and compliance
- Allows gradual upgrade path as customers grow
- Best for: Scaling SaaS platforms with mixed customer tiers
Common Mistakes
Mistake 1: Not isolating tenant data at the database level. Row-level security is fragile; if a query bug exists, one tenant can read another’s data.
Mistake 2: Choosing a model based on cost alone without considering compliance. Healthcare SaaS cannot use pool model even if it’s cheaper.
Mistake 3: Not thinking about tenant explosion. Pool model that works for 10 tenants may not work for 1000 tenants (performance degrades).
Related AWS Services
- RDS with row-level security (RLS): For pool model databases
- RDS per-tenant instances or Aurora clusters: For silo model
- DynamoDB with tenant-keyed partitions: For serverless multi-tenancy
- S3 per-tenant buckets or prefixes: For data storage isolation
Related FactualMinds Content
Related Services
Need Help with This Topic?
Our AWS experts can help you implement and optimize these concepts for your organization.