AWS Organizations vs Control Tower: Account Governance at Scale

A single AWS account works until it does not. Development and production share the same account — a developer accidentally modifies production infrastructure. Finance cannot see which team is responsible for which costs. A security incident in a development environment has blast radius into production. An audit finds that CloudTrail was disabled in one account for six months.

These are not hypothetical problems. They are the specific failures that motivated the multi-account strategy that AWS now recommends for any organisation beyond the earliest startup stage. AWS Organizations and AWS Control Tower are the two tools AWS provides for managing that multi-account environment. They are not alternatives — Control Tower builds on top of Organizations — but knowing what each one does independently is essential before understanding how they work together.

AWS Organizations: The Foundation

Organizations is a free service that enables management of multiple AWS accounts from a single root. The structure is hierarchical: a root (the management account), Organizational Units (OUs) for grouping accounts, and individual member accounts at the leaves.

AWS Organizations Structure
-----------------------------
Root (Management Account: acme-root)
  |
  +-- OU: Security
  |     +-- Account: security-audit
  |     +-- Account: log-archive
  |
  +-- OU: Workloads
  |     +-- OU: Production
  |     |     +-- Account: prod-ecommerce
  |     |     +-- Account: prod-payments
  |     |
  |     +-- OU: Non-Production
  |           +-- Account: dev-ecommerce
  |           +-- Account: staging-ecommerce
  |
  +-- OU: Shared Services
        +-- Account: shared-networking
        +-- Account: shared-monitoring

The primary governance mechanism is Service Control Policies (SCPs). SCPs are JSON policy documents attached to OUs or accounts that define the maximum permissions available in that scope. SCPs do not grant permissions — IAM policies still do that within accounts — but SCPs constrain what IAM policies can grant.

Example SCP use cases:

• Prevent any account in the production OU from disabling CloudTrail
• Require that all EC2 instances are created in approved regions only
• Block creation of IAM access keys for root users in all accounts
• Prevent deletion of VPC Flow Logs

SCPs are powerful because they cannot be overridden by account administrators, even those with AdministratorAccess. An SCP that denies CloudTrail deletion enforces that policy against every IAM user and role in the account, including the root user.

Organizations also provides consolidated billing: all member accounts’ charges roll up to the management account, enabling volume discounts, reserved instance sharing, and a single invoice.

What Organizations Does Not Do

Organizations provides structure and policy enforcement, but it does not set anything up. When you create a new member account through Organizations, you get a blank account: no CloudTrail, no GuardDuty, no Config, no baseline networking, no budget alerts, no IAM password policy. You can attach SCPs to the account, but the positive security controls (logging, monitoring, alerting) must be configured separately.

For teams managing five accounts, doing this setup manually is manageable. For teams that need to provision twenty accounts per year, manual setup becomes an error-prone, time-consuming process. That is the gap Control Tower fills.

AWS Control Tower: Automated Landing Zone

Control Tower is an orchestration layer on top of Organizations. It automates the setup of a secure, well-architected multi-account environment called a “landing zone.” When you set up Control Tower, it:

1. Creates the management account structure in Organizations
2. Creates required foundational accounts (Log Archive and Audit)
3. Enables CloudTrail, Config, and GuardDuty across all accounts
4. Configures centralised logging to the Log Archive account
5. Applies a baseline set of security controls (guardrails) across the organisation
6. Establishes baseline networking (optional)

The result is that every new account provisioned through Control Tower starts with logging enabled, security monitoring active, and baseline policies enforced — without any manual configuration.

Control Tower Landing Zone Setup
----------------------------------
After Control Tower setup:
  Management Account
  |
  +-- Log Archive Account
  |   - All CloudTrail logs from all accounts centralised here
  |   - S3 with Object Lock (cannot be deleted)
  |   - Only read access for audit
  |
  +-- Audit Account
  |   - AWS Config aggregator (all accounts)
  |   - GuardDuty master
  |   - Security Hub aggregator
  |   - Read-only cross-account access
  |
  +-- Custom OUs (configured by you)
      +-- Production OU (with Control Tower guardrails applied)
      +-- Development OU (with appropriate guardrails)

Guardrails: Control Tower’s Policy Layer

Control Tower uses the term “guardrails” for its policy controls. Guardrails are implemented as SCPs (preventive) or AWS Config rules (detective).

Preventive guardrails (SCPs): Block actions before they happen. “Disallow changes to CloudTrail logging” prevents anyone in the enrolled OU from modifying or disabling CloudTrail. These are enforced and cannot be bypassed by account administrators.

Detective guardrails (Config rules): Detect non-compliant configurations and report them. “Detect whether MFA for the root user is enabled” monitors all enrolled accounts and flags those where root MFA is disabled. Detective guardrails report drift but do not automatically remediate it.

Guardrails are classified by enforcement level:

• Mandatory: Always enforced, cannot be disabled
• Strongly recommended: AWS best practice, enabled by default but can be disabled
• Elective: Optional controls for specific compliance needs

Control Tower ships with 20–30 guardrails enabled by default. Additional guardrails can be enabled from the Control Tower library or created as custom controls using SCP templates or Config rules.

Account Factory: Provisioning New Accounts

Account Factory is Control Tower’s mechanism for creating new AWS accounts. It uses Service Catalog to provide a self-service portal where teams can request new accounts. An approved request triggers automated provisioning: the account is created, added to the appropriate OU, enrolled in Control Tower (inheriting all guardrails), connected to consolidated billing, and configured with baseline logging and monitoring.

Account Factory supports customisation through Account Factory for Terraform (AFT), which allows organisations to extend the baseline provisioning with additional Terraform-based configurations: VPC setup, security tools, SAML federation, cost budgets, or any other IaC-managed configuration.

When to Use Which

Start with Organizations alone when:

• You have 3–5 accounts and are comfortable with manual setup
• You have specific, non-standard account configurations that do not fit Control Tower’s opinionated model
• You need very fine-grained control over SCPs without Control Tower’s guardrail abstraction
• Your organisation already has an established multi-account strategy with custom tooling

Start with Control Tower when:

• You are building a new multi-account environment from scratch
• You want security baselines (CloudTrail, Config, GuardDuty) enabled automatically in every new account
• You need Account Factory for self-service account provisioning at scale
• You want AWS-managed guardrails as a starting point for compliance

Important constraint: If you already have an existing Organizations structure with custom SCPs and account configurations, enrolling it in Control Tower requires careful planning. Control Tower expects to own the root-level structure, and it will modify existing OU configurations during setup. Migrating an existing Organizations deployment into Control Tower is possible but requires a structured process to avoid disrupting existing SCP policies and account configurations.

Most organisations at scale end up with both: Control Tower managing the landing zone and baseline governance, while custom SCPs created directly in Organizations handle organisation-specific policy requirements that Control Tower’s guardrail library does not cover.