Serverless SaaS
Consider a multi-tenant SaaS product: many customer organizations, unpredictable per-tenant load, and a small team that cannot run servers. The goal is to pay near nothing when tenants are idle, scale instantly when they are not, and keep each tenant's data isolated — all without an operations department.
This is the canonical case for serverless on Azure. Container Apps and Functions provide compute that scales to zero, Cosmos DB or Azure SQL elastic pools provide multi-tenant data, Front Door provides the global edge, and Entra External ID provides customer identity. The architecture's defining decisions are the tenancy model and where the cold-start risk is acceptable.
Compute
Stateless services run on Azure Container Apps, scaling on HTTP concurrency and to zero when a tenant is idle; background and event-driven work runs on Azure Functions. The economics are the point — at zero traffic the bill approaches zero — but any latency-sensitive endpoint sets a minimum of one replica so a cold start never violates a customer's experience.
Customerauthenticated by Entra External ID
Front Doorglobal edge · cache · WAF
Container Appsstateless services, scale on concurrency / to zero
Cosmos DBper-tenant partition or poolData and Tenancy
The tenancy model is the central decision. A database-per-tenant (Azure SQL elastic pool) gives the strongest isolation and is the SaaS pattern elastic pools exist for — idle tenants cost little while the pool absorbs peaks. A shared store partitioned by tenant (Cosmos DB with tenant ID as the partition key) scales further but demands disciplined partition design and query-time tenant filtering to prevent data leaking across tenants. Mind the 20 GB cap per logical partition: a large tenant on a bare tenant-ID key will hit it, so use a synthetic key or hierarchical partition keys for tenants that can grow.
Identity and Edge
Customer sign-up and sign-in run on Entra External ID, keeping tenant identities out of the corporate directory and off the application's shoulders. Front Door fronts the whole product globally — edge TLS, caching for static assets, and a WAF — so customers worldwide hit a nearby edge and the application sees clean, filtered traffic.
Scaling and Cost
The architecture scales per tenant automatically and bills for use, which is what makes a long tail of small or idle tenants economical. The risks are cold starts on scale-to-zero services and a noisy tenant starving shared resources — addressed with minimum replicas on hot paths and per-tenant throughput limits or pool isolation on the data tier.
Database-per-tenant (SQL elastic pool) — Strongest isolation, simple per-tenant operations; the pool keeps idle tenants cheap. Choose it for stronger isolation and moderate tenant counts.
Shared store partitioned by tenant (Cosmos DB) — Scales to very large tenant counts, but requires disciplined partition keys and tenant filtering to prevent cross-tenant leakage.
- Allowing scale-to-zero on a latency-sensitive endpoint, so the first request after idle pays a cold start the customer feels.
- Sharing a data store across tenants without rigorous partition design and tenant filtering, risking data leaking across tenants.
- Provisioning a dedicated database per tenant outside an elastic pool, paying for idle capacity on every small tenant.
- Putting customer identities in the workforce tenant instead of Entra External ID.
- Letting one noisy tenant exhaust shared throughput, degrading every other tenant.
- Skipping the edge (Front Door) so global customers hit a single region with no caching or WAF.
- Run stateless services on Container Apps (scale-to-zero) and background work on Functions; set minimum replicas on hot paths.
- Choose the tenancy model deliberately — elastic pools for isolation, partitioned Cosmos DB for very large scale.
- Enforce tenant isolation at the data layer with partition keys and query-time filtering, and test for leakage.
- Use Entra External ID for customer identity and Front Door for global edge, caching, and WAF.
- Apply per-tenant throughput limits or pool isolation so a noisy tenant cannot starve the rest.
- Let the architecture bill for use, making the long tail of idle tenants economical.
Knowledge Check
Why are Azure SQL elastic pools well suited to a database-per-tenant SaaS?
- Tenants share a resource budget, so idle tenants stay cheap while the pool absorbs peaks — with strong per-tenant isolation
- They give each tenant a dedicated, always-on set of provisioned vCores that the tenant pays for around the clock whether idle or busy
- They remove the need for any tenant data isolation at all
- They are the only Azure store that can scale all the way to zero
What is the risk of scale-to-zero on a SaaS latency-sensitive endpoint?
- The first request after idle pays a cold start; set a minimum of one replica to avoid it
- Scale-to-zero deletes the tenant's stored data whenever the endpoint sits idle for a while
- It forces the app onto a database-per-tenant model
- It disables the Front Door WAF entirely
What must a shared, tenant-partitioned data store get right to be safe?
- Partition-key design and query-time tenant filtering, to prevent data leaking across tenants
- A separate dedicated Azure region for every single tenant
- Disabling Front Door caching across the whole storefront
- Storing all of the tenants together inside one shared logical partition with a single key
You got correct