Do you need an AWS landing zone? No, not on day one. A single AWS account is the correct, boring choice for an early prototype, and standing up a full multi-account landing zone before you have anything to protect is premature optimization you will pay interest on. What matters is recognizing the handful of tipping points that turn a single account from “pragmatic” into “the finding your SOC 2 auditor writes up.” This piece is about spotting those points before they cost you a migration.
What does a single AWS account actually cost you?
Nothing, until you have production data, more than a couple of engineers, or a compliance obligation. Then it costs you on five fronts at once, and the bill arrives all at the same time.
- Blast radius. The account is the only hard security wall AWS gives you. One leaked CI token, one over-permissive role, one phished laptop, and the attacker has the whole company, because there is no inside wall to stop at.
- IAM sprawl. Roles and policies accumulate faster than anyone prunes them. By the time you look, there are dozens, at least one carries a
Resource: "*"nobody remembers granting, and “who can touch production” has become a policy-analysis research project instead of a list of names. - No hard environment isolation. Prod and dev share an IAM universe, the same account-scoped service quotas, and the same KMS keys. The load test that exhausts Lambda concurrency takes production down with it. Separation is a naming convention, which is to say it is not separation.
- Muddy billing. One account means one bill. Attributing spend to a team, a customer, or an environment depends entirely on tags that were enforced for about six weeks in 2023, so the allocation report is fiction with a currency column. Better tagging helps (cost-aware tagging is the fix), but a tag is a weaker boundary than an account.
- A weak audit boundary. When a SOC 2 or HIPAA assessor asks how production is isolated from development, “a tag” is an expensive answer. Assessors expect isolation to be structural, not procedural, and for a HIPAA workload the gap between those two words is a remediation project.
None of this is a problem for a two-person prototype with no real users. All of it is a problem the week you sign your first customer.
When should you move from a single account to multi-account?
When any one of the signals below is true, not when all of them are. The move is triggered by the first tipping point you hit, and in practice most teams hit “real data in production” and “a compliance requirement” within a quarter of each other. Do not wait for consensus among the signals. One is enough.
The signals, with what each one actually implies:
| Signal you’re ready | What it means | Routes you to |
|---|---|---|
| Real customer data, PHI, or PII in production | Blast radius stops being theoretical; a breach is now a notification event | Minimum viable, at least |
| A compliance requirement (SOC 2, HIPAA) | An assessor will ask how prod is isolated, and “a tag” fails | Full landing zone |
| Security review incoming (customer or investor DD) | Someone external is about to grade your account boundaries | Full landing zone |
| More than ~2-3 engineers | IAM sprawl and shared blast radius outpace anyone’s ability to reason about them | Minimum viable |
| Multiple environments (prod / staging / dev) | Environment separation by tag is not separation; quotas and IAM are shared | Minimum viable |
| Need clean per-team or per-customer billing / isolation | Tags cannot give you a hard cost or security boundary; accounts can | Minimum viable, growing |
Read the table as an OR, not an AND. Cross one line and you have outgrown the single account. Which target you build toward depends on whether compliance is in the picture yet.
What is a minimum viable landing zone?
Not the twenty-account enterprise build. The minimum that earns the name is four to five accounts: a management/org account that runs nothing and exists only for billing and org administration, a log-archive account that receives an organization-wide CloudTrail into an S3 bucket with Object Lock, a security/audit account that hosts your delegated security tooling, and separate prod and non-prod workload accounts so promotion exercises real isolation rather than a naming prefix.
That is the same three-account spine described in minimum viable HIPAA on AWS, plus the prod/non-prod split, and it is deliberately small. The point is to get the boundaries that matter (logs an admin cannot delete, a production account a leaked staging credential cannot reach, a management account nothing runs in) without minting an account per microservice. Account sprawl recreates the governance problem you left, with a monthly baseline bill in every account, because Config, GuardDuty, and Security Hub all meter per account.
Once you have decided the answer is yes, two follow-ups matter. The full topology, the OU map, and the service control policy starter set live in building a multi-account AWS landing zone. The build-versus-buy call, Control Tower against rolling your own in Terraform, lives in Control Tower vs. Terraform. Read both after you have crossed a tipping point, not before — they are the account-topology chapters of the broader platform engineering foundation a regulated startup grows into. Deciding the tooling while you are still a single account with no users is the same mistake in a different hat.
So which do you actually pick?
The verdict, stated plainly so you can stop deliberating:
- Pick a single account when you have no real customer data in production, no compliance obligation, three or fewer engineers, and one environment. This is early prototyping, and the correct move is to not build a landing zone. Turn on MFA for everyone, enable CloudTrail, set a budget alarm, lock the root credentials in a safe, and ship. You can retrofit later without moving production.
- Pick a minimum viable landing zone when you have real users or a second environment or a growing team, but no live compliance requirement yet. Four to five accounts. It buys you the boundaries that stop the worst outcomes without the operational weight of the full build.
- Pick a full landing zone when compliance is real (SOC 2 or HIPAA), a customer or investor security review is coming, or you need per-team or per-customer isolation. This is five OUs and roughly ten accounts with SCPs and Identity Center, and at this point it is not gold-plating, it is the thing the auditor is asking to see.
The good-enough bar: a leaked credential in your least-trusted environment cannot reach production data, and you can answer “how is prod isolated?” with a boundary an auditor accepts rather than a tag you hope holds. A single account clears that bar for a prototype with nothing to lose. It fails it the moment there is something to lose. The whole decision is figuring out which side of that line you are on today, and the honest answer is usually that you crossed it a month before you noticed.
The Template
Run this top to bottom. Any single checked box in the “tipping points” section means you have outgrown the single account. The rest tells you which target to build and what “done” looks like.
Tipping points (check any that are true today)
- Real customer data, PHI, or PII lives in production
- There is a SOC 2 or HIPAA requirement, signed or imminent
- A customer or investor security review is on the calendar
- The team is larger than 2-3 engineers with AWS access
- There is more than one environment (prod / staging / dev)
- You need clean per-team or per-customer cost or access isolation
If zero boxes are checked (stay single-account, do the basics)
- MFA enforced on every human with console access
- Root user locked away, not used, alarmed on login
- CloudTrail enabled and logging
- A budget alarm exists so a runaway resource is not a surprise invoice
If any box is checked, no compliance yet (minimum viable landing zone)
- Management/org account created; nothing runs in it
- Log-archive account receiving org-wide CloudTrail with S3 Object Lock
- Security/audit account for delegated security tooling
- Separate prod and non-prod workload accounts (not separate VPCs)
- IAM Identity Center for human access; zero per-account IAM users
- A non-overlapping CIDR plan covering accounts you have not created yet
If a box is checked and compliance is real (full landing zone)
- The five-OU topology from the build guide is in place
- Service control policies attached and exercised, not just written
- Delegated security tooling (GuardDuty, Security Hub, Access Analyzer)
- Tooling decision made deliberately (Control Tower vs. Terraform)
- Org definition under version control and drift detection
Most teams find themselves with one or two tipping-point boxes checked and none of the structural work started. That is a normal, fixable place to be. The path from there is to build toward the target the checked boxes point to, and no further.