An enterprise SaaS company grows from one cloud account to hundreds across many teams. What structure prevents this from becoming ungovernable, and what is the wrong way to impose it?

The structure

• Account or subscription per workload and environment, not per team. The account is the strongest isolation boundary the cloud offers — for blast radius, for cost attribution, for access control and for quotas — and using it as the unit of isolation is what makes everything else tractable.
• An organisational hierarchy with policies applied at the level they belong: security controls at the top, environment-specific rules at the branch, workload-specific configuration at the leaf.
• Preventive guardrails as policy, not detective ones as reports. A control that denies the creation of a public storage bucket is worth more than a report listing public buckets, because the report requires someone to act and the policy does not.
• A paved road — a template producing a compliant, observable, networked, logged account with a pipeline attached — so the compliant path is the fastest path.
• Centralised logging, identity and network egress, because these are the things that must be consistent to be useful and are painful to unify retroactively.

The wrong way to impose it

A review board approving every new account. It becomes a queue, the queue becomes a bottleneck, teams route around it by reusing existing accounts for unrelated workloads, and the isolation the structure existed to provide is destroyed by the process meant to protect it.

The other wrong way is retrofitting guardrails onto hundreds of existing accounts by report and remediation ticket. That is a permanent treadmill. The workable path is to make the new accounts correct, migrate high-risk workloads deliberately, and let the rest converge — while measuring the percentage of the estate on the paved road as the metric that matters.

The cost dimension

Account-per-workload makes cost attribution automatic, which is the single most effective FinOps control available: teams that can see their own spend reduce it, and teams that cannot, do not. Shared accounts require tagging discipline that never survives contact with reality, and cost allocation then becomes an ongoing argument rather than a fact.

The trade-off to state honestly

More accounts means more networking complexity, more identity federation, more places to apply a change, and a real risk of quota fragmentation — a limit that is per-account is now hit at a fraction of the total usage. That is the price of isolation, and the mitigation is automation: if creating and configuring an account is not automated, account-per-workload is unmanageable and the design will collapse back into shared accounts.