AWS Organizations and Control Tower: What SEs Need to Explain to Customers

AWS Organizations and Control Tower are not the same thing. They are not interchangeable. They are not competing services. They are two layers of the same governance stack — and the relationship between them is one of the most consistently misunderstood topics in enterprise AWS architecture.

The confusion is understandable. Both are described using the same vocabulary — accounts, policies, guardrails, governance. Both appear in the same conversations about multi-account strategy. Both are referenced in the AWS Well-Architected Framework. The difference is architectural: AWS Organizations is the foundational control plane. AWS Control Tower is an orchestration layer built on top of it.

Getting this relationship wrong at design time produces environments that look governed and aren’t — accounts provisioned without policy inheritance, guardrails that don’t cover the full account estate, SCP logic that conflicts with IAM permissions in ways that are invisible until a compliance audit or a security incident makes them visible.

This post covers how AWS Organizations and Control Tower actually work together, what each layer controls, and the architectural decisions that determine whether a multi-account environment is genuinely governed or just structured.

AWS Organizations: The Control Plane Foundation

AWS Organizations is not an optional governance add-on — it is the foundational layer that AWS Organizations and Control Tower builds on. It is the foundational layer beneath every serious AWS multi-account environment. Without it, accounts are isolated billing and resource containers with no shared policy enforcement, no consolidated visibility, and no mechanism for applying governance at scale.

The Management Account

The Management Account is the root of the AWS Organizations hierarchy. It is the account that creates the organization, owns the consolidated billing, and holds the authority to create, invite, and remove member accounts. It is not a workload account — deploying application infrastructure in the Management Account conflates the governance plane with the data plane and violates the isolation principle that Organizations exists to enforce.

The Management Account should contain: the Organizations configuration, consolidated billing, and the Service Control Policies that apply at the root level. Nothing else.

Organizational Units

Organizational Units (OUs) are the grouping mechanism within Organizations. Accounts placed in an OU inherit the policies assigned to that OU — and to every OU above it in the hierarchy, up to the root. This inheritance model is what makes Organizations a governance control plane rather than just a billing aggregator.

The OU structure is an architectural decision. A flat structure — all accounts under a single OU — applies the same policy set to every account regardless of workload type, compliance requirement, or risk profile. A tiered structure — separate OUs for Platform, Production, Development, Sandbox, and Suspended accounts — allows differentiated policy enforcement that matches the actual risk profile of each workload class.

The CAF reference hierarchy:

Root
├── Security OU (centralized security tooling)
├── Infrastructure OU (shared services — networking, identity)
├── Sandbox OU (individual developer experimentation — lowest policy restriction)
├── Workloads OU
│   ├── Production OU (strictest SCPs, no self-service)
│   └── Non-Production OU (relaxed SCPs, controlled self-service)
└── Suspended OU (decommissioned accounts pending deletion)

The Suspended OU is frequently overlooked. Accounts cannot be deleted immediately — they must be closed and then move through a suspension period. Without a dedicated OU, suspended accounts sit in production OUs and accumulate policy inheritance that is no longer relevant.

Service Control Policies

Service Control Policies are the primary preventative governance mechanism in AWS Organizations Control Tower environments. They define the maximum permissions available to any identity in any account within their scope — guardrails that even account-level administrators cannot override.

The critical distinction: SCPs do not grant permissions. They define permission boundaries. An SCP that allows s3:* does not give any identity S3 access — it means that S3 access is permitted within the boundary, subject to IAM policies. An SCP that denies s3:DeleteBucket blocks that action for every identity in every account beneath the SCP’s attachment point, regardless of what IAM policies say.

Three SCPs every production environment should have at the root or Workloads OU level:

Deny region restriction — prevents resource deployment outside approved regions. For data sovereignty requirements, this is the enforcement mechanism, not a configuration guideline.

json

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    }
  }
}

Deny root account actions — prevents any action performed by the root user in member accounts. Root credentials should never be used for operational tasks.

Deny leaving the organization — prevents member accounts from being removed from the organization without explicit management account authorization. A compromised account that leaves the organization also leaves the governance model.

The Amazon AWS Infrastructure Architecture page covers the IAM and governance layers that SCP policy sits within — including how Organizations integrates with the broader Zero Trust governance model.

AWS Control Tower: The Orchestration Layer

If AWS Organizations is the foundation, AWS Control Tower is the automated build system that constructs a governed environment on top of it. Control Tower does not replace Organizations — it orchestrates it, along with IAM Identity Center, CloudTrail, AWS Config, and several other services, into a coordinated landing zone deployment.

What Control Tower Actually Deploys

When Control Tower is enabled, it creates a baseline environment that includes:

• A Log Archive account — centralized S3 storage for CloudTrail logs and Config snapshots from all member accounts. Isolated from workload accounts so that a compromised workload account cannot tamper with its own audit trail.
• An Audit account — read-only access to security tooling across the organization. Security teams operate from here rather than from individual workload accounts.
• An OU structure — the Security and Sandbox OUs are created automatically. Additional OUs for workload accounts are configured during setup.
• Guardrails — preventative and detective controls applied across the account estate.
• IAM Identity Center — centralized federated access so users authenticate once and receive role-based access to the accounts they’re authorized for.

Guardrails: Preventative vs Detective

Control Tower guardrails are categorized as mandatory, strongly recommended, or elective — and by mechanism: preventative (SCP-based) or detective (Config rule-based).

Preventative guardrails use SCPs to block non-compliant actions before they happen. They are enforced continuously and cannot be bypassed by account-level IAM.

Detective guardrails use AWS Config rules to evaluate resource configurations and flag non-compliance. They do not prevent the non-compliant action — they surface it after the fact. For compliance frameworks that require evidence of continuous monitoring, detective guardrails provide the audit trail.

The mandatory guardrails that Control Tower applies and cannot be disabled include:

• Disallow changes to CloudTrail configuration in enrolled accounts
• Disallow deletion of the Log Archive bucket
• Disallow changes to IAM roles created by Control Tower

These exist to protect the governance infrastructure itself. An environment where an account administrator can disable CloudTrail is an environment where the audit trail can be destroyed. The mandatory guardrails prevent that.

Account Factory

Account Factory is the self-service account provisioning mechanism in Control Tower. Rather than manually creating accounts and configuring them against the organization’s security baseline, Account Factory provisions new accounts from a template that includes:

• Correct OU placement (and therefore correct SCP inheritance)
• Pre-configured network topology (VPC, subnets, route tables) if a network customization is configured
• IAM Identity Center permission sets applied automatically
• CloudTrail and Config enabled by default

The operational value: development teams can request new accounts through a service catalogue interface, receive an account within minutes that already meets the organization’s governance baseline, and never have to interact with the Management Account or the Organizations configuration directly.

The Account Factory for Terraform (AFT) extends this model by replacing the default Account Factory provisioning mechanism with a Terraform-based GitOps pipeline. Account requests become pull requests. Account configuration is code. Changes go through review before deployment. For organizations where infrastructure state management is already Terraform-native, AFT produces accounts that are consistent with the broader IaC model rather than existing as a parallel configuration system.

How Organizations And Control Tower Work Together

The AWS Organizations and Control Tower relationship is layered, not parallel. AWS Organizations exists independently of Control Tower — you can have an Organizations structure without Control Tower. You cannot have Control Tower without Organizations.

Control Tower reads and writes to the Organizations layer. When a new account is provisioned through Account Factory, Control Tower calls Organizations APIs to create the account, places it in the correct OU (triggering SCP inheritance), configures CloudTrail and Config in the new account, and assigns IAM Identity Center permission sets. All of these are Organizations and service-level operations — Control Tower is coordinating them, not replacing them.

The practical implication: organizations that customized their OU structure or SCP logic before enabling Control Tower may encounter conflicts. Control Tower has opinions about the OU structure it expects to manage. Enabling Control Tower on an existing Organizations environment that doesn’t match its expected structure requires a registration process that reconciles existing accounts against the Control Tower baseline.

For environments already running AWS Organizations without Control Tower — a common state in organizations that built their multi-account structure before Control Tower existed — the migration path is to enroll existing accounts into Control Tower management rather than rebuild the Organizations structure from scratch.

What Control Tower Doesn’t Handle

Understanding the boundaries of AWS Organizations Control Tower governance is as important as understanding what it covers.

Network topology — Control Tower configures basic VPC settings through Account Factory network customization, but it does not build the Hub-and-Spoke or Transit Gateway topology that connects accounts to each other and to on-premises. Network architecture is a separate design decision.

Application-level compliance — Control Tower guardrails enforce infrastructure configuration standards. They do not enforce application security requirements, data classification policies, or workload-specific compliance controls. Those require additional Config rules, Security Hub standards, and application-layer controls.

Drift in enrolled accounts — Control Tower detects drift through detective guardrails. It does not automatically remediate it. An account that has drifted from the governance baseline surfaces a finding in the Control Tower dashboard — resolution requires manual remediation or custom automation.

Cost governance — Organizations provides consolidated billing and the mechanism for tag enforcement policies. It does not provide cost anomaly detection, budget alerting, or FinOps analysis. Those require AWS Cost Explorer, AWS Budgets, and Cost Anomaly Detection configured separately. The FinOps Architecture post covers the cost governance layer that sits above the Organizations billing consolidation.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →