One AWS account per project is the simplest piece of cloud hygiene almost nobody does, because setting it up by hand takes a day you’d rather spend building. That’s a shame, because the account boundary is the only wall in AWS that nothing can climb over: not a bad script, not a runaway bill, not an over-eager AI agent with admin rights.
This post explains what “an AWS account per project” actually means, the four problems it solves, why “one big account with good tags” quietly falls apart, and how AWS Organizations makes extra accounts free.
What “one AWS account per project” means
It means each product, experiment or client job runs in its own AWS account, and those accounts are grouped under a single AWS Organization that you own. The Organization pays one bill; each account keeps its own resources, permissions and limits.
A few terms, so the rest of this makes sense:
- Management account: the root of the Organization. It should run nothing. It exists to create accounts, pay the bill and hold the guardrails.
- Member account: a normal AWS account that belongs to the Organization. This is where a project lives.
- Organizational unit (OU): a folder for accounts. You can attach policies to an OU and every account inside inherits them.
If you later want separate dev and prod for one project, that’s two member accounts in the same OU. The pattern scales down to one tiny side project and up to a company with hundreds of workloads without changing shape. AWS describes this layout in its own multi-account guidance.
Four problems a per-project account solves
A separate account gives you a hard boundary for mistakes, a clean bill, independent service limits and a one-click teardown. Each of those is painful to fake inside a shared account.
1. Blast radius
Inside one account, every resource can see every other resource unless you’ve written IAM policies to stop it. A deploy script that runs delete against the wrong resource name, a Lambda that loops and hammers a shared database, or an AI coding agent that decides to “clean up unused buckets” can all reach across projects.
Inside its own account, a project can only break itself. You don’t need a perfect IAM policy to protect the other projects, because the other projects are somewhere else. This matters more now that agents write and run infrastructure code; we cover the specifics in how to keep AI coding agents away from production.
2. A bill you can read
Each account produces its own line on the consolidated bill. You open Billing in the management account and see Project A: $0.00, Project B: $3.12, Client C: $41.80. No tag filters, no cost allocation reports, no “unallocated” bucket where half the spend hides.
That also makes avoiding a surprise AWS bill much easier: an AWS Budget alert per account tells you exactly which project misbehaved.
3. Independent quotas
AWS service quotas (Lambda concurrency, API Gateway requests per second, the number of VPCs, and so on) apply per account, per region. In a shared account, one project’s load test can push another project into throttling. In separate accounts, every project starts with a full set of limits. See AWS service quotas for the defaults.
4. Clean deletion
Projects end. In a shared account, killing one means finding every resource it created, in every region, and hoping nothing shared is tangled in. People skip this, and the zombie resources keep costing a few cents a month forever.
In its own account, you close the account. AWS stops billing it and removes the resources after the retention window. Done.
Why “one account with tags” drifts
Tags work until the first person forgets to add one, and then the cost report has an “untagged” row that grows every month. Tagging is a discipline; an account boundary is a fact.
The tagging approach also doesn’t help with the other three problems. A tag doesn’t stop a script from deleting a resource that belongs to a different project. A tag doesn’t give you a separate Lambda concurrency limit. A tag doesn’t let you close a project with one action.
There’s a subtler issue. IAM policies that scope access by tag are possible but fiddly: you need condition keys on every statement, enforced tag-on-create rules, and tests to prove it all works. Most solo developers and small teams never finish that work, so the “shared account with good tags” becomes a shared account with admin rights everywhere. That’s the setup that leaks.
How to do it with AWS Organizations
Create an Organization from a dedicated management account, make one OU per project, create a member account inside it, and sign in through IAM Identity Center. Accounts are free; the bill is consolidated.
Here are the steps, in order:
- Create or pick a management account. It should contain nothing but the Organization itself. If your only AWS account already runs workloads, create a fresh one to be the management account and invite the old one in as a member.
- Enable AWS Organizations with “all features” turned on, so you can use service control policies later. The Organizations user guide walks through this.
- Create an OU per project (or per project per environment, if you want dev and prod split from day one; see why dev and prod shouldn’t share an account).
- Create a member account inside the OU. Each account needs a unique email address. The
+trick works with most providers:you+projectname@example.com. - Set up IAM Identity Center (formerly AWS SSO) in the management account, so you sign in once and switch between accounts without juggling access keys.
- Attach a service control policy to the OU that blocks the things no project should ever do: leaving the Organization, disabling CloudTrail, creating IAM users with access keys.
- Wire deployments per account. Each project’s GitHub repository gets its own OIDC role in its own account. That’s covered in keyless deploys from GitHub Actions to AWS.
That’s the honest list, and it’s why most people don’t do it: steps 1 to 7 take an afternoon the first time and an hour or two every time after, before you’ve written a line of product code. This is the part TigerSoup automates. It creates the account, the OU, the roles and the deploy connection for a new project in under a minute, so the only decision left is the project’s name.
One billing note: an account that belongs to an Organization is moved onto the AWS Paid plan, so the sign-up credits that new standalone accounts receive don’t apply. Nothing in this setup has a monthly fee and the always-free allowances still work, but don’t plan around credits. We explain the details in the AWS Free Tier in 2026.
When not to bother
Skip this if you have exactly one project and you’re sure it’ll stay that way. A single account with a budget alert is fine for one thing.
The moment you start a second project, though, you’ve got a shared account, and every problem above starts to apply. It’s much easier to begin with the Organization in place than to migrate a running project into one later. Moving resources between AWS accounts is a rebuild, not a drag-and-drop.
A second exception: if your company already has a platform team running a landing zone, use their process. The point of this post is that you shouldn’t need a platform team to get the same isolation they’d give you.
Where this fits in a new project
A separate account is the first item on any sensible new project setup checklist. It costs nothing to run, it’s the one guardrail that doesn’t rely on anyone remembering anything, and it’s much cheaper to do on day one than on day ninety.
If you’d rather not spend the afternoon, TigerSoup is a free Mac app that sets up the account, a private GitHub repository and keyless deploys for each new project, with production gated. The accounts it creates are yours, in your own Organization, so there’s nothing to migrate if you stop using it.
