Most teams start with one cloud account because it is the obvious thing to do. Everything lives together, permissions are simple and there is nothing to coordinate. The problems arrive later, and they arrive all at once.
What one account actually risks
Blast radius. A credential that leaks from a development laptop reaches production, because it is the same account. There is no boundary to stop it.
Accidents. Someone running a cleanup script against the wrong resources, or a Terraform apply pointed at the wrong workspace, can destroy production while intending to tidy up a test environment. Account boundaries turn a catastrophe into an error message.
Quota contention. Service quotas apply per account. A load test that consumes the vCPU quota can prevent production from scaling at exactly the moment it needs to.
Cost attribution. With everything in one account, working out what development actually costs means tagging discipline that almost never survives contact with a deadline. Separate accounts give you clean numbers for free.
Access control. Contractors and junior engineers need access to development. In a single account, granting that safely means carefully scoped policies that someone has to write and maintain correctly, forever.
The common structures
Per environment. Production, staging and development in separate accounts. This is the baseline, and it solves blast radius, accidents and quota contention at once.
Per team. Larger organisations give each team its own accounts so that one team’s usage cannot affect another’s, with cost naturally attributed.
Per client. Agencies and consultancies keep each client in a separate account. This is not optional in most client relationships: it keeps data separated, makes handover clean if the client takes the infrastructure in-house, and means a compromise in one engagement does not touch another.
The obvious objection
Separation costs overhead. More accounts means more credentials, more setup and more places to apply policy.
Two things reduce that cost substantially. First, the platforms provide organisational tooling built for exactly this: AWS Organizations, Google Cloud resource hierarchy, Azure management groups. Policy applies at the top and inherits downward.
Second, if your infrastructure is defined as code, a new environment is a parameter change rather than a manual build. Teams that find separation painful are usually the ones still clicking through consoles.
How to split without breaking things
- Production first. If you do only one thing, get production into its own account. That is where most of the risk lives.
- Move development next, since it has the loosest access and the most experimentation.
- Keep staging genuinely production-like. A staging environment that differs structurally from production does not test what you think it tests.
- Centralise audit logs outside the accounts that generate them, so a compromise in one cannot erase its own trail.
- Set billing alerts per account. Separate accounts make anomalies visible that would be lost in an aggregate bill.
Where the accounts come from
Creating each new account from scratch means going through card checks, phone validation and, on several platforms, an identity review, every time. For an agency onboarding a client against a deadline, that is friction at the worst possible moment.
This is a common reason teams buy accounts with billing already active: the separation they want is straightforward, and the account creation process is the only thing slowing it down. Configurations and pricing for each platform are listed on the catalogue page.
Secure each one properly
Separation only helps if each account is itself secured. Every new account needs its own credential rotation, its own multi-factor authentication on the root user, its own scoped users, its own billing alert and its own audit logging. The day one checklist applies to each account individually, not once across all of them.
Common questions
Is this worth it for a two-person team?
Splitting production from everything else, yes. Full per-team separation, probably not yet.
Does separation increase cost?
Usage costs are the same. You may lose some volume discount aggregation, which organisational tooling largely addresses by consolidating billing.
How do I share resources between accounts?
Each platform supports cross-account access through roles and resource sharing. Grant it explicitly and narrowly rather than recreating a single flat account by accident.