Subsystem 01
Edge & routing layer
TLS termination, WAF rate limiting and tenant subdomain resolution
Typical stack
Amazon CloudFront + Cloudflare Workers
Reference architecture
Multi-tenant B2B SaaS reference architecture on AWS
A reference architecture for B2B SaaS on AWS that pools compute and database capacity across tenants, while PostgreSQL row-level security keeps each tenant's data isolated.
Design constraints
What the design has to hold to
Targets for the scenario this reference is sized for. A real engagement starts by replacing them with your own numbers.
- 01No cross-tenant reads, whatever query the application sends
- 02New tenants onboard without provisioning dedicated infrastructure
- 03p95 API latency under 100 ms in every served region
- 04Automated per-tenant usage metering and billing enforcement
Component topology
System components and technologies
Subsystems with separate responsibilities, clear contracts between them and storage that scales on its own. The stack named for each is typical, not mandatory.
Stack topology
Multi-tenant B2B SaaS reference architecture on AWS
Illustrative reference architecture
- 01
Edge & routing layer
TLS termination, WAF rate limiting and tenant subdomain resolution
Amazon CloudFront + Cloudflare Workers
- 02
Application runtime
Pooled containerized microservices that scale with load
Amazon EKS with Karpenter autoscaling
- 03
Data tier
Shared relational database with row-level security policies per tenant
Amazon Aurora PostgreSQL Serverless v2
- 04
Identity & access
Tenant-aware JWT issuance with custom organization claims
Amazon Cognito / Clerk organizations
Subsystem 02
Application runtime
Pooled containerized microservices that scale with load
Typical stack
Amazon EKS with Karpenter autoscaling
Subsystem 03
Data tier
Shared relational database with row-level security policies per tenant
Typical stack
Amazon Aurora PostgreSQL Serverless v2
Subsystem 04
Identity & access
Tenant-aware JWT issuance with custom organization claims
Typical stack
Amazon Cognito / Clerk organizations
Subsystem 05
Observability
Tenant-tagged distributed tracing, metrics and audit logs
Typical stack
OpenTelemetry + Datadog / Grafana Tempo
Data lifecycle
End-to-end data flow
Requests arrive at the CloudFront edge; the tenant ID is taken from the subdomain or the JWT.
A Cloudflare Worker attaches a tenant_id header and forwards the request to the EKS Application Load Balancer.
The service verifies the JWT and sets a transaction-scoped tenant context (SET LOCAL app.current_tenant = 'tenant_123').
PostgreSQL row-level security filters every SELECT, UPDATE and DELETE to that tenant's rows.
Background events go to Amazon EventBridge with tenant metadata for usage metering and billing.
Reliability and resilience
Failure modes and how each is contained
Failure mode 01
Noisy-neighbor compute saturation
Mitigation
Per-tenant token-bucket rate limits in edge Redis, plus EKS pod priority classes for critical workloads.
Failure mode 02
RLS bypassed by the table owner or a privileged role
Mitigation
Set FORCE ROW LEVEL SECURITY on every tenant table, connect as a role without BYPASSRLS, and test the policies with pgTAP in CI.
Failure mode 03
Database connection exhaustion
Mitigation
Put Amazon RDS Proxy in front of Aurora to pool and multiplex connections from every container and serverless function.
Questions
What teams ask about this design
A pooled database costs far less to run than thousands of separate instances, and a schema change is one migration instead of thousands. Row-level security enforces isolation inside PostgreSQL, so a missing WHERE clause in application code cannot expose another tenant's rows.
With a hybrid silo-and-pool model: higher-tier enterprise tenants are routed to dedicated database clusters, while standard tiers share the pooled cluster.
Planning a system like this?
Send us your requirements, expected load and budget. We'll reply within one business day with an honest read on the design, and on whether we're the right team to build it.