Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasServerless multi-tenant SaaS AWS architecture diagram with CloudFront, WAF, Cognito, API Gateway, Lambda, EventBridge, SQS, DynamoDB Streams, and S3. The image links to a fully editable BuildPlane starter.
Overview
A multi-tenant SaaS backend built entirely on serverless primitives. Requests enter through an edge-cached, WAF-protected API, authenticate against Cognito, and run in a per-tenant Lambda service. Domain events flow through EventBridge into a queued worker, while DynamoDB (with Streams) and S3 hold durable state and assets.
Components
- Edge + API: CloudFront and WAF front an API Gateway REST surface with tenant-scoped usage plans.
- Identity: Cognito issues JWTs carrying the tenant claim used for authorization and data partitioning.
- Async Workflows: EventBridge decouples writes from work; an SQS queue (with dead-letter redrive) feeds an idempotent worker Lambda.
- Tenant Data: A single DynamoDB table with Streams drives change-data workflows; S3 holds per-tenant assets.
- Operations: The worker owns durable writes so retries stay idempotent and the read model is rebuildable from the stream.
Request Flow
- A user hits CloudFront, which forwards API traffic through WAF to API Gateway.
- API Gateway authorizes with Cognito and invokes the tenant API Lambda.
- The tenant Lambda publishes a domain event to EventBridge.
- EventBridge enqueues work; the worker persists tenant state to DynamoDB and writes assets to S3.
- DynamoDB Streams captures the change for downstream projections.
Customize First
- Choose your tenant isolation model (pool, bridge, or silo) and adjust data partitioning accordingly.
- Wire the DynamoDB stream to an OpenSearch projection or a metering pipeline as your read path grows.
- Add a billing webhook handler (e.g. Stripe) and SES for transactional email as separate integrations.
Design rationale
Decisions that shape this architecture
Carry tenant identity through every boundary
Cognito claims identify the tenant, but API authorization, event payloads, database keys, object prefixes, logs, and metrics must preserve that context consistently.
Separate request acceptance from durable work
The API publishes a domain event instead of performing every downstream action synchronously. EventBridge routes the event and SQS provides retryable worker delivery.
Choose an explicit tenant-isolation model
A pooled DynamoDB table can scale efficiently, but partition keys and IAM conditions must prevent cross-tenant access. Higher-isolation customers may justify bridge or silo variants.
Before production
Operational checks
Test cross-tenant authorization at the API, worker, table, and object-storage layers.
Make asynchronous writes idempotent and define dead-letter redrive ownership.
Meter usage by tenant without placing billing work in the request path.
Track noisy-neighbor signals such as per-tenant throttling and queue depth.
Scope and tradeoffs
What this diagram does not solve
Serverless does not remove tenancy design
Isolation, quotas, migrations, noisy neighbors, support access, and tenant deletion still require deliberate product and data policies.
The diagram is a backend baseline
Billing, transactional email, search projections, analytics, deployment pipelines, and administrative support flows should be added as distinct integrations when required.
Common questions
Frequently asked questions
How should tenant data be partitioned in DynamoDB?
A common pooled model includes the tenant identifier in partition keys and every access pattern. The exact key design must follow the product queries and isolation requirements.
Why use both EventBridge and SQS?
EventBridge routes domain events to interested destinations. SQS gives a worker durable buffering, backpressure, retry control, and dead-letter handling.
Can this architecture support enterprise tenants?
It can be extended for enterprise requirements, but stronger isolation, audit, networking, key management, and support-access controls may require bridge or silo deployments.
Keep exploring
Related AWS architectures
Secure Application Authentication with Amazon Cognito
This architecture separates identity verification from application authorization. Cognito authenticates the user, API Gateway validates the presented token, Lambda enforces business rules, and DynamoDB remains behind the application boundary.
Explore the architecture
Event-Driven Order Processing Architecture on AWS
This design accepts an order through an authenticated API, publishes a durable domain event, and uses a saga to coordinate payment, inventory, fulfillment, and notification. It separates request latency from business processing while preserving explicit recovery paths.
Explore the architecture
Production-Grade Highly Available Web Platform on AWS
This reference expands the three-tier baseline with a global edge, separate scaling domains, caching, read scaling, private egress, secrets, backups, and operations. It is intended for teams evaluating a conventional production web platform rather than a minimal learning diagram.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.