Single-account AWS is a ticking time bomb. I don’t say that lightly. I’ve watched it blow up firsthand, and I’ve spent more hours than I’d like to admit cleaning up the aftermath. If you’re running anything beyond a personal side project in a single AWS account, you’re playing a game you will eventually lose.

This is the guide I wish I’d had years ago. I’m going to walk you through AWS Organizations, Control Tower, SCPs, and account vending — the full multi-account strategy that actually works in production.

The War Story That Changed Everything

A few years back, I was working with a team that ran everything in one AWS account. Dev, staging, prod — all of it. Same account, same VPC, same mess. We had IAM policies, sure, but they’d grown organically into a tangled web that nobody fully understood.

One Thursday afternoon, a junior developer was cleaning up some test resources. They’d been asked to tear down a dev environment that was racking up costs. Reasonable task. Except the naming conventions were inconsistent, and the dev resources looked almost identical to production. They ran a delete script. It hit prod.

The database was gone. The S3 buckets were gone. We had backups, thankfully, but the recovery took the better part of two days. Two days of downtime, frantic Slack messages, and a postmortem that basically concluded: “We shouldn’t have had everything in one account.”

That was the moment I became a zealot for multi-account strategy. Not because it’s trendy or because AWS recommends it — because I’ve seen what happens without it. The blast radius of a mistake in a single account is unlimited. In a multi-account setup, the worst someone can do is destroy their own sandbox.

Why Multi-Account Isn’t Optional Anymore

Here’s the thing — AWS itself is designed around the assumption that you’ll use multiple accounts. IAM has hard limits per account. Service quotas are per account. CloudTrail, Config, GuardDuty — they all work better when you’ve got clean account boundaries.

The benefits stack up fast:

  • Blast radius containment. A misconfigured IAM role in dev can’t touch prod.
  • Clean billing. You can see exactly what each team, project, or environment costs without tagging gymnastics. This ties directly into AWS cost optimization — you can’t optimize what you can’t measure.
  • Service quota isolation. That load test someone’s running in dev won’t eat into your prod API rate limits.
  • Security boundaries. Real ones, not “please don’t touch that” ones. This is foundational to zero trust networking.
  • Compliance. Auditors love account-level separation. It makes their job easier, which makes your life easier.

If you’re designing scalable systems in AWS, multi-account isn’t a nice-to-have. It’s table stakes.

AWS Organizations: The Foundation

AWS Organizations is the backbone. It lets you create and manage multiple accounts under a single management account, organize them into Organizational Units (OUs), and apply policies across the board.

Setting it up is straightforward. From your management account:

aws organizations create-organization --feature-set ALL

That ALL feature set is important — it gives you access to SCPs, which are the real power here. Don’t use CONSOLIDATED_BILLING only unless you genuinely don’t want governance capabilities.

Now create your OU structure. I’ve landed on something like this after a few iterations:

# Core OUs
aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Security"

aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Infrastructure"

aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Workloads"

aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Sandbox"

My recommended OU structure:

  • Security — Log archive, security tooling, audit accounts.
  • Infrastructure — Shared networking, DNS, CI/CD tooling.
  • Workloads — Nested OUs for prod, staging, dev per team or product.
  • Sandbox — Individual developer experimentation accounts with aggressive guardrails and budget limits.

Don’t overthink the OU hierarchy on day one. You can move accounts between OUs later. What matters is getting the separation started.

Control Tower: Guardrails Without the Pain

AWS Control Tower sits on top of Organizations and gives you a landing zone — a pre-configured multi-account environment with sensible defaults. It’s opinionated, and I mean that as a compliment.

I used to set all of this up manually. Custom CloudFormation stacks for log aggregation, hand-rolled Config rules, bespoke IAM policies for cross-account access. It worked, but it was brittle and took weeks to get right. Control Tower does it in about an hour.

What you get out of the box:

  • A management account, a log archive account, and an audit account.
  • AWS SSO (now IAM Identity Center) configured for centralized access.
  • CloudTrail enabled across all accounts, logs shipped to the log archive.
  • Config rules running as guardrails.
  • Account Factory for provisioning new accounts with your baseline.

You set it up through the console initially — there’s no CLI for the initial landing zone setup, and that’s fine. It’s a one-time operation. After that, everything’s manageable through APIs and infrastructure as code.

The guardrails are where Control Tower earns its keep. They come in two flavors:

  • Preventive guardrails — These are SCPs under the hood. They stop actions before they happen.
  • Detective guardrails — These are Config rules. They flag non-compliant resources after the fact.

Enable the mandatory ones (they’re on by default) and then selectively enable strongly recommended ones based on your compliance needs. Don’t enable everything at once — you’ll break things and create alert fatigue.

SCPs: The Policies That Actually Bite

Service Control Policies are the teeth of your multi-account strategy. Unlike IAM policies, which grant permissions, SCPs set the maximum permissions boundary for an entire account. Even the root user can’t bypass them.

Here’s an SCP I attach to every production OU. It prevents anyone from disabling CloudTrail or leaving the approved regions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "sts:*",
        "organizations:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

Attach it like this:

aws organizations create-policy \
  --name "ProdGuardrails" \
  --type SERVICE_CONTROL_POLICY \
  --content file://prod-scp.json \
  --description "Guardrails for production accounts"

aws organizations attach-policy \
  --policy-id p-xxxxxxxxxxxx \
  --target-id ou-xxxx-xxxxxxxx

A few SCP patterns I’ve found essential:

  • Deny region sprawl. Lock accounts to your approved regions. Resources in forgotten regions are a security and cost nightmare.
  • Protect logging. Nobody should be able to disable CloudTrail, Config, or GuardDuty in any account.
  • Deny root user activity. The account root user should never be used for day-to-day work. SCP it away.
  • Restrict VPC modifications in prod. Network changes should go through infrastructure-as-code pipelines, not the console.

One gotcha: SCPs don’t affect the management account. Ever. That’s why your management account should have almost nothing running in it. It’s a governance account, not a workload account.

Account Vending: Automation Over Tickets

Account vending is the process of spinning up new AWS accounts that are pre-configured with your baseline — networking, IAM roles, security tooling, budget alerts, the works. If creating a new account requires a Jira ticket and two weeks of manual setup, you’ve already lost.

Control Tower’s Account Factory handles the basics. You define an account blueprint, and it provisions accounts with your guardrails and configurations baked in. But for anything serious, you’ll want to layer Terraform or CloudFormation on top.

Here’s what my account vending pipeline does:

  1. Developer requests an account through a self-service portal (or a CLI tool).
  2. A Step Functions workflow triggers.
  3. Control Tower Account Factory creates the account.
  4. A Terraform pipeline runs against the new account, deploying the baseline: VPC, security groups, IAM roles, Config rules, budget alarms.
  5. The account ID and access details land in the team’s Slack channel.

The whole thing takes about fifteen minutes. No tickets, no waiting, no drift.

For the Terraform baseline, I keep it modular. Each account gets:

# Example: applying baseline to a new account
cd account-baseline/
terraform init -backend-config="key=accounts/${ACCOUNT_ID}/terraform.tfstate"
terraform apply \
  -var="account_id=${ACCOUNT_ID}" \
  -var="account_email=${ACCOUNT_EMAIL}" \
  -var="environment=dev" \
  -auto-approve

The baseline modules cover VPC setup, CloudWatch alarms, IAM roles for CI/CD, and secrets management configuration. Every account starts identical, and drift detection catches anything that changes.

Cross-Account Access Done Right

With multiple accounts, you need a clean way to move between them. IAM Identity Center (formerly AWS SSO) is the answer. Forget about IAM users with long-lived credentials scattered across accounts. That’s how breaches happen.

Set up permission sets that map to job functions:

# List your Identity Center instance
aws sso-admin list-instances

# Create a permission set
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxx \
  --name "DeveloperAccess" \
  --session-duration "PT8H"

I typically create these permission sets:

  • AdminAccess — Full admin, restricted to infrastructure team, only for break-glass scenarios in prod.
  • DeveloperAccess — PowerUser minus IAM and networking changes. This is what most devs use daily.
  • ReadOnlyAccess — For auditors, on-call engineers reviewing dashboards, and anyone who just needs to look.
  • DeploymentAccess — Used by CI/CD pipelines. Scoped tightly to the services the pipeline actually deploys.

Developers authenticate once through Identity Center and then assume roles into whichever account they need. No shared credentials, no long-lived keys, full CloudTrail audit trail. It’s how cross-account access should work.

For CI/CD pipelines, I use OIDC federation with short-lived credentials rather than storing access keys. Your deployment role in each target account trusts the pipeline’s OIDC provider. No secrets to rotate, no keys to leak.

Networking Across Accounts

Multi-account networking trips people up. The instinct is to peer every VPC to every other VPC, and suddenly you’ve got a mesh that’s impossible to reason about.

Use AWS Transit Gateway. One Transit Gateway in your infrastructure account, shared via RAM (Resource Access Manager) to your workload accounts:

# Share Transit Gateway with your organization
aws ram create-resource-share \
  --name "SharedTransitGateway" \
  --resource-arns arn:aws:ec2:us-east-1:111111111111:transit-gateway/tgw-xxxxxxxxx \
  --principals arn:aws:organizations::111111111111:organization/o-xxxxxxxxxx

Route tables on the Transit Gateway control which accounts can talk to each other. Prod can reach shared services but not dev. Dev can reach the internet through a centralized NAT but can’t route to prod. The network topology enforces the same boundaries your SCPs do.

For DNS, use Route 53 Private Hosted Zones shared across accounts. Centralize your DNS in the infrastructure account and associate the zones with VPCs in workload accounts. Clean, manageable, and no more hardcoded IPs.

Monitoring and Compliance at Scale

You can’t manage what you can’t see. With dozens of accounts, centralized observability isn’t optional.

My setup:

  • CloudTrail — Organization trail, all events shipped to the log archive account. Non-negotiable.
  • AWS Config — Aggregator in the audit account pulling compliance data from every account.
  • GuardDuty — Delegated administrator in the security account, monitoring all member accounts.
  • Security Hub — Same pattern, delegated to the security account, aggregating findings org-wide.
# Enable GuardDuty org-wide from delegated admin
aws guardduty create-members \
  --detector-id xxxxxxxxxxxx \
  --account-details AccountId=222222222222,Email=<email>

aws guardduty update-organization-configuration \
  --detector-id xxxxxxxxxxxx \
  --auto-enable

Pipe Security Hub findings into a central SNS topic or EventBridge bus. From there, route critical findings to PagerDuty or Slack. Low-severity findings go to a dashboard that the security team reviews weekly.

The key insight: delegate administration to the security account, not the management account. Keep the management account clean.

Mistakes I’ve Made So You Don’t Have To

I’ve been doing this long enough to have a decent collection of scars. Here’s what I’d tell past-me:

Don’t put workloads in the management account. I know it’s tempting. It’s right there. But the management account is immune to SCPs, which means it’s your least governed account. Use it for Organizations management and nothing else.

Don’t skip the sandbox OU. Developers need a place to experiment without fear. Give them sandbox accounts with tight budget alerts and aggressive SCPs that prevent anything expensive. A $50/month budget alarm and an SCP blocking ml.* and redshift:* goes a long way.

Don’t create too many OUs too early. Start with four or five. You can always add more. I’ve seen organizations with 30+ OUs that nobody understands. Complexity is the enemy of governance.

Don’t forget about account email addresses. Every AWS account needs a unique email. Use plus-addressing: [email protected], [email protected]. Set up a shared mailbox that the team can access. Losing access to an account’s root email is a nightmare.

Do invest in account vending early. The longer you wait, the more snowflake accounts you’ll have. Automate from account number three, not account number thirty.

Where to Start

If you’re sitting on a single account right now, here’s the pragmatic path forward:

  1. Create an Organization from your current account (it becomes the management account).
  2. Enable Control Tower. Let it create the log archive and audit accounts.
  3. Create a new account for your production workload. Migrate prod first — it’s the thing that matters most.
  4. Set up IAM Identity Center. Get your team authenticating through it immediately.
  5. Apply a basic SCP to the production OU: deny region sprawl, protect logging, deny root user actions.
  6. Create a sandbox OU with budget-limited accounts for developers.
  7. Iterate. Move staging next, then dev. Build out your account vending pipeline.

You don’t need to do this all in a week. But you do need to start. Every day you run prod in a shared account is a day you’re one bad script away from the war story I told you about at the top of this article.

Multi-account isn’t about complexity. It’s about boundaries. Good boundaries make systems safer, teams faster, and incidents smaller. I’ve never met anyone who regretted moving to a multi-account strategy. I’ve met plenty who regretted waiting.