Everything in one account
It is the most common starting point: a single account (or subscription, or project) where development, testing and production live together, across several applications and several teams. It works while it is small. After that, every permission granted is too broad, every mistake can reach production and nobody knows whose share of the bill is whose.
A hierarchy with intent
All three major providers let you organise their accounts in a hierarchy (with different names in each: organisations and units, management groups and subscriptions, organisation and folders). The structure that works best usually has these levels:
- The organisation, with the rules that apply to everything.
- Units by purpose: shared platform (network, identity, logs), business workloads, sandboxes for experimenting.
- Environments within each unit: development, acceptance, production, genuinely separated.
- Accounts per application or team, each with its owner.
What you gain without writing a single rule
Isolation. A mistake or an attack in one application's development account does not reach another's production.
Bounded permissions. Granting access to 'the orders acceptance account' is far more precise than granting access to a shared account.
Cost allocated by construction. Everything that happens in an account already has an owner (the most robust way to allocate cost).
Policies per level. What applies to a unit is inherited by all its accounts, as we will see two articles from now.
Designing it at the start
Moving resources between accounts afterwards is costly and sometimes impossible without recreating them. That is why the structure is designed at the start, written into the standard and created with infrastructure as code, so that every new account is born in its place and with its rules.
A well-made account structure multiplies the number of accounts. And that brings the next question: how to know who is who across all of them.
How we apply it: Multicloud Governance.