PATTERN Cited by 2 sources
Account-per-tenant¶
Intent¶
Achieve maximum isolation between SaaS tenants by provisioning a dedicated cloud account per tenant, providing hard boundaries for security, quotas, billing, and blast radius.
Problem¶
In shared-account multi-tenant architectures, tenant workloads compete for shared service quotas, IAM boundaries require complex policy engineering, billing attribution is indirect, and a single tenant's failure (or abuse) can cascade to all tenants via shared resource exhaustion.
Solution¶
Provision one AWS account per tenant via AWS Organizations. Each account provides: - Quota isolation: Independent service limits prevent noisy-neighbor quota exhaustion. - Security boundaries: IAM policies, SCPs, and resource policies operate at account boundaries — the strongest isolation primitive AWS offers. - Billing transparency: Per-account Cost Explorer provides natural per-tenant cost attribution. - Blast radius containment: A tenant's misconfiguration or compromise is confined to their account.
Structure¶
Management Account
├── Organization OU (production)
│ ├── Tenant-A Account (Lambda, DynamoDB, EventBridge)
│ ├── Tenant-B Account
│ └── ... (thousands)
├── Organization OU (shared services)
│ ├── Observability Account
│ └── Deployment Account
└── SCPs (baseline security guardrails)
Operational requirements¶
- Automated account factory: Account creation must be fully automated (<15 min from request to ready). See patterns/automated-account-factory.
- StackSets or equivalent for fleet deployment: Infrastructure updates must deploy to all accounts in parallel.
- Cross-account observability: Centralized log/metric aggregation from all accounts.
- Cost discipline: Per-account overhead (monitoring, baseline resources) must be minimized — at thousands of accounts, $3/account/month is material.
Trade-offs¶
| Pro | Con |
|---|---|
| Strongest isolation primitive | Management complexity scales with tenant count |
| Natural billing attribution | Cross-account IAM setup for shared services |
| Independent quota limits | Service quota increases needed per-account |
| Blast radius containment | Deployment tooling must handle fleet-at-scale |
When to use¶
- SaaS platforms requiring strong security isolation (healthcare, finance, government).
- Workloads where noisy-neighbor quota exhaustion is a real risk.
- When regulatory requirements mandate physical resource separation.
- When billing transparency per tenant is a business requirement.
Seen in¶
- sources/2026-06-29-aws-lessons-learned-from-scaling-to-1-million-lambda-functions — ProGlove operating 1M+ Lambda functions across thousands of tenant accounts.
- sources/2026-02-25-aws-6000-accounts-three-people-one-platform — ProGlove's earlier deep-dive on 6,000-account multi-tenant platform.