Landing zone
Almost every AWS environment starts with one account, and at the start that is the right call. Past a certain size it turns: production and test share the same permissions, the bill cannot be traced back to a product, access runs through keys nobody rotates any more, and at the first audit every answer is missing. I build in the structure that should have been there from the beginning, without stopping operations.
Structure and foundation as a bounded three to six week engagement, enrolling existing accounts afterwards in waves. Operations stay with your team, which is why the handover is part of the work.
Remote from Germany. Straight with me, no agency in between.
The starting point
Nobody decides to put everything in one account. It starts with one account, because a second one would be effort without benefit on day one, and then the moment where somebody stops to think never comes. Eventually production, test and the database holding customer data sit in the same permission environment, and the separation consists of naming conventions and the hope that nobody makes a typo. That is not a security hole in the technical sense, but it is the kind of setup where a single mistake reaches everything you have.
The second finding is always attribution. When all workloads live in one account and tags are voluntary, nobody can say what a product costs. The bill is then not a steering signal but a surprise at the end of the month. And because reducing cost begins with attributing cost, more hangs on this question than tidiness: without an account split and enforced tagging, every piece of cost work starts with archaeology.
The third finding is access. Grown environments have long-lived access keys in configuration files, shared credentials for emergencies, and a root user whose password sits in a password manager too many people can open. That is solvable today without becoming inconvenient: access through IAM Identity Center with roles per task, and the root credentials of member accounts can be removed centrally rather than kept. Accounts newly created in an organization have none from the start.
Does any of this sound familiar?What I do
First the question of where the cut goes. Not one account per team, because teams change, but per isolation boundary: production separated from everything that is not production, security relevant logs in an account no application can reach, shared services where they are genuinely shared. Account count has long stopped being the limit, up to a thousand accounts fit in a single OU. The question is the reasoning, not the number.
A real decision with two right answers. Control Tower takes work off your hands and prescribes structure, in return the part AWS rolls out stays in its hands, and your landing zone follows a version level AWS sets. Your own build in Terraform leaves more freedom and demands more responsibility. I decide that on your case and name the downside as well as the upside.
Sign in through IAM Identity Center, connected to your existing directory, with roles per task rather than per person. Long-lived access keys disappear from configuration files and become short sessions; pipelines obtain permissions through OIDC. And the root credentials of member accounts are removed centrally rather than kept, with a documented path for the few tasks that genuinely need root.
Three kinds, and they do different things. SCPs cap what principals in an account may do at all. RCPs cap what can be permitted on a resource, which also covers access from outside your organization. Declarative policies do not frame calls, they set a desired state for service attributes and are enforced in the control plane of the service itself, not at the API call. We take a few that will be lived with, rather than many that somebody switches off again after three weeks.
CloudTrail at organization level into a dedicated log account, Config for state, S3 with a retention period somebody actually decided, and customer managed KMS keys where they make a difference. Plus the uncomfortable side: Config is the cost driver of this setup once workloads are short lived, and a second self managed CloudTrail trail alongside the managed one costs twice. Both get decided rather than overlooked.
What already runs gets enrolled, not rebuilt: accounts move into the structure, deviations get reported rather than discovered, and the order respects the risk. At the end the things that make the result durable: a guide for how the next account comes into being, the rule for console access, a runbook for emergency access and a handover session.
How many accounts do you have, and along which line are they cut?
Write to me about how your environment is split today and what triggered the question. You get an assessment before you commission anything.
How it runs
Four steps, and after the second one the foundation stands. No step assumes that you commission the next one.
Which accounts exist, how access works today, what is logged and which requirement triggered this. The result is a proposal for the structure with reasoning and effort. Read access is enough.
Organization, OUs, log account, access and the first guardrails, described in Terraform. After this the structure exists, even if no application has moved yet.
Existing accounts move into the structure, the uncritical ones first. Between two waves the environment is always in a valid state, and every wave is useful on its own.
Guide for the next account, rules for console and emergency access, drift reporting in place, and a session with the team.
The outcome
Separate accounts are the only boundary on AWS that really holds. A wrong permission in the test environment no longer reaches production.
When workloads live in their own accounts and tags are enforced, every line can be attributed to a product. Only after that is cost work more than guessing.
Who has access, what is logged, how long it is kept: the answers come from the structure and from the repository, not from memory.
A new account comes into being with guardrails, logging and access, without anyone having to remember. That is the real gain, and it only shows at the tenth one.
Technologies I use
From practice
Production and staging in two accounts grown over years. The first problem was not the size of the bill but the missing explanation for it: no increase could be attributed with confidence to a workload, a data volume or a decision. That attribution is exactly what an account structure with enforced tagging produces.
Read the case studyAlso from real projects
Migration of revenue reporting for a platform with nine figure revenue into a scalable AWS environment, while it stayed in operation. Network, permissions and logging existed as code before the first workload moved.
Read the case study
Who you are talking to
I am Tim Rutte. More than 20 years in software development, plus the AWS certifications as Solutions Architect Professional and for Security. I build account structures that survive an audit and that a team can still use. You talk to the person who touches your code, from the first call to the handover.
Common questions
Both are defensible, and the answer hangs on two questions: how much structure do you want handed to you, and how much idiosyncrasy do you have to represent. Control Tower takes a lot of work off your hands, sets up the log account, guardrails and account factory and keeps them at a version level. The price is coupling: the part AWS rolls out stays in its hands, and your landing zone follows its versions. To be fair, a landing zone from version 3.1 onwards can be repaired and updated without jumping straight to the newest version, and with landing zone 4.0 from November 2025 individual integrations can be switched off. Your own build in Terraform fits when you already have a grown organization, your own identity integration, or requirements that Control Tower can only work around. In both cases as much as possible gets described as code.
Control Tower itself costs nothing, which is what the AWS pricing documentation says. What you pay for are the services underneath: Service Catalog for the account factory, CloudTrail for the logs, Config for state, plus S3, SNS and CloudWatch. The line item that surprises people is AWS Config, specifically when many short lived resources appear and disappear again, and AWS names that explicitly. The second is a self managed CloudTrail trail running alongside the managed one: then you pay twice for the same events. Both are decidable if you know beforehand, which is why they are here.
No. Existing accounts get enrolled into the structure rather than replaced: they move under an OU, receive the guardrails and the logging, and then appear in the central view. That runs in waves, the uncritical ones first, and between two waves the environment is in a valid state. What regularly turns up in the process is an account nobody needs any more, and that one does not get enrolled, it gets closed.
Fewer than somebody wants to sell you, and more than one. The cut follows isolation boundaries, not the org chart: production separated from everything non productive, a dedicated account for security relevant logs, shared services where they are genuinely shared. One account per team sounds tidy and goes stale with the next reorganization. The technical limit stopped mattering a while ago: since August 2024 up to a thousand accounts fit in a single OU, and OUs may be nested.
They act in three different places, and that gets conflated often. An SCP caps what principals in your accounts may do; it grants nothing, it limits. An RCP caps what can be permitted on a resource, which means it also applies to principals that do not belong to your organization, and that is the case an SCP does not cover. A declarative policy does not put a frame around calls but sets a desired state for service attributes, enforced in the control plane of the service itself. In practice: SCPs for "must not", RCPs for "not from outside either", declarative policies for "should always be configured this way".
No, and that is a deliberate choice. A review delivers an assessment, and the same assessment is available from AWS partners at no cost, sometimes funded with credits. What gets built here is a change: an organization with OUs, a log account, access through SSO, guardrails and Terraform code your team carries on with afterwards. If a document were the only thing left at the end, this page would be misnamed.
Rarely, and mostly not at the start. Landing Zone Accelerator is built for heavily regulated environments that need many prepared controls and an elaborate network topology. It brings a corresponding amount of surface with it, and surface has to be understood and maintained by somebody. If your requirement is "we have to pass an audit and want our accounts separated", a lean landing zone you described yourself is easier to run. If your requirement is a catalogue of controls out of a regulatory framework, we look at the accelerator.
Billing is by time spent, with structure and foundation as a bounded three to six week engagement. There is deliberately no fixed price package here: between a single account and twenty grown accounts with three identity sources and an existing Control Tower installation lies work too different to price up front. After taking stock I can offer the rest at a fixed price; before that it would be guesswork.
No. I build the structure, describe it as code and hand it over. An account structure whose rules only an external contractor understands is a problem at exactly the moment things need to move fast, emergency access for instance. What remains are questions, which I am glad to answer, and no ownership.
Other services
From your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreWhen the AWS environment can only be administered by hand: take stock and import it, build clean state, remove drift, make environments reproducible.
Learn moreI find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn more