"We don't need 10+ AWS accounts. It's overkill for us—we can do this later after we launch. This will slow down product development and add unnecessary complexity."

I've heard this pushback dozens of times. And here's the thing: the instincts behind it aren't wrong.

It can feel like over-investing in infrastructure too early. It is more accounts than most people new to AWS start with. And if you've used multi-account setups before without good tooling, they absolutely can feel cumbersome and slow.

On top of that, understanding someone else's infrastructure code is always harder than code you wrote yourself, and you don't even know the final product architecture yet—shipping the product has to be the priority.

All of that is fair.

The Most Common Misunderstanding

The counterproposal usually sounds reasonable:

"We just need dev, staging, and production accounts. Anything more is unnecessary complexity."

Here's the thing: this is correct. To operate any product on AWS, you need a minimum of one account per SDLC stage—dev, staging, production. That's the baseline.

The misunderstanding comes when you look at this holistically: what does the organization need to operate securely? There's more than your software at stake.

The "three accounts" view only considers the application. It ignores everything else the organization needs to function—and that's where it breaks down the moment you start asking concrete questions.

Where do logs live?

If they're centralized—and they should be for security, compliance, and tamper resistance—they can't live in dev/staging/prod. Hence an audit account.

Where does your container registry live?

If you rebuild container images per account, you're triplicating images and not running what you tested. If you promote artifacts—which you should—a shared account is the logical solution. Hence an artifacts account.

Where do CI runners run?

In every account? That's 3× the cost and operational overhead. If centralized, how do they securely talk to services across accounts? Hence an automation account and a transit gateway. Don't think you need self-hosted runners? Make sure you have other ways to manage Kubernetes and RDS databases on private subnets.

None of these are future-state problems—they show up fast.

When you put it all together—answering each of those concrete questions—you end up with:

1. Root (Management) account — Organization root, billing, SCPs
2. Network account — Transit gateway, shared networking
3. DNS account (optional) — Acts as your DNS registrar
4. Audit account — CloudTrail, Config, centralized logging
5. Security account — Security Hub, GuardDuty, incident response
6. Artifacts account — ECR, shared packages, build outputs
7. Automation account — CI/CD runners, deployment pipelines
8. Dev account — Development workloads
9. Staging account — Pre-production testing
10. Prod account — Production workloads

That's 9–10 accounts for a minimal level of isolation.

Not because someone decided "9–10 is the right number." Because each account answers a specific question that you'll have to answer anyway. The accounts aren't arbitrary—they're the natural result of thinking through where things actually need to live.

Does this seem like a lot? Consider what happens without these boundaries:

• Dev and prod share the same account, meaning one IAM misconfiguration exposes production
• Logs live alongside the systems they're supposed to audit
• CI/CD has broad access to everything because there's no other way
• Artifact promotion becomes "hope we tagged the right image"

The accounts aren't bureaucracy. They're guardrails that let you move faster, not slower.

The "We Can Always Add Accounts Later" Myth

Here's the thing: you can add accounts later. That's not the myth.

The myth is believing it's easy or cheap to do later. It's not.

Adding accounts later requires complex migrations, scheduling and coordination across teams, and untangling months or years of decisions built on faulty assumptions—like CIDR allocations that don't support peering or future growth.

Some accounts are genuinely optional. If you're never going to have self-hosted runners, skip the automation account. If you're never using AWS as a DNS registrar, skip the DNS account. No big deal.

But some decisions are foundational—and brutal to change later:

• Not separating dev/staging/prod? Hard to untangle.
• Running everything in root? Even worse.
• Assigning all accounts the same VPC CIDR? Now everything goes through expensive NAT gateways, or you're re-IPing entire environments.
• Not factoring regions, accounts, and namespaces into resource names? You'll hit conflicts when you expand.
• Using VPC peering instead of Transit Gateway? Works fine with 2-3 accounts—becomes a nightmare with more accounts or multi-region.

The accounts themselves might sit empty for a while. But the architectural decisions you make on day one—CIDR allocation strategy, naming conventions, network topology—those get baked in immediately.

Here's the real message: unless you operate today like you'll have multiple accounts, adding more accounts later won't make a difference.

You need to instill multi-account practices now in how you architect your applications and base your assumptions. It affects everything: network CIDR allocations, naming conventions, S3 bucket naming, Terraform state storage, DNS architecture, IAM trust relationships.

Create the boundaries now. Use them as the problems present themselves. If you wait until you need them, you're not just creating accounts—you're untangling everything you built assuming they didn't exist.

Multi-Account Enables Developer Autonomy

There's another reason account boundaries matter that's easy to underestimate:

VPCs only give you network isolation. Accounts are the only hard IAM boundary AWS gives you.

If your goal is developer autonomy—letting engineers move fast without stepping on each other—fewer accounts actually makes that harder, not easier.

You end up either doing fragile IAM gymnastics, or giving everyone administrative access—which is very hard to walk back. Clean account boundaries let devs have broad access in some places and almost none in others—especially around production and security.

And here's the uncomfortable truth: nothing is harder to craft than IAM policies.

Getting IAM right in a single-account setup where you need to simulate multi-account boundaries is exponentially more complex than just having the boundaries in the first place.

This Isn't Over-Engineering (It's Choosing Where to Pay the Cost)

This might look like over-engineering. It's not—it's choosing where to pay the cost.

Here's the key: it's only complicated if you don't have the right tooling, conventions, and a framework that ties it together.

With the right tooling (like Atmos), managing 10 accounts isn't harder than managing 3. The complexity objection assumes you're doing this manually or piecing it together yourself. A proper framework handles the multi-account orchestration for you.

Simple account setups optimize for getting started. Multi-account setups optimize for not having to unlearn assumptions later.

You're not adding complexity. You're preventing it.

The complexity of multi-team access, centralized logging, artifact promotion, and network segmentation is coming whether you plan for it or not. The only question is whether you have clean boundaries when it arrives, or whether you're retrofitting them into a single-account monolith.

The math is simple:

• Starting clean = a couple of weeks (especially with a battle-tested reference architecture)
• Untangling later = 6–12 months of migration and rework

Closing Thought

I genuinely understand the pushback. The instinct to ship fast and avoid premature complexity is exactly right in most contexts.

But AWS account boundaries aren't premature complexity—they're deferred simplicity. The complexity exists regardless. The only question is whether you've given it clean places to live.

Starting clean is weeks. Untangling later is months.

Choose wisely.

If you're navigating this conversation internally and want help making the case—or just want to talk through the tradeoffs with someone who's been there—talk to an engineer. No sales theater. Just engineers who understand both the technical reality and the organizational dynamics at play.