|7 min read

AWS Organizations and Multi-Account Strategy

Designing a multi-account AWS architecture for enterprise workloads using Organizations, SCPs, and IAM patterns

cloud

When I started my role as an Enterprise Cloud Architect, one of the first things I learned is that serious AWS usage does not happen in a single account. The moment you have more than a handful of engineers, more than one environment, or any compliance requirements at all, you need multiple AWS accounts. And managing those accounts without a coherent strategy leads to chaos faster than you would believe.

AWS Organizations, which became generally available earlier this year, provides a framework for managing multiple accounts centrally. I have spent the last few months helping design our organization's multi-account architecture, and I want to share the patterns that have worked for us.

Why Multiple Accounts

The single-account approach seems simpler at first. One account, one bill, one set of IAM users. But it creates problems that compound over time:

Blast radius. If a developer accidentally deletes a resource or a deployment goes wrong, the impact is contained to a single account. In a single-account setup, a misconfigured IAM policy or a runaway script can affect production workloads. Separate accounts create natural boundaries.

Security boundaries. AWS accounts are the strongest isolation boundary AWS provides. IAM policies within an account can always be worked around by a sufficiently privileged user. Separate accounts mean that a compromised set of credentials in the development account cannot reach production resources.

Billing clarity. With multiple teams and projects in a single account, attributing costs becomes an exercise in tagging discipline. Separate accounts give you clean cost allocation by default. Each account has its own bill, and consolidated billing through Organizations rolls everything up.

Service limits. AWS imposes service limits per account. Running development and production in the same account means they compete for the same limits. A spike in development activity can eat into production headroom.

The Account Structure

After evaluating several reference architectures and adapting them to our needs, we settled on a structure that looks roughly like this:

Root (Management Account)
├── Security OU
│   ├── Log Archive Account
│   └── Security Tooling Account
├── Infrastructure OU
│   ├── Shared Services Account
│   └── Network Hub Account
├── Workloads OU
│   ├── Development OU
│   │   ├── Team A Dev
│   │   └── Team B Dev
│   ├── Staging OU
│   │   ├── Team A Staging
│   │   └── Team B Staging
│   └── Production OU
│       ├── Team A Prod
│       └── Team B Prod
└── Sandbox OU
    ├── Developer Sandbox 1
    └── Developer Sandbox 2

Each organizational unit (OU) represents a logical grouping with shared governance requirements. The key insight is that the OU hierarchy maps to your governance model, not your org chart. Teams come and go, but the distinction between development and production environments is permanent.

Service Control Policies

Service Control Policies (SCPs) are the most powerful governance tool in AWS Organizations, and also the most dangerous if misused. An SCP is a permission boundary applied at the OU or account level that restricts what actions can be performed, even by the root user of the account.

A few SCPs we implemented:

Deny region restriction. We only operate in us-east-1 and us-west-2. An SCP at the root level denies all actions in other regions, with exceptions for global services like IAM, Route 53, and CloudFront.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/OrganizationAdmin"
        }
      }
    }
  ]
}

Deny leaving the organization. Every member account has an SCP that prevents it from removing itself from the organization.

Restrict root user actions. In member accounts, the root user should almost never be used. An SCP restricts root to only the actions that require it (like changing account-level settings) and denies everything else.

Require encryption. An SCP in the production OU denies any S3 PutObject calls that do not include server-side encryption headers. Similarly, EBS volume creation is denied without encryption enabled.

The critical thing about SCPs is that they are deny-only guardrails. They do not grant permissions; they restrict them. An SCP that denies an action cannot be overridden by any IAM policy within the account. This makes them ideal for enforcing organizational standards that individual teams should not be able to bypass.

IAM Strategy

IAM in a multi-account setup is fundamentally different from IAM in a single account. The key patterns:

Centralized identity. Users authenticate through a central identity provider, either AWS SSO (now available through Organizations) or a federated identity system like SAML with Active Directory. Nobody creates IAM users in individual accounts. This eliminates the problem of orphaned credentials in member accounts.

Cross-account roles. When a user or service in one account needs to access resources in another, they assume a role in the target account. The trust policy on the role specifies which principals in which accounts can assume it. This creates an explicit, auditable access pattern.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/DeploymentPipeline"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "deployment-pipeline-2016"
        }
      }
    }
  ]
}

Permission boundaries. For accounts where teams manage their own IAM roles (like sandbox accounts), permission boundaries set a ceiling on what those self-managed roles can do. A team can create any role they want, but it cannot exceed the permission boundary.

Centralized Logging

Every account sends CloudTrail logs to the Log Archive account. This is non-negotiable. If a security incident occurs, you need a complete, tamper-proof audit trail. The Log Archive account has an S3 bucket with:

  • Object lock enabled (WORM compliance)
  • A bucket policy that allows CloudTrail from all member accounts to write
  • An SCP preventing anyone in the Log Archive account from deleting or modifying the logs
  • A lifecycle policy that transitions logs to Glacier after 90 days

We also centralize VPC Flow Logs and AWS Config snapshots in the same account. The Security Tooling account runs analysis and alerting against these logs, but it only has read access. Nobody can write to the Log Archive except the AWS services themselves.

Lessons Learned

Start with governance, not workloads. The temptation is to spin up accounts and start migrating workloads immediately. Resist it. Get your SCP guardrails, logging, and IAM strategy in place first. Retrofitting governance onto an existing multi-account setup is painful.

Automate account creation. We use CloudFormation StackSets to apply baseline configurations to new accounts automatically. When a new account is created, it gets CloudTrail, AWS Config, default VPC cleanup, and security baselines without any manual steps.

Plan for account sprawl. Accounts are free, which means they proliferate. Establish a naming convention, a tagging strategy, and a process for decommissioning accounts early. We already have more accounts than I expected after just a few months.

SCPs are powerful but blunt. Test SCPs thoroughly in sandbox OUs before applying them broadly. A misconfigured SCP can lock out every user in every account under that OU, including administrators. We learned this the hard way during a testing exercise and now have a strict SCP change management process.

Multi-account architecture is one of those foundational decisions that either enables or constrains everything you build on top of it. Getting it right early is worth the upfront investment. Getting it wrong means years of technical debt and governance headaches.

We are still refining our approach, but the fundamentals are solid. Separate accounts for isolation. SCPs for guardrails. Centralized identity and logging. And a healthy respect for the blast radius of every decision.

Share: