The Multi-Account Mindset Shift
"We don't need 10 AWS accounts. That's overkill for a company our size."
I've heard this pushback dozens of times. And here's the thing—the instinct behind it isn't wrong.
Shipping fast matters. Premature complexity kills.
But here's what gets missed: those 9-10 accounts aren't arbitrary bureaucracy. Each one answers a specific question you'll have to answer anyway.
The Questions You Can't Avoid
Where do logs live that can't be tampered with by the systems they're auditing?
Where do container images get promoted from (not rebuilt)?
Where do CI runners securely talk to services across environments?
These aren't enterprise concerns. They're "we need to not shoot ourselves in the foot" concerns.
As I explored in Why You Need More AWS Accounts Than You Think, the math is simple:
- Starting clean = a couple of weeks
- Untangling later = 6-12 months of migration pain
The Real Complexity Objection
"But managing 10 accounts is harder than managing 3."
This assumes you're managing them manually.
With the right tooling—Terraform, Atmos, a proper multi-account framework—managing 10 accounts isn't meaningfully harder than managing 3.
The complexity you're avoiding isn't account management. It's the organizational complexity of figuring out where things should live.
And that complexity is coming whether you plan for it or not.
The IAM Reality Check
Nothing is harder to craft than IAM policies.
And getting IAM right in a single-account setup where you need to simulate multi-account boundaries? That's exponentially more complex than just having the boundaries in the first place.
Think about it:
In a multi-account setup:
- Devs get admin in dev account
- Read-only in staging
- Almost nothing in prod
- Clean. Simple. Auditable.
In a single-account setup:
- Resource-based policies everywhere
- Tag-based access control (pray they tagged correctly)
- Condition keys for days
- Constant IAM troubleshooting
Which one sounds "simpler" now?
What This Means for You
If you're just getting started:
Accept that you'll end up with more accounts. The question is whether you architect for it now or pay the migration tax later.
Don't start with the tools. Start with the questions: Where do logs go? Where does CI/CD live? Where do artifacts get promoted?
Get the network topology right. CIDR allocations, transit gateway, DNS delegation—these are brutal to change later.
The accounts themselves might sit empty for a while. That's fine.
The architecture decisions can't wait.
Ready to get your AWS foundation right the first time?
Talk to an engineer — no sales theater, just a real conversation about what you're building.
Erik Osterman Founder & CEO, Cloud Posse