Picture yourself at an AWS-using startup. It’s a year or two old and maybe starting to see product-market fit. As the CTO or one of the first engineers, you’ve made but a fraction of the architectural and technical decisions that will be made over the course of the company’s future. Most of the coworkers you’ll have don’t work there yet.

The company has one AWS account. You’ve heard that you should have lots of AWS accounts, and that sounds like a headache so you’re tempted to put it off. Startups have long been taught to do things that don’t scale, to move fast, to take on technical debt. And having one giant AWS account is technical debt. So conventional wisdom would say that it’s fine, right?

What is technical debt?

Software engineers use the term technical debt to describe decisions that give a benefit now for a cost paid later. Commonly, the benefit is shipping something faster and the cost is needing to refactor or replace the code later.

Is technical debt good or bad?

Not all technical debt carries the same interest rate. Honestly, not all the things folks call technical debt are even technical debt. Real technical debt gets you a quick win but costs you a little something every day after and always comes due eventually. Some examples:

• Good technical debt: The naive algorithm for an important product feature runs in O(n²) time. You choose to spend five minutes coding the naive algorithm and slap a comment on it explaining that the absolute running time of the algorithm will become a problem somewhere around 100,000 users. This is good technical debt!
• Not technical debt: You build your product as a monolithic application using a popular framework, backed by a proven database. Maybe one day your team or traffic will motivate a more service-oriented architecture but that would take longer to build today. This is not technical debt! Technology choices you’ll only maybe outgrow but save you unfathomable time today are just good architectural decisions.
• Bad technical debt: You have one giant AWS account. Later, you’ll have to undertake a year-long migration to isolate environments and services, reduce the blast-radius of changes, and segment access. But at least right now you…constantly cause outages when development changes accidentally affect production. This is bad technical debt! The interest is steep and you start paying it immediately. It costs you later and it costs you now.

Split up that giant AWS account now!

Why is one giant AWS account a technical debt that will absolutely come due? Because isolation between environments and services is the foundation of both security and reliability. And accounts are the one true unit of isolation in AWS. Isolation means you can test changes safely. Isolation gives each environment or even service their own allocation of AWS rate limits and service quotas. Isolation means one team can’t impact another. Isolation means costs are automatically allocated.

Having lots of AWS accounts from the beginning also isn’t a drag on productivity. For the cost of assuming an IAM role, you gain confidence that you can test in development without impacting production. Tools like Substrate make this downright pleasant.