The Decision That Looks Optional Until It Is Not
Most SaaS founders build their first ten customers on a shared everything stack. One database. One Lambda. A tenant_id column on every table. It works. It is cheap. It ships fast.
Then the eleventh customer is a regulated buyer who wants to know exactly where their data lives, who can read it, and what happens if another tenant gets compromised. That is the conversation where the original architecture decision suddenly costs you six figures of refactoring or, worse, a lost deal.
We have built multi-tenant SaaS on AWS across every isolation pattern there is. Here is the honest breakdown, including which one to start with based on who you are selling to.
The Four Patterns
There are really only four meaningful isolation patterns in production AWS SaaS. Most platforms use a mix.
Pattern 1: Pool (Shared Everything)
Every tenant lives in the same database, same compute, same everything. Isolation is enforced in application code through a tenant_id filter on every query.
When to use: B2C, B2SMB, anything where you have hundreds or thousands of small tenants paying $20 to $200 per month. Tenant 1 and tenant 1000 share infrastructure, and that is the only economically viable way to serve them.
What it costs you: Engineering discipline. One missing tenant_id filter is a cross-tenant data leak. We enforce this with row-level security in Postgres, partition keys in DynamoDB, and middleware that rejects any query missing a tenant scope.
What enterprise buyers will say: "We are not comfortable with our data sitting next to our competitors' data." You will hear this in security review. Sometimes it is a deal blocker, sometimes it is fine if you have the right answers about encryption and access control.
Pattern 2: Bridge (Shared Compute, Isolated Data)
Compute is shared (one Lambda, one ECS cluster, one EKS namespace), but each tenant gets their own database or their own table. Different schemas in the same Postgres cluster, separate DynamoDB tables, or completely separate database instances per tenant tier.
When to use: B2B SaaS where individual tenants are paying $500 to $5000 per month and may ask data residency questions. The compute layer scales economically while the data layer gives you a clean answer to "where exactly does our data live."
What it costs you: More moving parts. Database connection pooling gets harder. Migrations need to run across N databases instead of 1. Backup and restore is more involved.
We use this pattern most often for our Tier 2 builds. It is the sweet spot for production-ready SaaS that needs to grow from 10 to 500 customers without a rewrite. We covered the broader cost picture in How Much Does It Cost to Build a SaaS MVP in 2026?.
Pattern 3: Silo (Isolated Stack Per Tenant)
Every tenant gets their own AWS account, or their own VPC, or their own dedicated stack inside a shared account. Compute, data, networking, all separated.
When to use: Enterprise customers paying $50K+ per year, regulated industries (healthcare, financial services, government), or any deal where the contract literally requires it. This is what FedRAMP and high-tier HIPAA customers expect.
What it costs you: Real money. Per-tenant infrastructure starts at $200 to $500 per month even for an idle tenant. Operations overhead grows linearly with tenant count. Every change becomes a fleet upgrade.
The pricing math only works at enterprise contract sizes. If you are charging $2K per month and running a silo, your margins are gone. If you are charging $20K per month, the silo is rounding error.
Pattern 4: Hybrid (Tier-Based)
Most mature SaaS platforms end up here. Free and SMB tenants live in a pool. Mid-market lives in a bridge. Enterprise lives in silos. Pricing tiers map directly onto isolation tiers.
When to use: Once you have product-market fit and tenants across multiple price points, hybrid is almost always the right answer. The architectural complexity is real, but it lets you serve every customer profitably.
What it costs you: A platform team. You cannot run hybrid as a side effect of two engineers shipping features. Someone owns the deployment pipeline, the cross-tier observability, and the onboarding flow that decides which tier a new tenant lands in.
How to Pick the Starting Pattern
Three questions force the answer.
Who is your first paying customer profile? If they are paying under $500 per month, start in pool. If they are paying $1K to $10K per month, start in bridge. If they are paying $20K+ per month or are in a regulated industry, start in silo.
What does the first enterprise deal look like? If your sales motion is bottom-up and enterprise is a someday problem, do not over-engineer for it. If you are doing top-down enterprise sales from day one, your first design needs to support silos.
How fast can you migrate later? Pool to bridge is achievable but expensive. Bridge to silo is achievable. Pool to silo is essentially a rewrite. The further apart the patterns, the more painful the migration. Build one pattern up from where you are, not down from where you might end up.
What Auditors Actually Check
We have walked clients through dozens of security reviews. The questions auditors ask about multi-tenant isolation are always the same.
Encryption at rest with per-tenant keys. Bonus points if it is customer-managed KMS keys. Pool can do this with envelope encryption. Bridge does it natively. Silo gets it for free.
Network isolation. In a silo, every tenant has their own VPC. In a bridge or pool, the answer is "we use IAM and security groups," and you need to be ready to defend that.
Access controls and audit logging. Every tenant operation needs to be logged with tenant_id, actor, action, timestamp, and outcome. CloudTrail covers the AWS side. Your application audit log covers the rest.
Data export and deletion. GDPR, CCPA, and most enterprise contracts require you to export or delete a tenant's data within a defined window. In silos this is trivial. In pools, you are running tenant-scoped jobs across every table in your database.
Backup and disaster recovery. Cross-tenant restore should not be possible. Tenant-specific point-in-time recovery is a question that comes up in every serious security review.
For more on how to design these guarantees in from the start, see How We Ship SaaS That Passes a Security Review in Weeks, Not Months.
Where We See Founders Go Wrong
Two patterns of failure show up over and over.
Picking silo too early. A pre-revenue startup decides they want to be enterprise-ready, builds a per-tenant CDK stack, and ships nothing for six months because every tenant onboarding is a deploy. The first ten customers were all going to be SMB anyway.
Picking pool too late. A growing startup hits 50 enterprise tenants on a shared Postgres cluster and tries to retrofit row-level security in a Friday sprint. RLS works, but bolting it on under load is a months-long migration that should have been a week of design upfront.
The middle path (bridge, then hybrid) almost always wins in our experience. It buys you the right answers for security review without the operational drag of full silos.
What This Looks Like in AWS
Concrete service patterns we use:
Pool: RDS Postgres or Aurora Serverless with row-level security, single Lambda or ECS service, single CloudFront distribution, tenant_id in every Cognito token.
Bridge: Aurora Serverless with one database per tenant or DynamoDB with tenant-prefixed partition keys, shared Lambda layer, per-tenant secrets in Secrets Manager.
Silo: Per-tenant CDK stack containing VPC, RDS or DynamoDB, Lambda functions, API Gateway, and CloudFront. Deployed via a control plane account that orchestrates onboarding.
Hybrid: Pool tier on the lowest-cost compute, bridge tier with shared compute and isolated data, silo tier with dedicated stacks. A control plane account routes new tenants based on their plan.
For the broader picture of running this on AWS without overspending, see AWS Cost Optimization: 7 Quick Wins That Save Thousands.
A Practical Starting Point
If you are pre-launch and selling to SMBs, start in pool. Get to revenue. Migrate to bridge before customer 50. Plan for hybrid by the time you hit your first $20K+ ACV deal.
If you are pre-launch and selling to enterprise, start in bridge with the silo migration path designed in. You will not need silos on day one, but the data layer should already be tenant-scoped so the migration is mechanical, not architectural.
If you are mid-flight and feeling the pain of the wrong pattern, the next step is a cost and effort audit of the migration. We have run these in two-week sprints that produce a concrete plan and a fixed price for the rebuild.
Get an Honest Assessment
If you are designing a multi-tenant platform from scratch or living with a pattern that is starting to bite, get in touch. We will walk through your customer profile, your roadmap, and your security posture, and tell you which pattern fits your business. Our SaaS development service covers exactly this kind of architecture work, and you can read about how we do it with a small team in Small Team, Big Architecture.