Multi-tenancy means one product serves several customer organizations while preserving isolation, performance, governance, and operability. Azure does not choose the tenancy model for you. Decide separately for identity, application compute, data, encryption, network, model/search resources, observability, deployment, and support access.
Method note: Tenancy and isolation are architecture decisions that must be made before choosing a deployment tool. The service chapters show Portal and automation methods for the resulting resources; no interface can substitute for these product, data, and security boundaries.
Use tiers: small tenants share; regulated or large tenants receive a dedicated stamp. Keep the product experience consistent.
Maintain an authoritative tenant catalog with tenant ID, identity configuration, plan/tier, region/stamp, data stores, keys, feature flags, quotas, lifecycle status, and compliance attributes. Every request derives tenant context from the authenticated identity and trusted routing—not from a user-editable parameter.
The catalog is highly sensitive and critical. Make it resilient, audited, and recoverable.
Support workforce tenants through Entra multitenant application patterns or external identities according to the product. Validate issuer, audience, tenant allowlist/onboarding state, subject, and claims. Map external identities to internal tenant/user records. Administrative support access must be time-bound, approved, logged, and visible.
Do not accept a token from any Entra tenant simply because its signature is valid.
Shared database: every table/document uses a trusted tenant key, with row-level security or repository filters and tests. Database-per-tenant: automate creation, schema migration, backup/restore, key/connection, capacity, and retirement. Use per-tenant encryption keys only when the security value justifies key fleet operations.
For RAG, store tenant/access metadata in every chunk and build the filter server-side. Consider index-per-tenant for high isolation, shared index with filters for efficiency, or stamp-level indexes for balance. Test cross-tenant leakage as a release blocker.
Set quotas by tenant for requests, concurrency, storage, events, search, model tokens, and agent/tool work. Use queue partitioning, fair scheduling, rate limits, circuit breakers, and workload bulkheads. Meter actual usage for billing and capacity.
A stamp is an independently deployable scale unit containing app compute, data/search, messaging, and monitoring for a tenant group/region. Infrastructure as code creates identical stamps. A global control plane places tenants and routes traffic. Upgrade a canary stamp before fleet rollout.
Define maximum tenant count/load per stamp and a rebalancing/migration process before the first stamp fills.