AWS Multi-Account Governance - Organizational Control with Organizations, Control Tower, and SCPs
This article examines the multi-account governance mechanisms centered on AWS Organizations, Control Tower, and SCPs (Service Control Policies), comparing them with Azure Management Groups to explain the differences in enterprise governance design capabilities.
Multi-Account Strategy Is the Foundation of Enterprise Cloud
At enterprise scale, running everything in a single cloud account is simply not practical. Separating development from production environments, managing costs by department, establishing security boundaries, and meeting compliance requirements all demand a multi-account strategy with systematic management of multiple accounts. AWS provides a multi-layered governance framework built on Organizations as the foundation, with Control Tower for automated landing zone construction, SCPs for preventive guardrails, and AWS Config for detective guardrails. The maturity of this framework is one of the key reasons enterprise customers choose AWS.
Hierarchical Control with AWS Organizations and SCPs
AWS Organizations manages multiple AWS accounts in a hierarchical structure of Organizational Units (OUs). OUs can be arranged in a tree structure, allowing flexible hierarchy design that mirrors your corporate structure or workload classification. SCPs (Service Control Policies) are preventive guardrails applied to OUs or accounts. Unlike IAM policies, SCPs define the maximum allowed API actions for all principals within an account, including the root user. For example, you can block resource creation outside specific regions, restrict certain instance types, or prevent CloudTrail from being disabled, all applied in bulk at the OU level. SCPs support both deny-list and allow-list approaches, enabling flexible control aligned with your organization's security policies. SCPs are inherited along the OU hierarchy, so policies defined at a parent OU automatically apply to all child OUs and accounts.
Automated Landing Zone Construction with Control Tower
AWS Control Tower automatically builds a landing zone based on multi-account environment best practices. A landing zone is the starting point for a multi-account environment with security, log aggregation, and account management foundations already in place. Control Tower automatically configures Organizations, IAM Identity Center (formerly SSO), CloudTrail, AWS Config, and S3, building a baseline that includes a log archive account and an audit account. Guardrails come in two types - preventive (SCP-based) and detective (AWS Config Rules-based) - and can be applied at three levels: mandatory, strongly recommended, and elective. Account Factory standardizes new account creation, enabling self-service provisioning of accounts with pre-defined network settings, IAM configurations, and guardrails automatically applied. Account Factory for Terraform (AFT) extends this automation to Terraform users.
Comparison with Azure Management Groups
Azure uses Management Groups to hierarchically manage subscriptions (equivalent to AWS accounts). Management Groups support a tree structure up to 6 levels deep, with Azure Policy applied at the group level. Azure Policy combines functionality similar to both AWS SCPs and AWS Config Rules, capable of enforcing compliance at resource creation time (deny effect) and auditing existing resource compliance (audit effect). Azure Policy's strength is managing deny and audit within a single policy framework. In AWS, preventive controls (SCPs) and detective controls (AWS Config Rules) are provided as separate services, giving Azure an advantage in management unification. On the other hand, Azure lacks a managed service equivalent to Control Tower for automated landing zone construction. Azure Landing Zone is provided as a reference architecture, but you need to deploy Bicep or Terraform templates yourself, falling short of Control Tower's level of managed automation. Additionally, Azure Management Groups have a maximum of 6 hierarchy levels, which can constrain hierarchy design for large organizations.
Comparison with GCP's Resource Hierarchy
GCP manages resources through a three-tier structure of Organization, Folder, and Project. The Organization is tied to a Google Workspace or Cloud Identity domain, and Folders can be nested up to 10 levels deep. Organization Policy Service can apply SCP-equivalent constraints at the Folder or Project level. GCP's resource hierarchy is simple and easy to understand, but it lacks the depth of governance features compared to AWS Organizations and Azure Management Groups. GCP has no managed landing zone construction service equivalent to Control Tower, requiring manual setup using Terraform Foundation Toolkit or Cloud Foundation Toolkit. Organization Policy constraint types are also less flexible than AWS SCPs, with limitations in conditional policy expressiveness. GCP's strength lies in its simple and intuitive IAM inheritance model, where IAM roles granted at a parent Folder automatically propagate to child Projects without explicit boundary settings like SCPs. However, this inheritance model can create risks of excessive permission propagation in large organizations, making SCP-based explicit restrictions safer from a governance perspective.
Multi-Account Design Best Practices
AWS multi-account design structures OUs to achieve workload isolation, environment separation, and security boundary establishment. A common pattern recommends a Security OU (log archive, audit), Infrastructure OU (shared networking, DNS), Sandbox OU (developer experimentation), and Workloads OU (production, staging, development). AWS Config's aggregation feature enables centralized monitoring of compliance status across all accounts from the management account. Security Hub aggregates security findings from multiple accounts and provides automated assessments based on CIS Benchmarks and AWS Foundational Security Best Practices. To systematically learn multi-account governance design patterns, related books on Amazon can also be helpful.
Summary
AWS multi-account governance is built on a three-layer structure: hierarchical management with Organizations, preventive guardrails with SCPs, and automated landing zone construction with Control Tower. Azure has strengths in unified policy management through Management Groups and Azure Policy, but lacks a managed landing zone construction service equivalent to Control Tower. GCP features a simple resource hierarchy and intuitive IAM inheritance model, but trails AWS in governance feature depth. At enterprise scale, the maturity of multi-account governance directly impacts security and compliance quality. The combination of Control Tower's automated landing zone construction and SCPs' powerful preventive controls represents AWS's most differentiated governance capability.