The AWS account layout that keeps your bill honest
The whitepaper answer to "how many AWS accounts should we have?" assumes you have a platform team. Most companies I work with have one overloaded DevOps engineer, if that. So here's the layout I actually deploy — including the places where I deliberately cheat on the textbook.
What's non-negotiable
Production gets its own account. Always. Blast radius, IAM clarity, a bill you can read. And an AWS Organization with centralized billing and guardrails from day one, because retrofitting one under a running company is miserable work. That much of the textbook survives contact with reality.
Where I cheat
Everything non-production often lives in one account — dev, test, staging side by side, separated by naming and tags. Purists wince. But for a twenty-engineer company, the isolation you gain from three more accounts rarely justifies the cross-account plumbing you'll maintain forever to make them usable.
One ECR, shared everywhere. Build an image once and promote the same digest from dev to production with cross-account pull permissions. Copying images between per-environment registries costs storage, transfer, and eventually a 2 a.m. mystery about which environment ran which build.
A shared VPC in non-prod. NAT gateways run about $32 a month each in us-east-1 before you push a byte through them (AWS VPC pricing) — three environments times three AZs of "proper" isolation is real money for mostly imaginary safety at this scale. Share the VPC (Resource Access Manager makes it painless), keep the subnets separated, and spend the difference on monitoring.
Sometimes even a shared RDS instance in non-prod, one schema per environment. That one depends on the data and the team — and it's the first thing to unshare when growth arrives.
When to stop cheating
All of this is stage-appropriate, not permanent. A compliance framework lands, a team gets its own on-call, non-prod environments start stepping on each other — split them out. This is exactly why the IaC-from-day-one rule matters: if your accounts are declared in code, the split is a refactor. If they were built by hand, it's a migration.
The principle underneath all of it: your account layout — and your bill — should match the stage you're at, not the org chart you hope to have someday.