I run a small hosting business for clients' static websites, primarily using S3 and CloudFront. DNS is managed through Cloudflare, and ACM provides certificates where needed. Each client has a separate Git repository and CI/CD pipeline, with completely independent codebases.
My current setup uses one AWS account per client, with development and production resources separated inside that account. As I add more clients, I'm considering whether to keep this model or change it.
The options are:
1. One account per client, with dev and production resources in the same account.
2. One account per client per environment, giving every client separate dev and production accounts.
3. One shared account for all clients, but with separate Terraform states and resource boundaries.
4. One shared account with a single Terraform state.
The sites are mostly simple front ends, although I use separate development and production accounts for larger clients that need backends or databases. Clients do not receive direct AWS access.
For a small team or solo operator, what structure is the best balance of isolation, security, Terraform management, CI/CD complexity, billing, and operational overhead? Is one account per client with dev and production together a sensible long-term design, or is separating each environment into its own account worth the extra management?
4 Answers
For simple static sites managed by one operator, one account per client with dev and production inside it is a reasonable compromise. It keeps billing and ownership clear while avoiding a rapid increase in account count. Use separate Terraform states, tightly scoped deployment roles, strong CI/CD protections, and explicit production approval steps.
I’d reserve separate dev and production accounts for clients with databases, sensitive data, higher risk, compliance requirements, or a genuine need for stronger isolation. Account-per-environment is more secure, but it can be excessive for a few S3 and CloudFront distributions.
I’d keep the current one-account-per-client model for these front-end-only customers, but make dev and production clearly separate through roles, pipelines, state files, and naming rather than combining everything into one Terraform state. Automate the account setup so adding a customer is repeatable.
If the business grows substantially, or a customer requires stronger guarantees, migrate that customer to separate dev and production accounts. This gives you a practical default without paying the full operational cost of account-per-environment for every small site.
A shared account can work when the sites are really just copies of the same multi-tenant platform and customers never access AWS. In that case, separate Terraform states, strict IAM roles, consistent tagging, budgets, and deployment pipelines are essential. A single state for every customer is usually the least attractive option because one mistake can affect unrelated sites and state management becomes difficult as the system grows.
However, separate states are not a substitute for account boundaries. CloudFront and some other services make fine-grained isolation awkward, and a compromised deployment role or overly broad policy could still expose multiple clients.
For the strongest isolation, use a separate account for each client and environment, with production and non-production in separate organizational units. AWS accounts are the most reliable resource and access boundary, so a bad Terraform change or compromised development environment is much less likely to affect production or another customer.
The trade-off is account-management overhead. You’ll need to automate account creation, baseline security, logging, IAM, billing, and CI/CD access, and you may eventually need service-limit increases. This model makes the most sense when clients have meaningful backends, data, compliance requirements, or independent access needs.
That matches my situation fairly well. I’m currently hosting around ten sites, and the sites are mostly simple front ends. For clients needing backend or database infrastructure, I already use separate development and production accounts, so I’ll likely keep the lighter model for static-only customers.