Account-Per-Tenant SaaS Architecture on AWS: Managing 6,000 Accounts

ProGlove, a SaaS provider for smart wearable barcode scanning solutions, has implemented an extreme multi-account strategy on AWS: an account-per-tenant model. This approach dedicates a separate AWS account to each customer, enabling clear security boundaries and simplified resource ownership. This decision was driven by the need to balance speed of innovation with stringent security and data isolation requirements inherent in SaaS platforms.

Why an Account-Per-Tenant Model?

While many SaaS providers evolve from dedicated deployments to shared multi-tenant models to optimize costs, ProGlove adopted the account-per-tenant model to address common multi-tenancy challenges. This model mitigates issues such as a large blast radius from misconfigurations, shared quota limits, operational complexity in resource ownership attribution, customization limitations, and difficulties in cost visibility for individual tenants. The AWS account boundary provides the strongest form of isolation.

Key Benefits

• Strong Isolation: Each tenant account has independent storage, compute, and permissions, limiting the impact of security incidents or misconfigurations to a single tenant.
• Simplified Mental Model: Developers only need to consider a single tenant context, reducing cognitive load and simplifying debugging, as services always belong to one tenant.
• Customization: Individual accounts can be modified, tested, and migrated independently, allowing for tailored deployments and feature activations.
• Transparent Cost Attribution: AWS Cost Explorer and linked accounts enable straightforward per-tenant cost reporting and chargebacks, beneficial for consumption-based pricing models.

Challenges and Trade-offs

The account-per-tenant model shifts complexity from application development to platform development. Managing thousands of accounts manually is impractical, necessitating extensive automation for account creation, baseline setup, IAM roles, and guardrails. ProGlove leverages AWS Organizations, Service Control Policies (SCPs), CloudFormation StackSets, and custom tooling to manage this orchestration.

• Automation Overhead: Account lifecycle management (creation, configuration, retirement) requires significant automation investment. AWS Step Functions automate provisioning, while retirement might still involve manual scripts.
• Cost Management: While serverless services like AWS Lambda and DynamoDB scale to zero, services like EC2 or RDS incur costs even when idle. Careful cost modeling and optimization are crucial when deploying across many accounts.
• Centralized Observability: Monitoring across thousands of accounts and regions is complex. Centralized observability tooling is essential, but it must be designed to avoid reintroducing the isolation risks the multi-account strategy aims to prevent. AWS Observability Access Manager is a key enabler.
• Identity and Access Management: Operating across accounts requires a robust IAM model with cross-account trust policies. Avoiding long-lived credentials and implementing secure identity practices are critical to mitigate security risks and reduce monitoring effort.