1. What Is Multi-Tenancy?
Multi-tenancy means a single instance of software serves multiple customers (tenants). Each tenant's data and configuration are logically isolated even though they share underlying infrastructure. SaaS vendors need it to amortize cost, simplify operations, and ship features once for everyone.
- Tenant — an organization (not a single user) that subscribes to the service.
- Isolation — guarantees one tenant cannot access another's data or impact their performance.
- Customization — per-tenant branding, feature flags, or configuration without code forks.
2. Tenant Isolation Models
direction: LR
[Shared Everything|App + DB shared|Low cost, low isolation] --> [Shared App / Separate DB|Same code, per-tenant DB|Medium cost, good isolation]
[Shared App / Separate DB] --> [Shared Infra / Separate App|Per-tenant deployment|Higher cost, strong isolation]
[Shared Infra / Separate App] --> [Fully Isolated (Silo)|Per-tenant subscription|Highest cost, max isolation]
Most SaaS platforms use a hybrid: shared pool for free/standard tiers and isolated deployments for enterprise tenants.
3. Data Partitioning
| Strategy | How | Pros | Cons |
|---|---|---|---|
| Row-level (tenant_id) | Single DB, WHERE tenant_id = @t | Cheapest, easiest migrations | Risk of cross-tenant leaks, noisy neighbor |
| Schema-per-tenant | Same DB server, separate schemas | Logical isolation, shared compute | Schema drift, limited to ~hundreds |
| Database-per-tenant | Elastic Pool with per-tenant DBs | Strong isolation, easy backup/restore per tenant | Cost grows linearly, connection management |
| Cosmos DB partition key | partitionKey = tenantId | Automatic throughput isolation, global distribution | 400 KB doc limit, cross-partition queries expensive |
Row-Level Security (RLS) in Azure SQL enforces tenant_id filtering at the engine level — even if app code has a bug, the DB blocks cross-tenant reads.
4. Compute Isolation
- Shared App Service Plan — all tenants in one plan; cheapest but noisy-neighbor risk.
- Per-tenant deployment slots — logical separation on same plan; useful for canary per tenant.
- Per-tenant AKS namespace — resource quotas + network policies isolate workloads.
- Per-tenant subscription (silo) — maximum blast-radius containment; required for regulated tenants.
5. Identity & Onboarding
- Register a multi-tenant Entra ID app (accounts in any organizational directory).
- On first sign-in, the admin consent flow provisions a service principal in the tenant's directory.
- Store per-tenant config (theme, feature flags, custom domain) in a tenant catalog (Cosmos DB or SQL).
- Use custom claims or app roles to enforce tenant-scoped authorization in APIs.
6. Scaling & Noisy Neighbor Prevention
- Elastic Pools — set per-database DTU min/max so one tenant can't starve others.
- Cosmos DB autoscale — RU/s scales per partition (tenant); hot partitions don't block cold ones.
- API Management rate limiting — per-subscription (tenant) throttling policies.
- KEDA per-queue scaling — each tenant's Service Bus queue triggers its own scaler; burst in one queue doesn't delay others.
- AKS resource quotas — CPU/memory limits per namespace prevent runaway workloads.
7. Billing & Metering
Track per-tenant consumption to support usage-based pricing:
- API Management — built-in analytics per subscription key = per tenant.
- Custom metering — emit events to Event Hubs → Stream Analytics → billing DB.
- Azure Cost Management tags — tag resources with tenant ID for chargebacks in silo model.
- Marketplace metered billing API — report custom meters to Azure Marketplace for ISV offers.
8. Isolation Model Comparison
| Model | Cost | Security | Complexity | Best For |
|---|---|---|---|---|
| Shared everything | ★☆☆ | ★★☆ | ★☆☆ | Free tier, internal tools |
| Shared app / separate DB | ★★☆ | ★★★ | ★★☆ | Standard B2B tenants |
| Shared infra / separate app | ★★★ | ★★★ | ★★★ | Premium tenants needing custom config |
| Fully isolated (silo) | ★★★★ | ★★★★ | ★★★★ | Regulated enterprise, government |
9. Real-World: B2B SaaS with 500 Tenants
direction: TB
[Shared Pool (480 tenants)|App Service Plan P3v3|Elastic Pool 1000 DTU|Row-level security] --> [API Management|Per-tenant subscription keys|Rate limiting: 100 req/s]
[Isolated Tier (20 enterprise)|Dedicated AKS namespace per tenant|Database-per-tenant|Private endpoints] --> [API Management]
[API Management] --> [Tenant Catalog (Cosmos DB)|Routing + config + feature flags]
[API Management] --> [Event Hubs|Usage metering stream]
📦 Architecture
- 480 small tenants share an App Service plan + Elastic Pool with RLS; cost ~$0.50/tenant/month infra.
- 20 enterprise tenants get dedicated AKS namespaces + database-per-tenant + private endpoints; ~$200/tenant/month.
- A tenant catalog in Cosmos DB routes requests and stores per-tenant config (theme, domain, tier).
- API Management enforces per-tenant rate limits and emits metering events to Event Hubs.
- Promotion path: when a tenant upgrades from Standard → Enterprise, a Bicep template provisions isolated resources and migrates data overnight.
10. Exam Tip
AZ-305 frequently asks: "How do you prevent one tenant from impacting others?" The answer is almost always per-tenant throttling (APIM policies or Cosmos DB partition-level RU limits) combined with Elastic Pool per-database DTU caps. Know that Row-Level Security prevents data leaks while rate limiting prevents performance leaks.