One AWS account is the right size at the start. A second account separates nothing that needs separating on that day. The question comes later, and it comes from a concrete state.
I therefore do not start with an account landscape. I start with one account and stay there for as long as the boundaries that matter still hold that way.
What is actually being compared
This is not a comparison between a landing zone and a messy account. The landing zone is what appears after the decision for several accounts has been made: structure, access, logs. That build is described on the page about building an AWS landing zone. This article is the decision before it.
The actual question is: Must a boundary hold that an administrator in the same account can cross today? If not, one account stays. If yes, the account itself is the boundary. Everything else is apparatus: organizational units, guardrails, a tool that creates the accounts.
What one account already carries
An account is already a boundary. Permissions, quotas and the bill end there. A lot can be kept clean inside that boundary, and that is where I start before anyone mentions a second account:
- Sign-in through IAM Identity Center, a role per task, no long-lived access keys.
- Production and test in separate networks, not merely under separate names.
- Permissions tight enough that the everyday role cannot delete production data.
- Tags that show up in cost allocation, and a rule that enforces them.
For one product, one team and a bill that can be explained, that is the whole solution. What it does not do: it does not stop anyone who is allowed to do more in this account than the everyday role. A naming convention is an agreement. A role in the same account is a path to the resource.
How keys and roles in a grown account come back to a set you can account for is covered in Cleaning up IAM in a grown AWS account.
When I stay on one account
I stay on one account for as long as these four sentences are true.
- There is one product and one team that is allowed to operate it.
- Anyone who can change production is supposed to be able to. There is no contractor and no second environment that must not see production data.
- The bill can be attributed to one product, because the tags are kept.
- Nobody yet requires the logs to survive an incident that the same access could also delete.
Two or three people, one application, test and production in two networks, access through roles. A second account would add an organization, a log account, cross-account roles and an address plan. None of that removes a risk this environment has today.
In that state, one account is the final architecture. It is not an interim stage that has to be made “proper” later.
What the split actually solves
Four things. I split accounts when at least one of them does not hold today.
The blast radius of a mistake. A permission that is too wide in the test environment reaches production for as long as both live in the same account. Separate accounts are the boundary on AWS that holds against the administrator of an account as well. Not against the administrator of the organization: whoever is administrator in the management account reaches the member accounts through their access role. That boundary is the core of a landing zone, and it is the condition under which I start that shape.
Who may go where, without relying on care. Roles in the same account are enough for as long as nobody has a role that covers both worlds. Once a person or a pipeline moves through both worlds in everyday work, the separation depends on attention. A separate account makes the wrong world unreachable.
Logs the incident cannot delete. CloudTrail trails and their logs in the same account can be switched off and deleted by the same access that is destroying something. What remains is the event history with the last 90 days of management events, nothing more. A log account that the application can only deliver into, and delete nothing from, survives exactly that moment.
A bill that does not depend on voluntary tags. Tags stay voluntary until somebody enforces them. In a grown account they often are not, for years. One account per product is an attribution nobody forgets. For as long as one product is the whole bill, I do not need that.
Where the bill still runs away inside one account is covered in Bad architecture sends no alerts. Splitting accounts does not replace that search. It only makes visible which product caused the line item.
Four arguments that are not enough on their own
“AWS recommends several accounts.” The recommendation describes an organization that has several boundaries. It does not describe the first week of a product. Implementing it beforehand leaves you with five empty accounts and the same application in one of them.
“The audit demands separate accounts.” What a questionnaire wants to see is the separation of the environments and evidence of who can reach where. A fixed account count is not in there. One account with tight roles and separate networks answers it, for as long as the evidence holds. It stops holding when an administrator reaches both environments in the same session and nobody can show that. Then a second account is the honest answer, because otherwise the evidence remains an agreement.
“We will grow.” Growth is not a date. The cut pays for itself when a second product arrives, a second team with its own permissions, or a contract that demands a boundary. Before that, the structure is a guess. I do not operate guesses.
“Accounts are free.” The account itself has no price. The structure around it does: AWS Config, a second CloudTrail beside the one the organization already writes, traffic between the accounts, and somebody who understands the organization. Control Tower takes work off that build and has no surcharge of its own. The services underneath do. The limit on the number of accounts is operability. That limit is the price.
What the cut looks like when it is due
The cut follows the boundary that must hold, not the org chart. Teams change. An isolation boundary changes less often.
The shape that then appears is that of a landing zone: management, logs, security, production, non-production. That is five accounts. They are the target shape, not the starting size on day one. I open them once the decision has been made. I do not open them so that the decision becomes easier someday.
A new organization is allowed ten accounts to begin with. The limit can be raised and constrains nothing in the long run. But the landing zone takes five of them on day one. What really constrains is whether the next account comes from a described path or from an afternoon in the console.
Whether that path runs through Control Tower or directly as infrastructure as code is a second decision. It depends on who operates the environment afterwards. The service page says what is needed there, including the downside. A tool choice would only make this article longer.
What the structure gets described with, once it is to be described, is covered in Terraform or AWS CDK.
The management account stays free of the application. Service Control Policies, the guardrails of the organization, do not apply to users and roles there. The account that owns the organization is therefore the worst place for the product.
What the cut costs
Moving a running application into another account is a migration, not a setting. If you already know the boundary is coming, you draw it before the first production load. Afterwards resources are created again and data is moved.
Address ranges are assigned before the second network exists. Overlaps show up at the first connection, and by then production load hangs on them.
Access is not multiplied with the number of accounts. Identity Center and roles apply to one account the same way they apply to ten. Every account comes with a root user. Anyone who maintains its credentials in every account and creates their own keys there as well has drawn the boundary and multiplied the original state. In an organization, the root credentials of member accounts can be removed centrally; newly created accounts then have none.
Pipelines take their permissions through short-lived tokens. Whether one account sits behind that or several changes the role that is assumed, not the path. What belongs on that path is covered in What a normal deployment pipeline really needs.
The decision as a table
| Situation | One account | Several accounts |
|---|---|---|
| One product, one team, evidence possible through roles | my default | overhead with nothing in return |
| Production and test separated only by name | tighten the roles first | only once the roles cannot be made tight |
| A contractor must not see production | roles are often enough | when the boundary must hold against an admin mistake |
| Logs must survive the incident | hard in the same account | the reason for a log account |
| Two products, two bills, two teams | tags, until they break | accounts |
| Several accounts already, with no shared pattern | sorts nothing any more | then the structure is the project |
| Management account | does not apply | leave it empty, put the application elsewhere |
The table does not decide on its own. The question before it does not fit in a row.
The question I start with
When someone says we need several accounts, I do not ask about Control Tower. I ask: Which boundary must hold even though someone is allowed to do more than they should?
There are clear answers to that. “A mistake in the test environment must not reach the production data, and today it can.” “The logs must stay put if the application account is compromised.” “Two products must not share a bill and administrators.” All of those hold.
“That is how it is done” is not enough for me. “For later” is not either.
For as long as the boundary holds with roles, networks and evidence, the one account is the smallest solution that carries the problem. If it does not hold, the next step is the structure. That is built on the page about building an AWS landing zone, on the environment that is already running, without stopping operations.
