Splitting AWS accounts sensibly

Anyone starting out on AWS has one account, and everything comes into being in that one account: the production database, the playground for experiments, permission management, the bill. That feels simple at first, and that is exactly why it is rarely questioned. The price only comes later, when a misplaced permission suddenly hits production as well, when nobody can say any more which cost item belongs to which purpose, or when a compromised login has access to absolutely everything.

Splitting into several accounts is therefore not a bureaucratic surcharge for large organisations, but a fundamental decision that pays off most early on and is most expensive to retrofit later. AWS itself does not treat the account as a billing unit on the side, but as the most important boundary the platform knows. We look at why this boundary carries so much, what the AWS Well-Architected Framework says about it, and what a sensible split looks like in concrete terms for a small product company.

Why several accounts at all

Everything within an account shares the same framework for permissions, the same visibility and the same fate when something goes wrong. That is exactly why the way accounts are split decides how far a problem reaches. If production sits in the same account as development, then an overly broad permission, a leaked key or a misdirected automation is never confined to the harmless side, but potentially hits what revenue depends on.

In its whitepaper on organising your environment, AWS lists several reasons for multiple accounts, and they read like the list of problems a single account causes. Accounts group workloads by purpose and ownership, so it is clear who owns what. They allow different security controls per environment, because production and development simply do not need the same rules. They limit the blast radius, that is the reach of an incident, because a problem in one account does not jump to the others. And they are the default unit by which AWS allocates costs, which is why separate accounts make it possible to report, forecast and budget spending cleanly in the first place.

The sentence “an account is the default unit of cost allocation” has a direct consequence for support costs, because Business Support+ is billed per account. How this affects the bill and when an aggregated Enterprise plan pays off is worked through with a calculator in the article What AWS Support really costs.

What Well-Architected says

The AWS Well-Architected Framework is the collection of principles against which AWS measures well-built systems, organised into pillars such as operational excellence, security, reliability and cost optimisation. What is special about the multi-account strategy is that it does not pay into one of these pillars, but into several at once. The same separation that increases security also improves reliability, sharpens cost transparency and makes operations easier to oversee.

AWS therefore recommends defining a multi-account strategy deliberately instead of leaving it to chance, and with AWS Organizations it provides the umbrella under which all accounts are managed centrally. Organizations handles consolidated billing, shared guardrails via service control policies and the orderly grouping of accounts into organisational units. The individual accounts are thus separated where separation protects, and connected where shared control helps.

A sensible split

For a small product company, the split does not have to replicate a corporation’s full landing zone, but a few accounts pull their weight from the start. We prefer at least five, and each has a clear, non-negotiable purpose.

The management account is the top of the organisation and runs no workload itself. It holds the organisation together, handles consolidated billing and carries the organisation-wide guardrails. Because it has the highest rights in the entire setup, as little as possible belongs in this account, so that the most powerful place is also the least exposed.

The backup account is the separate place of safekeeping for backups and logs. Its purpose lies precisely in the separation, because a backup that sits in the same account as the original does not protect against the case where that very account is compromised or misoperated. If backups and central logs live in their own account with very tight write and delete rights, they remain reliable even if something is on fire elsewhere. For this reason AWS gathers logs in a dedicated log archive account, and for a small team this role can easily be combined with the backup account.

The three remaining accounts separate the environments by maturity. Development is the place to build and try things out, with broader access but without real customer data, so a mistake there costs nothing but time. Staging is the production-like rehearsal, built as identically to production as possible, so it shows what would happen in the real environment before it happens there. Production carries the real customers and data and therefore gets the tightest rights and the strictest control. The most important boundary in the whole picture runs in front of production, because behind it lies what really hurts when it fails.

What this means for you

Splitting into several accounts is not an end in itself and not a sign of size, but the boundary on which AWS hangs security, reliability and cost transparency all at once. For a small product company, a manageable split into management, backup, development, staging and production is enough, one that grows with you instead of having to be laboriously retrofitted later. Splitting cleanly early saves you the expensive disentangling and, along the way, keeps the costs per purpose in view. Whether it is about the first split or about untangling a catch-all account that has grown over time, we are happy to sort it out together with you.