AWS Organizations and Control Tower: Multi-Account Governance in Practice

Most AWS teams start with one account. They create IAM users, attach policies, and eventually have a mess of permissions nobody fully understands. Then they start a second account for production, a third for staging, and suddenly they’re managing credentials in three places with no way to enforce consistent security controls across all of them. AWS Organizations and Control Tower exist to solve this — but they solve different pieces of the problem, and people regularly confuse them.

Short version: Organizations is the foundation. Control Tower is an opinionated setup on top of Organizations that automates landing zone creation, account vending, and guardrail enforcement. You can use Organizations without Control Tower. You cannot use Control Tower without Organizations.

AWS Organizations: The Structural Layer

Organizations lets you group AWS accounts into a hierarchy you control. At the top is the management account (formerly called the master account). Below it are organizational units — OUs — and below those are member accounts or more OUs. The structure is a tree.

The management account has billing authority over all member accounts. Consolidated billing aggregates charges from all accounts into one invoice. Volume discount tiers that apply to your organization-wide spend get calculated against the total — if your EC2 spend across all accounts crosses a pricing tier threshold, every account benefits.

Organizations integrates with about 30 AWS services through delegated administrator accounts. Instead of doing everything from the management account, you designate a member account as the delegated administrator for a specific service — Security Hub, GuardDuty, Config, IAM Access Analyzer. The delegated account can then manage that service organization-wide without having access to everything in the management account. This is important for security: the management account should be locked down to billing and governance only. No workloads should run there.

Service Control Policies (SCPs) are the enforcement mechanism. An SCP attached to an OU restricts what any identity in that OU can do — even the root user. An SCP that denies ec2:CreateVpc in a networking-restricted OU means nobody in any account in that OU can create a VPC, regardless of their IAM permissions. This is how you enforce organization-wide guardrails without relying on developers remembering rules.

SCPs are permissions boundaries on steroids: they don’t grant anything, they only restrict. The maximum permissions an identity can have is the intersection of the SCP, their IAM policies, and any permission boundaries. One common mistake: attaching an SCP to the management account. Management accounts are exempt from SCPs. That SCP does nothing there.

Each OU can have up to 5 SCPs attached. Plan your SCP structure before you run out. A typical hierarchy:

Root
├── SCP: DenyRegionsOutsideApproved
├── Security OU
│   ├── SCP: DenyModifyCloudTrail
│   ├── Log Archive Account
│   └── Audit Account
├── Workloads OU
│   ├── Development OU
│   │   └── Dev Account(s)
│   ├── Staging OU
│   │   └── Staging Account(s)
│   └── Production OU
│       ├── SCP: DenyDeleteProtectedResources
│       └── Production Account(s)
└── Sandbox OU
    └── SCP: DenyProductionServices
    └── Developer Sandbox Accounts

SCPs attached to a parent OU apply to all descendant OUs and accounts. The root SCP is your widest net — use it for non-negotiable organization-wide controls like region restriction. Narrower policies go on specific OUs.

What Control Tower Adds

Control Tower automates the setup that would otherwise take weeks of manual work: creating the management and Security OU accounts, configuring CloudTrail, enabling AWS Config across all accounts, setting up centralized logging in a Log Archive account, deploying an Audit account for security tooling, integrating IAM Identity Center for SSO, and applying a baseline set of guardrails.

It’s opinionated. Control Tower makes choices about account structure, naming, and baseline controls. Those choices follow AWS best practices. If you want a different account structure, different guardrail sets, or different baseline tooling, you’re either customizing Control Tower heavily or building the landing zone yourself with Terraform.

When you set up a Control Tower landing zone, it creates:

• Management account: Billing and governance only. No workloads.
• Log Archive account: Centralized S3 bucket receives CloudTrail logs from all accounts. Read-only for most users, auditors have access.
• Audit account: Security tooling hub. AWS Config aggregator, Security Hub, and GuardDuty run here with organization-wide visibility — both services have delegated admin features that aggregate findings from every member account into this single account for unified triage.
• Security OU: Contains Log Archive and Audit accounts. Locked down with mandatory preventive guardrails.

After the landing zone is set up, you create additional OUs for workloads and provision member accounts through Account Factory.

Guardrails: Preventive, Detective, Proactive

Control Tower enforces governance through guardrails. Three types, three enforcement mechanisms.

Preventive guardrails use SCPs. They block specific API calls before they happen. A preventive guardrail that disallows S3 public access at the organizational level means no one can make an S3 bucket public in any account under that OU. The block happens at the IAM evaluation layer — before the request reaches S3.

Detective guardrails use AWS Config rules. They evaluate existing resources continuously and flag non-compliance. A detective guardrail checking that all EC2 instances have detailed monitoring enabled will report every instance that doesn’t. Detective guardrails don’t stop anything; they surface problems for remediation.

Proactive guardrails use AWS CloudFormation hooks. They intercept CloudFormation deployments and can block stacks that would create non-compliant resources. A proactive guardrail that requires all S3 buckets to have server-side encryption enabled will reject any CloudFormation template that creates an unencrypted bucket, before the deployment runs.

The catch on proactive guardrails: they only work with CloudFormation. Resources created through the console, CLI, Terraform, or CDK bypass them. Detective guardrails still catch those after the fact, but there’s no pre-deployment gate for non-CloudFormation workflows.

Three guidance levels determine which guardrails get applied:

• Mandatory: Enabled by default, cannot be disabled. These are the non-negotiable baseline — things like disabling root access keys, requiring CloudTrail to be enabled, protecting the Log Archive bucket from deletion.
• Strongly recommended: AWS recommends enabling these, but they’re off by default. Review them and enable the ones that apply to your environment.
• Elective: Optional guardrails for specific compliance requirements or organizational preferences.

Don’t manually modify SCPs that Control Tower created. Control Tower tracks its guardrails against the SCP state and will flag drift if you change them outside of Control Tower. The fix for drift is to re-register the OU or reset the landing zone — not something you want to debug at 2 AM.

Account Factory

Account Factory is how you provision new AWS accounts from a template. You define the baseline configuration — default VPC settings, account email pattern, OU placement, pre-approved instance types — and Account Factory applies it to every new account. The provisioning happens through AWS Service Catalog.

# Trigger Account Factory provisioning via CLI (newer approach using Account Factory for Terraform)
aws servicecatalog provision-product \
  --product-name "AWS Control Tower Account Factory" \
  --provisioning-artifact-name "AWS Control Tower Account Factory" \
  --provisioned-product-name "dev-account-team-payments" \
  --provisioning-parameters \
    Key=AccountEmail,[email protected] \
    Key=AccountName,Value=payments-dev \
    Key=ManagedOrganizationalUnit,Value="Development (ou-xxxx-yyyyyyy)" \
    Key=SSOUserEmail,[email protected] \
    Key=SSOUserFirstName,Value=TeamLead \
    Key=SSOUserLastName,Value=Name

The new account gets: baseline IAM Identity Center access, CloudTrail enabled and shipping to the Log Archive account, AWS Config enabled and sending data to the Audit account, and all mandatory guardrails applied from the OU it lands in.

Account Factory for Terraform (AFT) is a newer version that wraps the account creation in a Terraform-based pipeline. If your team is already IaC-first, AFT fits better than clicking through Service Catalog — you commit account definitions to Git and a CodePipeline deploys them.

IAM Identity Center Integration

Control Tower sets up IAM Identity Center as the SSO layer for all accounts. Users authenticate once through the Identity Center portal and see every account they have access to. Permission sets defined in Identity Center become IAM roles in each member account automatically.

This is how it should work: one identity provider, consistent permission sets across accounts, no per-account IAM user management. Without this, teams end up with separate IAM users in each account, different passwords everywhere, and no centralized audit trail.

The management account should only be accessible to a small group with specific Identity Center permission sets. Day-to-day work — deploying applications, managing databases, reviewing logs — happens in member accounts through Identity Center. The management account is for emergency access and billing review, nothing else.

Cost

Control Tower itself has no additional charge. What costs money is what it sets up. Several mandatory services run across every enrolled account:

• AWS Config: Continuously evaluating resources. In a 10-account organization with moderate resource churn, Config rules can cost $50-150/month.
• CloudTrail: $2 per 100,000 management events plus S3 storage. Multi-account trail storage accumulates quickly.
• AWS Config conformance packs: Additional charges per evaluation.

Two specific costs people miss. First, Control Tower creates NAT Gateways in the Security OU accounts by default for outbound connectivity. NAT Gateway pricing ($0.045/hour plus $0.045/GB processed in us-east-1) adds up — roughly $33/month per NAT Gateway just for uptime, before data transfer. If those accounts don’t need internet egress, remove the NAT Gateways after setup.

Second, if you already have CloudTrail trails configured in your accounts and you enroll them in Control Tower, you’ll get duplicate trails logging the same events. AWS charges for both. Either remove your existing trails before enrollment or configure Control Tower to skip creating its own.

Realistic cost for a 10-account organization with light workloads: $60-150/month in underlying service charges. For 50 accounts with active workloads: $500-2000/month, primarily from Config evaluations and CloudTrail volume.

Organizations Alone vs Control Tower

Use Organizations without Control Tower when:

• You need maximum flexibility in account structure and aren’t ready for Control Tower’s opinions
• Your team is Terraform-first and wants to manage everything as code from day one
• You’re enrolling existing accounts with complex configurations Control Tower won’t handle cleanly
• You need a multi-account structure quickly and don’t have time for the landing zone setup process

Use Control Tower when:

• You’re starting fresh and want AWS best practices baked in from the beginning
• You need account vending — frequent provisioning of new accounts with consistent baseline configuration
• Your organization needs documented compliance controls with audit evidence
• You want the pre-built dashboard showing guardrail compliance across all accounts

The IAM roles and policies guide covers how SCPs interact with the standard IAM evaluation model — important context for understanding why SCP-based guardrails are so effective and why they don’t require anything in the member accounts to enforce.

Five Things That Will Catch You

The home region is permanent. When you set up a Control Tower landing zone, you select a home region. The Log Archive and Audit accounts are created in that region. You cannot change the home region after setup without destroying and recreating the entire landing zone. Choose carefully.

Enrolling existing accounts is painful. Control Tower assumes it provisions accounts from scratch. Enrolling an account that’s been running for two years — with its own CloudTrail, Config, networking baseline, and SCPs — requires resolving conflicts between what the account has and what Control Tower wants to configure. Mandatory guardrails that would conflict with existing configurations need to be addressed before enrollment completes.

SCP 5-policy limit bites at scale. Each OU can have at most 5 SCPs. Control Tower uses some of those slots for its mandatory guardrails. If you add custom SCPs for your own requirements, you’ll hit the ceiling faster than expected. Consolidate related restrictions into a single SCP rather than creating one per rule.

Proactive guardrails don’t cover Terraform. Teams that rely on Terraform for infrastructure provisioning get no pre-deployment gate from proactive guardrails — those hooks only fire on CloudFormation. Your detective guardrails will catch violations after deployment, but the resource gets created first. For critical compliance requirements, implement policy checks in your Terraform pipeline separately.

Control Tower doesn’t manage existing non-CT accounts. Accounts created outside of Control Tower (directly in Organizations) exist in the organization but aren’t enrolled in the landing zone. They don’t get Control Tower’s guardrails, Config rules, or centralized logging until you explicitly enroll them. Enrollment is possible but requires the account to meet Control Tower’s prerequisites.

Starting Point

If you have more than three AWS accounts and aren’t using Organizations, start there. Create an organization, move existing accounts in, set up consolidated billing. That alone simplifies billing and lets you attach SCPs for basic cross-account controls.

If you’re starting fresh with a new organization or have the time to plan a proper landing zone, Control Tower is worth the setup investment. The automated account vending alone — consistently provisioned accounts with security baseline applied on creation — eliminates weeks of manual configuration per account. At scale, that’s the difference between governance you can maintain and governance that falls apart when the team grows.

The IAM Identity Center guide covers the SSO layer that Control Tower sets up, including how to configure permission sets for multi-account access.