Skip to content

CONCEPT Cited by 1 source

Account-per-tenant isolation

What it is

Account-per-tenant isolation is the shape of tenant isolation in which the SaaS provider creates a dedicated AWS account per tenant and deploys the tenant's service instances exclusively into that account. The AWS account itself becomes the isolation boundary — no shared compute, storage, networking, or IAM scope across tenants unless explicitly configured. Compare against the shared-account shape where isolation is enforced at authorization, data-partitioning, and IAM-policy layers inside a single account.

"At scale, the AWS account boundary is the easiest way to implement isolation. Accounts are fully isolated containers for compute, storage, networking and more, with no shared scope unless you explicitly configure it." (Source: sources/2026-02-25-aws-6000-accounts-three-people-one-platform)

The spectrum

Shape Isolation boundary Examples in wiki
Shared account + resource-level boundaries IAM policies, data partitioning, per-request tenant_id checks Convera — patterns/per-tenant-policy-store in a single AWS account
Shared account + per-tenant policy store Authorization engine + data-layer tenant-context enforcement Convera (same source; systems/amazon-verified-permissions)
Account-per-tenant AWS account ProGlove Insight (this concept)

Benefits (ProGlove's framing)

  1. Strong isolation by construction. Tenant data is not co-located; each account has its own storage, compute, and permissions. Misconfigurations, runaway processes, and vulnerabilities are naturally bounded by the account. (concepts/blast-radius)
  2. Simplified developer mental model. "A deployed service instance always belongs to exactly one tenant" — no multi-tenancy code paths in the service, no per-row tenant-id filtering, no cross-tenant-leak unit tests. Cognitive load drops; debugging simplifies.
  3. Isolated production-like dev environments. Developers can be given their own tenant accounts that look identical to production tenants — closing the "works in dev, breaks in prod" gap.
  4. Per-tenant customization. Individual accounts can be migrated, modified, or have premium features toggled independently without touching the rest of the system.
  5. Transparent cost attribution. AWS Cost Explorer on linked accounts makes per-tenant cost reporting and chargeback trivial — particularly load-bearing for consumption-based SaaS pricing.
  6. Well-Architected review simplification. Many items in the Operational Excellence and Security pillars "didn't even apply" to ProGlove's setup, because the isolation is structural rather than implemented in application code.

(Source: sources/2026-02-25-aws-6000-accounts-three-people-one-platform)

Costs / what the shape forces you to build

The shape shifts complexity from application development to platform development. The mandatory platform investments:

The economic constraint: prefer serverless, avoid per-resource billing

The per-account cost-multiplier is the most under-appreciated constraint. AWS services split cleanly into two tiers:

  • Scale-to-zero / per-request billing: Lambda, DynamoDB on-demand, SQS, SNS, S3, EventBridge. Idle cost per account ≈ 0. Multiplies cleanly.
  • Per-provisioned-resource billing: EC2, RDS (non-serverless), ELB, NAT Gateway, Kinesis shards, OpenSearch domains. Smallest EC2 ≈ USD $3/month; at 1,000 accounts that's ~$3,000/month just for idle one-instance-per-tenant capacity.

"Services that scale linearly with the number of accounts should be avoided where possible." (Source: sources/2026-02-25-aws-6000-accounts-three-people-one-platform)

This is why ProGlove runs ~1,000,000 Lambda functions across 6,000 accounts — the function count doesn't matter economically because idle functions cost nothing. The concept is an implicit hard constraint on the service-mix for account-per-tenant to be viable.

Relationship to concepts/tenant-isolation

Both concepts describe tenant data / users / policies being inaccessible across tenants. The difference is the layer of enforcement:

  • concepts/tenant-isolation — canonical multi-layer shape inside a shared account (identity → token → authorization → routing → data); every layer is a tenant-boundary check.
  • concepts/account-per-tenant-isolation — the AWS account is the only boundary you need to enforce structurally; inside the account the code does not need to be multi-tenant-aware at all.

They are not mutually exclusive: a tenant account can itself contain a multi-layer auth stack (e.g. admin users vs end users within the tenant). But at the cross-tenant level, the account boundary is the sole load-bearing mechanism in the account-per-tenant shape.

Known unknowns / ceiling

  • Account count per AWS Organization has practical limits (default 10, raised for mature customers); at some tenant count the model requires multiple Organizations.
  • StackSet propagation time for a fleet-wide change grows with account count; large-scale updates "can take significant time to propagate." Not disclosed in the ProGlove source.
  • Retirement / offboarding latency — ProGlove handles this via scripts run "regularly," implying it is eventually consistent, not real-time.
  • Cross-tenant admin operations (a platform-admin role that legitimately operates across tenants) are not characterised here but are load-bearing in any multi-tenant system — they intentionally violate isolation and need their own audit story.

Seen in

Last updated · 200 distilled / 1,178 read