The tenant isolation model you choose early shapes security, operations and cost for years. Pool, silo and bridge models compared, and how to choose.
Multi-tenancy is one of those architectural decisions where the wrong early choice is expensive to reverse. We've helped companies migrate between isolation models: it's painful. The right model at launch saves enormous engineering effort later.
Every tenant gets their own AWS account. Maximum isolation, straightforward security model, and easy to give tenants direct AWS console access if needed. The downside is operational complexity at scale — managing 1,000 AWS accounts requires real automation.
Best for: enterprise B2B SaaS where tenants have strict data isolation requirements, or regulated industries where tenant data separation is a contractual or legal requirement.
Shared compute and infrastructure, but tenant data is logically isolated within a shared database. Row-level security, tenant-scoped IAM, and application-level isolation are the primary mechanisms.
This is the most common model and usually the right starting point. Lower operational overhead than silo while maintaining reasonable security properties.
Everything is shared: compute, database, and application layer. Tenant isolation is purely application-level. The lowest cost and simplest operations, but requires rigorous application-level security controls and is difficult to certify for compliance.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Within the bridge model, there are three common database patterns:
Schema-per-tenant: each tenant gets their own PostgreSQL schema in a shared RDS instance. Good for <1,000 tenants. Migration complexity is manageable, cross-tenant queries are naturally prevented.
Row-level security: all tenants share tables, RLS policies enforce isolation at the database level. Scales well, simpler schema management, but requires careful testing of RLS policies.
Database-per-tenant: separate RDS instances per tenant. Maximum isolation, highest cost. Usually only justified for tenants with large data volumes or strict compliance requirements.
The authorization model for multi-tenant SaaS needs to handle: authenticating users, identifying which tenant they belong to, enforcing tenant boundaries, and role-based access within tenants.
Cognito User Pools with custom attributes for tenant ID works well up to moderate scale. Each user pool can serve one or many tenants. Alternatively, a dedicated auth service (or a third-party like Auth0) gives you more flexibility at higher operational cost.
In shared-compute models, one tenant's workload can degrade the experience for others. Mitigation strategies: per-tenant request throttling at API Gateway or ALB, tenant-aware Lambda concurrency limits, database connection pooling with per-tenant limits, and monitoring per-tenant latency percentiles separately.
Tenant context propagated through every request (JWT claims, request headers, trace attributes)
All database queries filtered by tenant_id — never assume current tenant from application state alone
Separate encryption keys per tenant for sensitive data (KMS per-tenant CMKs)
Per-tenant audit logs — who accessed what, when
Tenant onboarding and offboarding automation from the start
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Platform Engineering in 2027: The AWS Stack We Would Choose Today, and Why
If we were starting a product on AWS today and wanted it to still be sensible in 2027, these are the choices we'd make (compute, data, identity, AI, delivery and observability) with the reason for each and the condition that would change our mind.
Read
7 AWS Architecture Mistakes Startups Make That Become Expensive at Scale
These decisions seem fine at 10 users. At 10,000, they're production incidents, security risks, or five-figure monthly bills.
Read
As of December 18, 2024. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.