Skip to content

CONCEPT Cited by 3 sources

Tenant isolation

What it is

Tenant isolation in a multi-tenant SaaS is the property that one tenant's users, data, and policies are strictly inaccessible to other tenants — enforced at every layer where cross-tenant leakage is possible (identity, authorization, compute, storage, network).

This is a layered property: a correctly isolated system enforces tenant boundaries redundantly, so a bug in any single layer cannot leak across tenants.

Isolation layers (Convera's shape)

  1. Identity layer. Tenant-specific Cognito pool with a custom tenant_id attribute on each user. Users physically cannot be a member of another tenant's pool.
  2. Token layer. Pre-token hook injects tenant_id into the JWT claim at issue time, fetched from a DynamoDB user → tenant mapping. The tenant binding is now cryptographically signed inside the token.
  3. Authorization layer. A [[patterns/per-tenant-policy-store|per-tenant AVP policy store]]. Policies are physically separate; a policy in tenant A's store cannot refer to resources in tenant B's. Authorizer looks up tenant_id → policy-store-id in DynamoDB and calls AVP against the tenant-specific store.
  4. Request-routing layer. API Gateway forwards to backend Kubernetes pods with tenant_id in a custom request header.
  5. Data layer. Backends re-validate with AVP (patterns/zero-trust-re-verification) against the tenant's policy store before hitting RDS; RDS is "configured to accept only requests with specific tenant context and returns data specific to the requested tenant_id."

Even if upstream layers are compromised or buggy, the RDS-side tenant-context enforcement is the last line of defense.

(Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization)

Key decisions

  • Per-tenant policy store vs single store with tenant-scoped policies. Convera chose per-tenant for isolation, customization, onboarding/offboarding, and per-tenant resource quotas. See patterns/per-tenant-policy-store for the tradeoff analysis.
  • Where tenant context is sourced. Every layer must source tenant_id from a place the tenant cannot spoof — JWT claim from authoritative Cognito pool, not request body, not URL path.
  • Zero-trust vs trust-boundary model. Convera's architecture is explicitly zero-trust: every tier re-verifies. Alternative: the API-Gateway boundary is the only verification point, everything behind it is trusted. The zero-trust pattern costs extra AVP calls per request but protects against compromised-backend and misconfigured-policy scenarios.
  • Airbnb Himeji — data-layer authorization with per-context Profile IDs and write-time relation denormalization. Different substrate (not AVP), same "enforce at the lowest layer possible" instinct.
  • concepts/least-privileged-access — the individual-scope twin; tenant isolation is the tenant-scope enforcement of the same principle.

Caveats

  • Isolation cost scales with tenant count. Per-tenant policy store works up to AVP's per-account store limit (not disclosed in Convera source); beyond that, a shared-store-with-tenant-scoped- policies variant is required.
  • Cross-tenant admin operations (a platform-admin role that legitimately sees across tenants) must be carefully modeled — they intentionally violate tenant isolation and need their own set of policies + audit.
  • Tenant onboarding latency. Creating a new policy store, provisioning a new Cognito pool, and seeding user mappings is not instantaneous; SaaS onboarding UX has to account for this.

Seen in

Isolation-shape spectrum (added 2026-04-21)

Tenant isolation admits at least three architectural shapes, on a spectrum of where the enforcement boundary lives:

Shape Boundary Canonical source
Shared account + JWT-only tenant claim + app-layer tenant-scoped queries (lightest) Identity + app-layer sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — tagged-storage config service, patterns/jwt-tenant-claim-extraction + DynamoDB composite-key isolation
Shared account + per-tenant AVP policy store + backend zero-trust re-verification + data-layer tenant-context enforcement Multi-layer inside the account sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization
Account-per-tenant — dedicated AWS account per tenant AWS account sources/2026-02-25-aws-6000-accounts-three-people-one-platform — see concepts/account-per-tenant-isolation

The multi-tenant-config post is the lightest of the three — single shared account, no per-tenant AWS resources, application-layer enforcement with JWT-sourced tenant context + DynamoDB composite-key partitioning as the structural safety net. Convera's is in-account multi-layer. ProGlove's is structural per-account. All three deliver tenant isolation; they trade operational complexity against isolation strength.

Convera's shape is isolation through application-layer redundancy. ProGlove's shape is isolation through structural separation. Both deliver the property; they make different trade-offs about where the operational complexity lives (authorization engine vs. platform automation).

Last updated · 200 distilled / 1,178 read