SaaS architecture pattern
Multi-Tenant SaaS on AWS — Pool, Silo, and Bridge
The isolation model you pick determines your cost ceiling, your security posture, and how easily you can sell to enterprise. Here is how we choose between pool, silo, and bridge in real engagements.
Last updated: April 30, 2026 Author: FactualMinds AWS Architects Reviewed by: Palaniappan P · AWS Solutions Architect — Professional
Problem
Most SaaS teams adopt a 'pool' multi-tenant architecture by default and only realize at Series B that some enterprise customers contractually require silo (single-tenant) isolation, while finance cannot answer 'what does Customer X cost us per month?'. Retrofitting tenant isolation and per-tenant cost attribution under deal pressure is expensive.
Solution
Pick the isolation model up-front based on your customer mix, and instrument tenant attribution from day one. Use AWS-native primitives — IAM tag conditions, Cognito user pools, EKS namespaces with IRSA, AWS Split Cost Allocation Data, and Bedrock per-tenant inference profiles — to make the isolation model load-bearing without inventing your own multi-tenancy framework.
AWS services in this pattern
| Service | Role |
|---|---|
| Amazon Cognito User Pools | Tenant identity provider; Cognito groups represent tenants; custom claims carry tenant_id into JWTs |
| API Gateway / Application Load Balancer | Edge entry point; tenant_id from JWT routes to the appropriate compute and authorizes downstream calls |
| Amazon ECS Fargate or EKS Auto Mode | Application compute; ECS tasks tagged by tenant_id for cost attribution; EKS uses namespace-per-tenant for silo |
| Amazon Aurora (Serverless v2 or Provisioned) | Pooled database with row-level security via tenant_id column; silo tenants get dedicated cluster |
| Amazon DynamoDB | Pooled item-collection-per-tenant pattern using tenant_id as partition key prefix |
| Amazon S3 | Per-tenant prefix in shared bucket (pool) or per-tenant bucket (silo); IAM tag-based policies enforce isolation |
| AWS KMS | Per-tenant customer-managed key for silo tier; shared key with grants for pool tier |
| AWS Split Cost Allocation Data | Per-tenant cost attribution for ECS, EKS, Lambda, and shared services |
| Amazon Bedrock with Inference Profiles | AI feature isolation — separate per-tenant inference profiles for spend caps and audit |
| AWS WAF + Shield Advanced | Per-tenant rate limiting, geo-match, and DDoS protection at the edge |
Architecture components
Pool tier
Shared compute, shared database with row-level security, shared KMS key. Cheapest, scales fastest, most multi-tenant noise risk.
Silo tier
Dedicated VPC, dedicated database cluster, dedicated KMS key. Most expensive, needed for regulated or enterprise contracts.
Bridge tier
Shared compute, but dedicated database and KMS key. Middle ground — cheaper than silo, more isolated than pool.
Tenant context
JWT claim from Cognito carries tenant_id through every request; downstream services use it for routing and authorization.
Cost attribution
Mandatory tenant_id tag on every resource via SCP; Split Cost Allocation Data exposes per-tenant unit cost in CUR 2.0.
Noisy-neighbor controls
WAF rate-based rules per tenant, ECS task quotas per tenant, RCU/WCU caps on DynamoDB per tenant via reserved capacity.
Why this pattern
Multi-tenancy is the single architectural decision that determines whether your SaaS scales economically or collapses under per-customer cost. The pool/silo/bridge framework, originated by AWS SaaS Factory, is genuinely the right shape — but the AWS service landscape has changed enough since 2019 that the old recommendations need updating.
This pattern reflects how we deploy multi-tenant SaaS in 2026: Cognito for identity, Aurora Serverless v2 (or DSQL where horizontal scale is needed) for pooled data, EKS Auto Mode or ECS Fargate for compute, and Split Cost Allocation Data for the per-tenant cost picture finance asks for at every board meeting.
Choosing the tier
| Signal | Pool | Bridge | Silo |
|---|---|---|---|
| ACV under $5K | ✅ | ||
| ACV $5K–$25K | ✅ | ✅ | |
| ACV over $25K | ✅ | ✅ | |
| Enterprise data isolation contract | partially | ✅ | |
| Data residency or sovereignty requirement | ✅ | ||
| Noisy-neighbor risk between tenants | ✅ | ✅ | |
| One tenant 10x larger than others | ✅ | ✅ | |
| Need fastest possible onboarding | ✅ |
What “tenant context everywhere” looks like
Every layer of the stack reads tenant_id from the JWT and uses it as a filter:
- API Gateway authorizer / ALB Lambda authorizer: validates JWT, returns tenant_id as request context
- Application middleware: injects tenant_id into the database session (Postgres
SET app.tenant_id = ...) - Aurora row-level security: every table has a
tenant_idcolumn; RLS policies enforcetenant_id = current_setting('app.tenant_id') - DynamoDB: tenant_id is the partition key prefix; every Query/GetItem operation is scoped
- S3: per-tenant prefix; IAM policy uses
${aws:RequestTag/tenant_id}condition to enforce - Bedrock: per-tenant inference profile; spend caps and audit per tenant_id
The discipline is the architecture. There is no AWS service that automatically enforces tenant isolation in pool — you build it once and audit it forever.
Where this pattern shows up in our consulting
We deploy this pattern most often in AWS Architecture Review engagements at Series A through Series C SaaS companies, when the founders realize that an enterprise contract is gated on isolation guarantees they did not design for. The cost optimization story usually rides along — once tenant attribution is in place, cost optimization recommendations become tenant-specific instead of org-wide averages.
Trade-offs
Pro
Pool tier is 5–10x cheaper per tenant than silo at scale, with much faster onboarding (no provisioning).
Con
Pool tier requires disciplined engineering — every query, cache key, and S3 path must include tenant_id. One missed filter is a data-leak incident.
Pro
Silo tier passes enterprise procurement and compliance reviews instantly — single-tenant isolation is what auditors expect.
Con
Silo tier infrastructure cost grows linearly with customers; per-tenant CI/CD and operations overhead is significant.
Pro
Bridge tier is the realistic answer for most SaaS — pooled compute gives the cost benefit, dedicated database satisfies "we need our data isolated" enterprise asks.
Con
Bridge tier is more complex to operate than pure pool — you maintain N database clusters at provision-time + a connection-routing layer.
Cost notes
Pool tier typically lands at 30–60% of silo cost at the same revenue. The break-even point depends on your average ACV: if you sell at $50K+ ACV, the silo cost is usually a rounding error and worth offering on the high tier. Below $10K ACV, silo is rarely defensible — sell pool to everyone and offer bridge for a 2x price uplift. Set the explicit per-tenant cost ceiling for your pool tier (e.g., $200/month) and route any tenant exceeding it to bridge.
Consulting engagements that deliver this pattern
AWS Well-Architected Review — Free Assessment
Free AWS Well-Architected Review from FactualMinds. Identify risks, compliance gaps, and optimization opportunities.
AWS Cost Optimization & FinOps Consulting
AWS cost optimization and FinOps consulting from FactualMinds — reduce spend by 20-40% with expert right-sizing and strategy.
AWS Application Modernization — From Legacy to Cloud-Native
AWS application modernization — legacy migration, microservices, containers. Expert consulting from FactualMinds.
Deep dives
Frequently asked questions
When should we move from pool to silo?
When customer ACV crosses ~$25K, when a deal explicitly requires single-tenant isolation, or when your pool tier hits a noisy-neighbor incident that costs more to remediate than the silo infrastructure for that customer would have cost in a year. Most SaaS we work with end up running all three tiers concurrently with explicit pricing tied to the tier.
Can we mix pool databases with silo compute, or vice versa?
Yes — that's the bridge model. Pooled ECS or EKS compute talking to dedicated Aurora clusters per tenant gives most of the isolation enterprise asks for at half the cost of full silo. The connection-routing layer (a Lambda authorizer or middleware that picks the cluster based on tenant_id) is the only new component.
How do we handle per-tenant cost when our compute is pooled?
AWS Split Cost Allocation Data attributes EKS, ECS, and Lambda costs to tenants based on tags or namespaces. For shared databases, the pattern is to record per-tenant query cost (RCU/WCU for DynamoDB, query duration for Aurora) at the application layer and expose it via CUR 2.0 cost categories. Once that pipeline is wired up, Cost Optimization Hub recommendations automatically respect tenant boundaries.
What about the database — pooled or silo?
For most B2B SaaS, pooled Aurora with row-level security is the correct default. Switch to silo Aurora clusters only when (a) a customer contractually requires it, (b) data residency rules force it, or (c) one tenant has an order-of-magnitude bigger workload than others. Silo databases at low ACV are a finance trap.
How does this pattern interact with our compliance posture (HIPAA, SOC 2)?
For HIPAA, the BAA covers the pool — you do not need silo to be HIPAA-compliant on AWS, but every shared component must be HIPAA-eligible and your tenant_id-based access controls must be airtight. SOC 2 Type 2 cares more about the controls themselves (least-privilege IAM, encryption, audit logs) than about isolation tier. For both, a documented control map at each tier is more important than the tier choice.
Want this pattern deployed end-to-end?
Our team builds these patterns in production for SaaS, healthcare, fintech, and enterprise customers. Tell us your constraints and we'll scope the engagement.