Mastering Multi-Account Management: AWS Organizations & Control Tower

This study guide covers the architectural and administrative strategies for managing large-scale AWS environments, focusing on the centralized control, governance, and billing features provided by AWS Organizations and AWS Control Tower.

Learning Objectives

By the end of this study guide, you should be able to:

• Define the components of AWS Organizations including Roots, OUs, and Accounts.
• Explain the difference between Consolidated Billing and All Features mode.
• Implement Service Control Policies (SCPs) to establish security guardrails.
• Differentiate between the roles of the Management Account and Member Accounts.
• Describe how AWS Control Tower automates the creation of a governed multi-account environment.

Key Terms & Glossary

• Management Account: The central account used to create the organization, manage invitations, and handle consolidated billing. It cannot be changed once established.
• Member Account: Any AWS account within an organization that is not the management account.
• Organizational Unit (OU): A container for accounts within a root. An OU can also contain other OUs, creating a hierarchy.
• Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization. It acts as a filter rather than a grant of permission.
• Landing Zone: A well-architected, multi-account AWS environment that is a starting point from which you can deploy workloads and applications.

The "Big Idea"

As organizations grow, managing everything within a single AWS account becomes a security and operational nightmare. The "Big Idea" here is Governance at Scale. By moving to a multi-account strategy, you isolate workloads (blast radius reduction), simplify billing, and use AWS Organizations to apply top-down "guardrails" (SCPs) that ensure even account administrators cannot bypass corporate security mandates.

Formula / Concept Box

[!IMPORTANT] When "All Features" is enabled, you can centrally manage permissions via SCPs across all accounts in the hierarchy.

Hierarchical Outline

• AWS Organizations Structure
  • Administrative Root: Topmost container in the hierarchy.
  • Organizational Units (OUs): Logical groupings (e.g., "Dev", "Prod", "Security").
  • Accounts: Individual AWS accounts; can only belong to one OU at a time.
• Policy Management
  • Inheritance: Policies attached to the Root apply to all OUs/Accounts; policies on OUs apply to child OUs/Accounts.
  • Maximum Depth: The hierarchy can be up to five levels deep.
• AWS Control Tower
  • Account Factory: Automates standardized account provisioning.
  • Guardrails: Pre-packaged SCPs and AWS Config rules for governance.

Visual Anchors

Organization Hierarchy Flow

Permission Evaluation Logic (SCP vs. IAM)

Definition-Example Pairs

• Consolidated Billing: A feature of AWS Organizations that aggregates all usage across member accounts into a single bill.
  • Example: A company with 10 accounts reaches the 100TB S3 storage tier faster by combining all account data, resulting in a lower per-GB price for everyone.
• Guardrails: High-level rules that provide ongoing governance for your overall AWS environment.
  • Example: Using a Control Tower guardrail to "Disallow changes to log archive buckets" to ensure compliance logs are never deleted.
• Member Account Invitation: The process of bringing an existing standalone account into an Organization.
  • Example: A startup is acquired; the parent company sends an invitation to the startup's AWS account ID to merge it into the corporate OU structure.

Worked Examples

Example 1: Restricted Region SCP

Scenario: A company operates strictly in the EU. They want to ensure no developer can spin up resources in US regions to avoid GDPR compliance issues.

Step-by-Step:

1. Identify the Target: The "Development" OU.
2. Draft the SCP:
   jsonCopy

   { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllOutsideEU", "Effect": "Deny", "NotAction": "iam:*", "Resource": "*", "Condition": { "StringNotEquals": {"aws:RequestedRegion": ["eu-central-1", "eu-west-1"]} } } ] }
3. Attach Policy: In the Management Account, navigate to AWS Organizations -> Policies -> SCPs. Create the policy and attach it to the Development OU.
4. Result: Even if a user has AdministratorAccess in a member account, they will receive an "Access Denied" error when trying to launch an EC2 instance in us-east-1.

Checkpoint Questions

1. What is the maximum depth of an Organizational Unit hierarchy including the root and account?
2. True or False: If an SCP denies an action, but an IAM policy allows it, the user can still perform the action.
3. Which account in an organization is responsible for paying all charges incurred by member accounts?
4. What happens to an account's data and resources when it is removed from an organization to become a standalone account?

▶Click to reveal answers

1. Five levels deep.
2. False (A Deny in an SCP overrides any Allow in an IAM policy).
3. The Management Account (Payer Account).
4. The data and resources remain intact, but the account becomes responsible for its own billing and loses the governance of the organization's SCPs.

Muddy Points & Cross-Refs

• SCPs do NOT grant permissions: This is the #1 exam trap. If an SCP allows s3:* but the user has no IAM policy, they still have zero access. Think of SCPs as the "Max Possible Permissions" filter.
• Management Account Limitations: You cannot apply an SCP to the Management Account itself. This is why it is best practice to keep the Management Account empty of actual workloads.
• Service-Linked Roles: Some AWS services use these to work across accounts; SCPs generally do not interfere with these internal AWS service-to-service permissions.

Comparison Tables