SaaS on AWS: Multi-Tenant Architecture Patterns

Why Multi-Tenancy Is the Central SaaS Architecture Decision

Unlike on-premises software, a SaaS platform typically serves hundreds or thousands of customers simultaneously through shared infrastructure. Multi-tenancy describes how these customers — in cloud terminology: tenants — are technically isolated from one another while using the same software instance.

This decision is fundamental because it affects nearly all other architecture decisions: database design, authentication architecture, cost model, scaling strategy, and compliance documentation. Changing the tenant model after the fact typically involves considerable effort.

Key Terms in Multi-Tenant Architecture

Tenant

A single customer (company or organization) using a SaaS platform. A tenant can have multiple users but is treated as a single unit from an isolation perspective.

Tenant Isolation

A technical guarantee that data and resources of one tenant are not accessible to other tenants. Can be achieved at the infrastructure level, database level, or through encryption.

Noisy Neighbor Problem

A situation in which a single tenant, through intensive use, degrades the performance of other tenants. Occurs primarily in the Pool model and requires active resource throttling.

Row-Level Security (RLS)

A database feature that restricts access to individual table rows based on the identity of the requesting user. Key technology for data isolation in the Pool model.

The Silo Model: Maximum Isolation

In the Silo model, each tenant receives a completely isolated infrastructure. On AWS, this typically means separate AWS accounts per tenant, managed through AWS Organizations and AWS Control Tower.

Advantages

• Strongest data isolation — complete separation at the infrastructure level
• Simple auditability for compliance (ISO 27001, BSI C5, financial regulations)
• No noisy neighbor problem
• Individual customization per tenant possible
• Tenant-specific data residency easily enforceable (e.g., Frankfurt-only for GDPR)

Disadvantages

• Higher infrastructure costs — each tenant bears its own fixed costs
• Complex operations management with many tenants
• Not suitable for freemium models or very many small tenants

AWS Implementation: AWS Organizations with Service Control Policies (SCPs), AWS Control Tower for an account vending machine, separate VPCs and databases per account.

The Pool Model: Maximum Efficiency

In the Pool model, all tenants share the same infrastructure: a shared database, the same EC2 instances or Lambda functions, the same network infrastructure. Isolation is enforced at the application and database level.

Data Isolation in the Pool Model

1. Row-Level Security (RLS): Each table contains a tenant_id column. PostgreSQL or Aurora RLS policies ensure every database query is automatically scoped to the authenticated tenant's rows. Implemented as a database policy: CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::uuid).
2. AWS KMS Customer Managed Keys (CMKs): Each tenant receives a dedicated KMS key. Data is encrypted tenant-specifically, so even with database access, data from other tenants cannot be decrypted.

AWS Implementation: Amazon RDS/Aurora with RLS enabled, Amazon Cognito for tenant identity and JWT claims with tenant ID, AWS KMS for per-tenant encryption, Amazon ECS or Lambda for compute.

The Bridge Model: Balance Between Isolation and Efficiency

The Bridge model (also: hybrid model) combines elements of both approaches. Typically, compute resources are shared (Pool) while database instances are isolated (Silo). Or: Basic-tier customers use shared infrastructure, Enterprise customers receive dedicated resources.

Tenant Identity with Amazon Cognito

Amazon Cognito is the AWS service for authentication and authorization in SaaS applications. Two common approaches for multi-tenant architectures:

1. Shared User Pool with Tenant Claims: A single Cognito User Pool for all tenants. Tenant membership stored as a Custom Attribute (custom:tenantId) in the JWT token. The application extracts the tenant ID from the token and uses it for RLS and resource access.
2. User Pool per Tenant (Silo): Each tenant gets its own Cognito User Pool. Enables individual configuration (own domain, own branding, SAML/OIDC federation with corporate IdP) at higher management overhead.

Automating Tenant Onboarding

Manual tenant onboarding does not scale. Above 50+ tenants, full automation is mandatory. The AWS reference architecture uses:

1. API Gateway + Lambda: REST API receives onboarding request (company name, plan, admin email)
2. Step Functions: Orchestrates the multi-step onboarding process
3. CloudFormation/CDK: Provisions tenant-specific resources (Silo: entire AWS account; Pool: tenant entry in configuration database)
4. Cognito: Creates tenant-specific User Pool or User Pool Client, sends invitation email to admin
5. DynamoDB (Control Plane): Stores tenant configuration: tenant ID, plan, resource IDs, status

Decision Guide: Which Model for Which ISV?

1. Regulated industries (finance, healthcare, public sector): Prefer the Silo model. Strict isolation is a compliance requirement, not just a best practice.
2. Horizontal B2B SaaS with many SME customers: Pool model with RLS and CMKs. Cost efficiency is critical for unit economics.
3. Products with different pricing tiers: Bridge model. Starter in Pool, Enterprise in Silo.
4. PLG model (Product-Led Growth) with freemium: Pool is mandatory. Hundreds of free tenants do not justify Silo infrastructure.

Frequently Asked Questions

What does multi-tenancy mean in SaaS?

Multi-tenancy means a single software instance simultaneously serves multiple customers while keeping their data strictly separated. The separation can be achieved at the database level, infrastructure level, or through encryption.

Which model is suitable for regulated industries?

The Silo model is best for regulated industries. Each tenant receives dedicated AWS resources (separate accounts, own databases), providing the strongest isolation and simplest auditability.

How do I implement Row-Level Security in Amazon Aurora?

Aurora PostgreSQL supports native PostgreSQL RLS. A policy is defined directly on the table: CREATE POLICY tenant_rls ON table_name USING (tenant_id = current_setting('app.tenant_id')::uuid). The application sets the tenant ID for each database connection via SET app.tenant_id = '...'.

Can a tenant use its own Active Directory?

Yes. Amazon Cognito supports SAML 2.0 and OIDC for federation with external identity providers. Tenants can integrate their own Azure AD, Okta, ADFS, or any other SAML-capable IdP. For enterprise customers, this is often a purchase prerequisite.

Storm Reply: SaaS Architecture Consulting for ISVs

Storm Reply is an AWS Premier Consulting Partner in the DACH region with the AWS SaaS Competency. We help ISVs choose and implement the right multi-tenant architecture — from the initial architecture decision to a fully automated tenant onboarding pipeline.

Our architects have hands-on experience with all three tenancy models and understand the specific compliance requirements of the German market: GDPR, BSI C5, BaFin requirements for fintech ISVs, and KRITIS regulations.