AWS Organizations and Control Tower: Multi-Account Governance – SAP-C02 Study Guide

Purpose of This Lesson

AWS Organizations and AWS Control Tower provide the foundation for governing multiple AWS accounts. They help centralize billing, organize accounts, control available API actions, standardize account provisioning, and implement security and compliance guardrails.

For SAP-C02 scenarios, distinguish between the capabilities provided directly by AWS Organizations and the opinionated, automated governance framework added by AWS Control Tower.

Key Concepts

AWS Organizations structure

An organization contains:

• A management account, formerly called the master account, that creates and administers the organization.
• Member accounts, which remain separate AWS accounts with their own resources and IAM configuration.
• Organizational units (OUs), which group accounts according to business, environment, workload, or compliance requirements.
• Policies attached to the organization root, OUs, or individual accounts.

A common hierarchy might look like this:

Organization root
├── Security OU
│   ├── Audit account
│   └── Log archive account
├── Production OU
│   └── Production accounts
└── Development OU
    └── Development and test accounts

The management account should be used primarily for organization-level administration. It should not normally host application workloads.

Consolidated billing

AWS Organizations provides consolidated billing through a designated management or paying account. The bill can be viewed centrally while costs remain itemized by member account, making it possible to allocate spending to teams, environments, or business units.

Consolidated billing does not merge account permissions or resources. Member accounts remain independent security and operational boundaries.

Organizations supports two feature modes:

• Consolidated billing only: Provides centralized billing with limited organization functionality.
• All features: Enables capabilities such as service control policies, policy inheritance, and broader centralized governance. This is the normal choice when implementing multi-account controls.

Service control policies

A service control policy (SCP) defines the maximum permissions available to IAM principals in member accounts. SCPs do not grant permissions. An action must be allowed by both:

1. An applicable SCP hierarchy, and
2. An identity-based or resource-based permission policy, where applicable.

An explicit deny in an SCP overrides an allow elsewhere in the account.

SCPs can be attached to:

• The organization root
• An OU
• An individual member account

Permissions flow down the hierarchy. A restriction applied to a parent OU affects accounts and child OUs beneath it.

#### Example: restricting EC2 instance types

An SCP could deny ec2:RunInstances when the requested instance type is not t2.micro. This prevents users in the affected OU from launching other instance types, even if their IAM policies allow ec2:RunInstances.

The policy still does not grant permission to launch t2.micro; an IAM policy must provide that permission separately.

SCP strategy: deny list versus allow list

#### Deny-list strategy

The default FullAWSAccess SCP remains attached throughout the hierarchy. Additional SCPs explicitly deny risky services, actions, Regions, or resource configurations.

Advantages:

• Easier to deploy incrementally
• New AWS services are not automatically blocked by omission
• Appropriate when accounts require broad service access with selected restrictions

Risks:

• A missed deny can leave an action available
• Requires careful testing of explicit-deny conditions

#### Allow-list strategy

The broad allow policy is removed, and SCPs explicitly allow only approved API actions. An action must be allowed at every level between the organization root and the target account.

Advantages:

• Stronger preventive control
• Useful for highly restricted environments

Risks:

• More difficult to administer
• New services and dependent API actions must be deliberately added
• A missing allow at any hierarchy level prevents the action

Other Organizations capabilities

AWS Organizations can also support:

• Tag policies for standardized tagging practices
• Backup policies for centrally defined backup configurations
• AWS CloudTrail organization trails for centralized auditing across member accounts
• AWS IAM Identity Center for federated workforce access and centralized permission-set management
• Programmatic account creation and organization administration through the Organizations API

A CloudTrail organization trail can be configured so member accounts cannot disable the intended centralized auditing configuration.

Organizations API actions

Important API operations include:

• CreateOrganization: Creates an organization
• CreateAccount: Creates a new member account
• CreatePolicy: Creates an organization policy
• AttachPolicy: Attaches a policy to the root, OU, or account
• InviteAccountToOrganization: Invites an existing AWS account to join

Automated account provisioning is useful when organizations need repeatable account baselines, standard tags, security controls, and networking configuration.

AWS Control Tower

AWS Control Tower builds on AWS Organizations. It creates and governs a multi-account landing zone, which is a standardized baseline for account structure, identity, logging, security, and governance.

Control Tower commonly establishes:

• A management account
• A Security OU containing accounts such as an audit account and a log archive account
• A sandbox or development OU
• A production OU
• Centralized logging and governance controls
• Federated access through IAM Identity Center or an external identity provider

Control Tower supports identity sources including:

• IAM Identity Center’s built-in directory
• A SAML 2.0 identity provider
• Microsoft Active Directory integrations

Account Factory

Account Factory automates the creation and enrollment of accounts using approved templates and organizational standards. This helps ensure that new accounts receive consistent governance rather than being created manually with varying configurations.

Control Tower guardrails

Control Tower provides governance controls commonly referred to as guardrails:

• Preventive guardrails: Prevent actions from occurring. These are implemented primarily with SCPs.
• Detective guardrails: Detect noncompliant configurations. These use services such as AWS Config rules and AWS Lambda-based remediation or evaluation logic.

Preventive controls block an operation before it happens. Detective controls identify a violation after configuration or deployment and can support notification, reporting, or remediation.

Exam-Relevant Takeaways

• AWS Organizations provides multi-account management, OUs, consolidated billing, SCPs, tag policies, backup policies, and organization-level governance features.
• AWS Control Tower uses Organizations and adds a prescriptive landing zone, Account Factory, centralized identity and logging patterns, and managed guardrails.
• An SCP is a permissions boundary for an account hierarchy; it is not an IAM permission grant.
• An explicit deny in an SCP overrides an allow in an IAM policy.
• An SCP attached to a parent OU affects accounts and child OUs beneath that OU.
• In a deny-list design, FullAWSAccess remains in place and additional SCPs deny selected actions.
• In an allow-list design, every required action must be allowed at every level from the root to the target account.
• The management account is not restricted by SCPs in the same way as member accounts. Do not treat SCPs as a complete control over management-account principals.
• Consolidated billing centralizes payment and reporting but does not combine account resources or IAM permissions.
• Use an organization trail when centralized CloudTrail coverage across member accounts is required.
• Control Tower preventive guardrails are primarily preventive SCP controls; detective guardrails commonly rely on AWS Config and related automation.

Architecture Decision Guide

Requirement	Recommended capability	Important consideration
Centralize payment for several AWS accounts	AWS Organizations consolidated billing	Accounts and permissions remain separate
Group accounts by environment or business unit	Organizational units	Policies attached to a parent OU inherit downward
Prevent member accounts from using selected APIs	SCPs	SCPs restrict maximum permissions; they do not grant access
Standardize account tags	Organizations tag policies	Combine with IAM and governance processes for enforcement
Centralize audit logs across accounts	Organization CloudTrail trail and log archive design	Protect the trail and destination from member-account changes
Provision accounts consistently	Organizations API or Control Tower Account Factory	Automate baselines, identity, logging, and security controls
Create an AWS multi-account baseline	Control Tower landing zone	Control Tower is more prescriptive than Organizations alone
Block known risky actions	Preventive guardrails or SCPs	Test dependencies and exceptions before deployment
Detect configuration drift or violations	Detective guardrails using AWS Config and automation	Detection does not necessarily prevent the initial change
Restrict a highly regulated account to approved APIs	SCP allow-list strategy	Operationally complex; maintain all required service dependencies

Common Exam Traps

• Assuming SCPs grant permissions: An SCP cannot make an action usable by itself. IAM permissions are still required.
• Ignoring the hierarchy: An allow at a child OU does not overcome a deny at a parent OU.
• Confusing consolidated billing with shared resources: Billing is centralized, but member accounts remain separate.
• Treating Control Tower as a replacement for Organizations: Control Tower relies on Organizations and extends it with landing-zone automation and guardrails.
• Assuming detective guardrails prevent changes: Detective controls identify noncompliance; preventive controls block API actions.
• Applying SCP expectations to the management account: SCP-based restrictions are designed primarily to govern member accounts. The management account requires additional security controls.
• Forgetting allow-list inheritance: With an allow-list model, the required action must be allowed at every level in the path to the account.
• Assuming an invited account is newly created: InviteAccountToOrganization adds an existing account; CreateAccount provisions a new member account.
• Using only IAM policies for organization-wide restrictions: IAM policies in each account are difficult to centralize. SCPs provide an organization-level maximum-permission boundary.

Real-World Engineer Notes

• Keep the management account tightly controlled, protected with strong MFA, and reserved for organization administration.
• Use separate accounts for security, logging, production, development, and experimentation. This reduces blast radius and simplifies billing and access boundaries.
• Prefer organizational structures that reflect governance requirements rather than only the company’s reporting hierarchy. Accounts should be placed where the same controls and policies apply.
• Start with a deny-list SCP model unless the environment has a strong requirement for strict allow-listing and the team can maintain the dependency graph.
• Test SCPs in a nonproduction OU. A broad deny can affect deployment pipelines, service-linked roles, control-plane automation, and managed services.
• Centralize CloudTrail and protect the log destination with restrictive resource policies, encryption, and limited write/read access.
• Use IAM Identity Center permission sets for workforce access instead of creating long-lived IAM users in every member account.
• Treat Control Tower controls as a baseline, not a complete security program. Add workload-specific controls, data protection, incident response, and continuous monitoring.
• Account Factory is most valuable when integrated with infrastructure automation, network baselines, tagging, cost allocation, and security account enrollment.

Quick Reference Summary

• Organizations: Centralized management of multiple AWS accounts.
• Management account: Creates and administers the organization; protect it carefully.
• Member account: Separate AWS account with independent resources and IAM configuration.
• OU: Hierarchical grouping for accounts and policy inheritance.
• SCP: Limits maximum available permissions; does not grant permissions.
• Deny-list: Allow broadly, then explicitly deny selected actions.
• Allow-list: Explicitly allow every required action at every hierarchy level.
• Consolidated billing: One payment view with account-level cost attribution.
• Control Tower: Organizations plus a governed landing zone, Account Factory, identity integration, logging patterns, and guardrails.
• Preventive guardrail: Blocks an operation, generally through SCPs.
• Detective guardrail: Detects noncompliance, commonly through AWS Config and automation.

Flashcards

1. Q: What is the primary purpose of AWS Organizations?

A: To centrally manage multiple AWS accounts, including their hierarchy, billing, and organization-level policies.

1. Q: What is the difference between the management account and a member account?

A: The management account administers the organization, while member accounts remain separate accounts for workloads and delegated administration.

1. Q: Do SCPs grant permissions?

A: No. They define the maximum permissions available. IAM or resource policies must still grant the required access.

1. Q: What happens when an SCP explicitly denies an action that an IAM policy allows?

A: The action is denied.

1. Q: How does an SCP on a parent OU affect child accounts?

A: Its restrictions flow down to child OUs and accounts.

1. Q: What is the default SCP strategy in many Organizations deployments?

A: A deny-list strategy using broad access plus explicit denies for prohibited actions.

1. Q: What is the main operational challenge of an SCP allow-list strategy?

A: Every required action must be allowed at every hierarchy level, and new service dependencies must be maintained.

1. Q: What does consolidated billing provide?

A: Centralized payment and a consolidated bill with costs itemized by account.

1. Q: What does InviteAccountToOrganization do?

A: It invites an existing AWS account to become a member of the organization.

1. Q: What does Control Tower add to AWS Organizations?

A: A prescriptive landing zone, Account Factory, centralized governance patterns, and preventive and detective guardrails.

1. Q: What is a preventive guardrail?

A: A control that blocks a prohibited operation before it occurs, commonly using an SCP.

1. Q: What is a detective guardrail?

A: A control that detects noncompliant resources or configurations, commonly using AWS Config and automation.

1. Q: Which service is commonly used for centralized workforce sign-in across accounts?

A: AWS IAM Identity Center.

1. Q: Why use a CloudTrail organization trail?

A: To centrally capture API activity across member accounts and support auditing and governance.

Practice Questions

Question 1

A company has an IAM policy allowing developers to launch any EC2 instance type. The security team attaches an SCP to the Development OU that denies ec2:RunInstances unless the instance type is t2.micro. What is the result?

Correct answer: Developers can launch only t2.micro instances, assuming their IAM policies otherwise allow the launch.

Explanation: The SCP limits the maximum permissions available in accounts below the OU. The explicit deny overrides the broad IAM allow for all other instance types. The SCP does not itself grant permission to launch t2.micro.

Question 2

An enterprise wants to ensure that every newly created AWS account receives centralized logging, standard organizational placement, and approved baseline controls. Which solution best meets this requirement?

A. Create accounts manually and attach IAM policies after creation
B. Use AWS Control Tower Account Factory
C. Use consolidated billing only
D. Attach an SCP to the organization root

Correct answer: B. Use AWS Control Tower Account Factory.

Explanation: Account Factory automates account provisioning within a Control Tower landing zone and applies approved governance patterns. Billing and SCPs alone do not create a complete account baseline.

Question 3

A security architect removes the broad access SCP from an OU and attaches an SCP allowing Amazon EC2 actions. A member account under that OU still cannot use Amazon DynamoDB, even though an allow for DynamoDB was attached directly to the account. Why?

Correct answer: DynamoDB must be allowed at every level in the hierarchy under the allow-list strategy.

Explanation: In an SCP allow-list design, the action must be allowed by the root, each parent OU, and the target account. An account-level allow cannot compensate for the missing allow at a higher level.

Question 4

A company wants to identify resources that violate encryption requirements but does not necessarily need to block their creation immediately. Which Control Tower control type is most appropriate?

A. Preventive guardrail
B. Detective guardrail
C. Consolidated billing
D. Account invitation

Correct answer: B. Detective guardrail.

Explanation: Detective guardrails use mechanisms such as AWS Config rules to identify noncompliant resources. Preventive guardrails are intended to block prohibited actions before they occur.

Question 5

A company wants one account to pay the AWS bill for all accounts while preserving separate IAM permissions and resource ownership for each business unit. Which capability should it use?

A. AWS Control Tower only
B. AWS Organizations consolidated billing
C. An IAM role shared by all accounts
D. A single VPC shared by all accounts

Correct answer: B. AWS Organizations consolidated billing.

Explanation: Consolidated billing centralizes payment and provides account-level cost visibility without merging the accounts’ resources or permissions.