Building Multi-Tenant SaaS on Serverless: A Case Study on AWS Architecture
Learn how to build an enterprise-grade multi-tenant SaaS on AWS Serverless. Discover tenant isolation, reference-based secrets, extension systems, and audit-ready compliance in this real-world case study.
Introduction: Why Multi-Tenant SaaS on Serverless is Hard
Scaling a SaaS product on serverless infrastructure sounds ideal: pay-per-use, minimal idle compute, and fast deployments. But when multiple tenants share a stack, challenges emerge: traffic spikes affect other tenants, secrets leak, and deployments risk breaking production.
In this post, we present a real-world case study of building a multi-tenant SaaS on AWS Serverless that balances developer velocity, tenant isolation, and audit-ready compliance.
The Challenges of Multi-Tenant SaaS on Serverless
Many serverless applications start simple:
One database
One database
Shared secrets
Many serverless applications start simple:
Tenant traffic spikes affect others
Secrets are shared, and auditing is impossible
Feature deployment conflicts risk all tenants
Our solution needed to:
Treat each tenant as a separate fault domain
Rotate secrets without redeploying
Ship new features as modular extensions
Generate compliance artifacts on demand
Our Approach: Enterprise Serverless Architecture on AWS
We built our solution using Serverless Framework v4 for fast deployment, then added an enterprise layer for isolation, secrets, and modularity.
1. Orchestrator (Control Plane)
Manages tenant lifecycle, billing webhooks, and telemetry.
Does not execute tenant workloads.
2. Tenant Stacks (Execution Plane)
Each tenant has a dedicated stack: Lambda, API Gateway, DynamoDB.
Provides full IAM, data, and secret isolation.
3. Reference-Based Secrets
Secrets stored as pointers in AWS SSM or Secrets Manager.
Resolved at runtime with TTL caching and webhook-driven rotation.
Eliminates redeploys during secret updates.
4. Extension System
Modular architecture with handlers, services, and models.
Auto-loaded per tenant at startup.
Example: Avalara ↔ Cetec ERP integration added without modifying core code.
5. Tenant-Aware Observability
Logs, metrics, and health endpoints are tenant-scoped.
Audit trails exportable in minutes.
Reference-Based Secrets in Multi-Tenant SaaS
Instead of embedding secrets in environment variables:
{
"avalara": {
"account_id": "ssm:/prod/tenants/acme/avalara/account_id",
"license_key": "secretsmanager:avalara-acme-secrets:license_key"
}
} At runtime:
TTL caching reduces AWS calls.
Tenant-specific IAM prevents cross-tenant access.
Webhook rotation updates secrets in under 1 second.
Extension System: Adding Features Without Risk
Traditional Flask apps require modifying core files, causing merge conflicts. Our system:
Scans extensions/handlers/ at startup.
Registers each blueprint in tenant context.
Each extension manages its own secrets and IAM.
Outcome: Entire Avalara ↔ Cetec integration added as three extensions, no core modifications required.
Real-World Results: Multi-Tenant SaaS Metrics
8 active tenants, ~12K API calls/month.
16 API keys rotated via webhook, zero downtime.
Deployment frequency: 2–3x/week (extensions only).
AWS cost: ~$21/month (~$2.63/tenant).
Peak throughput: 2,000 req/s per tenant without affecting others.
Lessons Learned from Building Enterprise Serverless SaaS
Validate secret references on write – avoids cache errors.
Cap caches with LRU – prevents memory bloat.
Treat pagination as first-class – external APIs may return 50K+ records.
Match local to production environment – DynamoDB Local mirrors prod.
Serve OpenAPI docs from API Gateway – ensures compliance and contract fidelity.
When to Use This Architecture
Ideal For:
B2B SaaS (10–10,000+ tenants).
High-compliance environments (SOC2, HIPAA, GDPR).
Variable per-tenant traffic.
Credential isolation and rotation needs.
Not Ideal For:
Consumer apps with millions of users.
Small internal tools (<10 users).
Stateful apps (WebSockets, long-lived connections).
Key Takeaways
Dedicated stack per tenant → predictable, isolated deployments.
Reference-based secrets → rotate safely without redeploys.
Extensions run in tenant context → ship features safely.
Audit-ready compliance → IAM, secrets, logs, and contracts exportable.
We call this approach “sovereign architecture”: boundaries you can prove, scale you can trust, and developer velocity you don’t have to apologize for.
Next Steps
Explore the Serverless Multi-Tenant SaaS Repository.
Deploy a new tenant in one command:
TENANT_ID=acme serverless deploy –stage acme