Your Cloud Account Structure Is a Security Decision Nobody Labelled as One

Ask how your cloud accounts came to be arranged the way they are and the answer is rarely a security rationale. It is usually finance wanting one invoice, or a platform team wanting one place to manage networking, or the first project simply creating an account and everything since being added to it. Reasonable decisions, made quickly, by people who were solving the problem in front of them.

The account is also the hardest boundary the platform gives you. Not the VPC, not the resource group, not the namespace, not the tag. The account is the unit within which permissions can be granted, the unit a policy can be scoped to, and the unit an attacker is confined to when everything else fails. Choosing how many you have and what goes in each is a security architecture decision. It is almost never recorded as one, which is why it is almost never revisited until an incident makes the case.

What the boundary actually does

Inside a single account, isolation depends entirely on policy correctness. Every resource sits under the same control plane, addressable by the same API, and the only thing keeping a development identity away from production data is a policy that says so. That policy is a document written by humans, changed under deadline pressure, and evaluated by a system with subtle precedence rules.

Across accounts, isolation is structural. An identity in one account has no implicit reach into another. Access requires an explicit trust relationship, created deliberately, visible as its own object. The default answer is no rather than yes, and a policy mistake in one account does not silently extend into the next.

That difference is the entire argument, and it is worth being precise about what it buys and what it does not.

Boundary	Isolation strength	What still crosses it
Tag	None, advisory only	Everything. Tags describe, they do not enforce
Resource group or project folder	Organisational	Any identity with account-wide permissions
VPC or virtual network	Network only	The control plane, which can reconfigure the network
Account or subscription	Structural, default deny	Only what an explicit trust relationship allows
Organisation root	Governance ceiling	Nothing, if guardrails are set at the top

The VPC row is the one that catches experienced infrastructure people. Network segmentation was the strong control on premises and it remains useful, but in cloud it protects data paths rather than management paths. An identity with the right permissions does not need to traverse your network to change it. Which is why the account boundary matters more than the network boundary, and why the control plane is what account separation is actually protecting rather than the workloads themselves.

The single account has a specific end state

It does not fail loudly. It degrades in a shape that is recognisable once you have seen it.

Permissions accumulate because every new workload needs something and the account already contains everything. Policies referencing resource name patterns spread, because that is the only way to express separation without a real boundary. A naming convention change, or one resource created outside the convention, quietly widens a scope nobody re-reads. Development and production share a control plane, so a misconfigured pipeline in one can reach the other, and the thing preventing it is a string match.

Then the practical problems arrive. Service quotas are per account, so a test workload consumes capacity a production one needed. Audit logs mix every environment into one stream, making the question "who changed this in production" a filtering exercise. And when an identity is compromised, the incident scope is the entire estate, because there was never a place for it to stop.

Working through what a multi-account structure buys you and what it costs to run matters before you split, because the answer is not "more accounts is better". More accounts means more places to configure networking, more identity federation, more sameness to maintain. The right number is the number that puts a hard boundary around each thing you would genuinely want contained separately, and no more.

Splitting by org chart is the common mistake

When organisations do split, the seam is usually the team structure. One account per team, because that maps to who owns what and makes billing legible.

Team boundaries move. Reorganisations happen every couple of years, and each one leaves accounts named after teams that no longer exist, owned by people who inherited them, containing workloads that belong to a different group now. The boundary you drew stops describing anything real, but the resources cannot easily move, so a translation layer of cross-account trust relationships grows to paper over the gap. Each of those relationships is a permitted path between accounts, which is exactly what the split was meant to reduce.

The seam that holds is environment and sensitivity. Production is separate from non-production because the consequence of a mistake differs by orders of magnitude. Regulated data is separate from unregulated data because the control set differs and you want the audit scope bounded. Shared services such as logging and identity live in their own accounts because they need to be reachable by everything while being modifiable by almost nothing. Those distinctions do not change when the org chart does.

Logging is the one that has to be decided first

Whatever structure you choose, the log destination cannot be one of the accounts being logged. This is the single sequencing decision that is genuinely painful to correct later, because retroactively rebuilding a trail you did not keep is impossible.

If audit logs live in the account that generated them, they are writable by identities in that account, including a compromised one. The first thing a competent intruder does after gaining control plane access is reduce their own visibility, and if logging configuration is within their reach, they will. A separate account holding logs, where the workload accounts have write access and nothing more, turns the trail into evidence rather than into another resource in the blast radius. Getting audit logging that spans accounts and survives the compromise of any one of them right at the start costs a fraction of what it costs to retrofit.

It also has a bearing on how much of the provider's column you were relying on. Investigation is yours, not theirs, which is the part of the shared responsibility model most commonly misread as covered.

What to do next

You cannot re-architect an estate on a Tuesday, but you can establish where you stand and stop the drift.

1. Draw the accounts you have and, next to each, write the reason it exists. Reasons that are purely administrative mark the boundaries doing no security work.
2. List every cross-account trust relationship. Each one is a deliberate hole, and any you cannot explain is an unexamined one.
3. Confirm the log destination is outside every account it records, and that workload identities can write to it but not alter or delete from it.
4. Decide the seam you will use for anything new: environment and data sensitivity, not team names.
5. Set guardrails at the organisation level, so the ceiling on what any account can do is enforced above the accounts rather than inside each one.

Structure decided deliberately is cheaper than structure inherited by accident, and the gap between the two widens every quarter. If you want an existing layout assessed against the boundaries it is actually providing, that review is where our cloud security services usually begin.