A company runs everything in a single AWS account and asks you to move to a multi-account setup. How would you structure the accounts and OUs, and what does AWS Control Tower add over assembling it yourself?
answer
- account is the strongest blast-radius wall
- OUs carry policies, not reporting lines
- log archive lives outside everyone's reach
- account vending is the real unlock
- opinionated baseline versus owning it yourself
basics
~20 sSplit by blast radius and governance rather than by team: an empty management account, a Security OU with log archive and audit accounts, shared infrastructure, and separate production and non-production workload accounts under OUs that carry the guardrail SCPs. Control Tower assembles and maintains that baseline for you.
solid answer
~60 sThe account boundary is the strongest isolation AWS offers — separate IAM, separate quotas, separate blast radius, separate bill — so I split where I want a hard wall: production apart from everything else, security tooling and log archive in their own accounts, shared networking in another, and a loose sandbox for experiments. OUs then mirror governance, not the org chart, because OUs exist to carry policies: a Security OU, an Infrastructure OU, Workloads split into Prod and Non-Prod, and Sandbox. Guardrails go on as deny-list SCPs — region pinning, no disabling the trail or the detection services, no leaving the organization — with the tightest set on Prod. AWS Control Tower builds this landing zone for you: it creates the log archive and audit accounts, sets up the organization trail and config aggregation, applies a curated set of controls, and vends new accounts through Account Factory already enrolled. The tradeoff is opinionation — it owns resources you must not hand-edit and constrains how you evolve the structure — so a large org with an existing platform team sometimes runs the same shape without it.
go deeper
Be able to say why more than one account exists at all — isolation of blast radius, quotas and cost — and that OUs group accounts so policies can be attached once.
Describe the standard account set (management, log archive, audit, shared infrastructure, prod, non-prod, sandbox) and know that Control Tower creates and baselines much of it for you.
Justify each boundary against its running cost, place the guardrail SCPs at the right level, and explain Control Tower's three control types and which resources it owns and you must not edit.
Own the decision itself — Control Tower's opinionation versus building on Organizations directly — and a migration sequence that delivers logging and guardrails before workload moves, so the programme survives contact with delivery pressure.
## Why more than one account An AWS account is the strongest boundary the platform has. Within one account, IAM is the only thing standing between a mistake and your production data, service quotas are shared, one runaway workload can throttle another, and cost attribution depends on tagging discipline that never quite holds. Across accounts, isolation is structural: a compromised principal in one account has no reach into another unless you built a path, quotas are per account, and the bill separates itself. That is the argument for splitting. The counter-argument is real too: every account needs credentials, network attachment, pipelines, monitoring and someone to own it. So you split where the wall is worth the overhead, not everywhere. ## Where to draw the lines Good boundaries, roughly in priority order: 1. **Production vs everything else.** The single highest-value wall. Different guardrails, different access, different change process. 2. **Log archive.** A dedicated account that receives the organization's trail and other audit data, with almost nobody able to write to it and nobody able to delete. Its whole purpose is being outside the reach of anyone who might want to erase evidence — including a compromised management account. 3. **Security tooling / audit.** Where detection and compliance services are aggregated organization-wide, via delegated administration so the work does not happen in the management account. 4. **Shared infrastructure.** Networking, shared DNS, shared build infrastructure — things many accounts consume. 5. **Sandbox.** A deliberately loose account or set of accounts, isolated from everything, with a spend guardrail and a short list of permitted services. 6. **Per-workload or per-team splits** below that, if isolation, quota pressure or chargeback justifies it. The management account holds none of this. It owns the organization and the bill, and nothing else. ## OUs mirror governance, not the org chart OUs exist to carry policies, so group accounts that should share a ceiling. A typical shape: ``` Root ├── Security (LogArchive, Audit) ├── Infrastructure (Network, SharedServices) ├── Workloads │ ├── Prod │ └── NonProd └── Sandbox ``` Structuring by department is the classic mistake: reorganisations then force account moves, and a move silently changes an account's ceiling. Governance requirements change far more slowly than org charts. Guardrails go on as deny-list SCPs — keep `FullAWSAccess`, add targeted Deny statements. Root-level: pin to approved regions, forbid disabling CloudTrail/Config/GuardDuty, forbid `organizations:LeaveOrganization`, protect the roles the landing zone manages. Prod-level: additionally deny anything that shortcuts the change process. Sandbox: deny the expensive instance families and anything that can reach production networking. ## What Control Tower actually does AWS Control Tower is an opinionated assembler of the above. On setup it creates a **landing zone**: an organization (or adopts an existing one), a Security OU with a **log archive** account and an **audit** account, an organization-level trail delivering to log archive, config aggregation, and a baseline of **controls**. Controls come in three flavours, and knowing which is which is the useful detail: - **Preventive** controls are implemented as SCPs — they stop the action. - **Detective** controls are implemented as Config rules — they report drift after the fact. - **Proactive** controls check resources before they are deployed. Each control is labelled mandatory, strongly recommended or elective, so the baseline is a curated starting set rather than a blank page. **Account Factory** then vends new accounts already enrolled: placed in an OU, baselined, controls applied, sign-in wired up. That is the part that pays for itself — the marginal cost of a new account drops enough that teams stop cramming workloads into an existing one. ## The tradeoff Control Tower owns resources. It manages roles, SCPs and a trail that you must not hand-edit, and drift shows up as an account needing re-enrolment. It has opinions about OU structure and about how accounts are provisioned, and evolving the landing zone means going through its update process rather than editing pieces directly. Region availability and the set of controls also constrain what you can express. So the honest answer is conditional. A company moving off a single account with no platform team should use Control Tower — the baseline is better than what they would write, and the account vending is the difference between a good design and a design that stays on paper. A large organization with an existing platform team and its own provisioning pipeline often builds the identical structure directly on Organizations, because they want to own the policy lifecycle end to end and do not want a managed service holding resources they need to change. ## Sequencing the migration Do not try to split everything at once. Stand up the organization and the security accounts first, get logging centralised, and put the universal guardrails on in warn-then-enforce order. Then move the easiest workloads — new services and non-production environments — into new accounts, and leave the legacy account as one more workload account that shrinks over time. Human access gets layered on top with a single sign-in path rather than per-account credentials, and cost visibility comes for free from the account split itself, which is often the change that gets everyone else on board.
- Why structure OUs around governance instead of around teams or departments?Because OUs exist to carry policies, and an account inherits the ceiling of wherever it sits. If OUs mirror the org chart, every reorganisation forces account moves, and each move silently changes what those accounts may do. Governance requirements — production versus not, regulated versus not, sandbox — change far more slowly and map directly onto the policies you actually want to attach.
- What is the point of a separate log archive account if you already have an organization trail?Separation of duties. The trail records what happened; the archive account makes the record hard to destroy, including by someone powerful in the management account. Almost nobody gets write access and nobody gets delete, so an attacker who compromises a workload account — or the organization itself — cannot quietly erase their tracks. It is the account whose value is entirely in who cannot touch it.
- When would you deliberately not use Control Tower?When you already have a platform team and a provisioning pipeline that owns the account lifecycle, and you want full control of the policy lifecycle without a managed service holding resources you must not hand-edit. Its opinions about OU shape, its update process and its control catalogue are worth it when they replace something worse; they are friction when they replace something you already run well.
- How do you sequence the move without a big-bang migration?Stand up the organization and security accounts first, centralise logging, then add universal guardrails in a warn-then-enforce order. Move new services and non-production environments into fresh accounts, and treat the original account as one more workload account that shrinks over time. Nothing forces a single cutover, and the account split delivers cost visibility early, which is usually what keeps the effort funded.
saying these in an interview costs you the question
- Structures OUs to mirror the company org chart
- Keeps shared tooling in the management account
- Creates one account per team and calls it isolation
- Assumes Control Tower resources can be edited by hand
- Treats consolidated billing as the main reason to split accounts