Mastering AWS Multi-Account Structures and Governance
AWS account structures, best practices, and related AWS services
Mastering AWS Multi-Account Structures and Governance
[!NOTE] This study guide focuses on the DevOps Engineer Professional (DOP-C02) domain concerning the automation, onboarding, and securing of multi-account environments using AWS Organizations and AWS Control Tower.
Learning Objectives
After studying this guide, you should be able to:
- Design a scalable AWS account hierarchy using Organizational Units (OUs).
- Implement Service Control Policies (SCPs) to enforce top-down security constraints.
- Differentiate between AWS Organizations and AWS Control Tower features.
- Automate account provisioning using Landing Zones and CloudFormation StackSets.
- Apply best practices for consolidated billing and cross-account security auditing.
Key Terms & Glossary
- Management Account: The master account used to create the organization. It handles consolidated billing and cannot be changed once established.
- Member Account: Any account within an organization that is not the management account. An account can belong to only one organization at a time.
- Organizational Unit (OU): A container for accounts within a root. OUs can contain other OUs, creating a hierarchy.
- Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization, offering central control over the maximum available permissions for all accounts.
- Landing Zone: A well-architected, multi-account AWS environment that is a starting point from which you can deploy workloads and applications.
- Guardrail: High-level rules in AWS Control Tower that provide ongoing governance (either mandatory or detective).
The "Big Idea"
The transition from a single-account to a multi-account strategy is driven by the need for isolation. By separating workloads into different accounts (e.g., Prod, Dev, Security, Shared Services), organizations limit the "blast radius" of security incidents or accidental configuration errors. AWS Organizations and Control Tower provide the "connective tissue" to manage these isolated units as a single, governed entity.
Formula / Concept Box
| Concept | Application Rule |
|---|---|
| SCP Inheritance | Policies applied at the Root or OU level are inherited by all child entities. |
| Permission Filter | (The intersection of what is allowed by both). |
| Max OU Depth | AWS Organizations supports a nesting depth of up to 5 levels of OUs. |
| Billing |
Hierarchical Outline
- AWS Organizations Structure
- The Root: The parent container for all OUs and accounts.
- Organizational Units (OUs): Logical groupings (e.g., by Business Unit or Environment).
- Management Account: Payer account, policy administrator.
- Governance and Security
- Service Control Policies (SCPs): Centrally control API access (e.g., prevent disabling CloudTrail).
- Consolidated Billing: Aggregates usage for volume discounts (S3, EC2).
- Eventual Consistency: Note that changes to the organization structure replicate across global endpoints over time.
- AWS Control Tower & Landing Zones
- Automation: Automates the creation of a "Landing Zone" with best practices.
- Account Factory: Standardizes the provisioning of new accounts via Service Catalog.
- Guardrails: Mandatory (SCPs) and Detective (AWS Config rules).
- Related Development Services
- Amazon CodeGuru: Intelligent code reviews and performance profiling.
- AWS FIS (Fault Injection Simulator): Chaos engineering to test resiliency in multi-account environments.
Visual Anchors
AWS Organization Hierarchy
SCP Permission Intersection
Definition-Example Pairs
-
Term: Service Control Policy (SCP)
-
Definition: A policy that sets the boundary for IAM permissions but does not grant permissions itself.
-
Example: An SCP that denies the
s3:DeleteBucketaction globally ensures that no user, not even an Administrator in a member account, can delete an S3 bucket. -
Term: Account Factory
-
Definition: A configurable template within Control Tower that automates the provisioning of new accounts.
-
Example: A developer requests a new sandbox account; the Account Factory automatically applies the networking VPC, IAM roles, and logging configurations without manual intervention.
Worked Examples
Example 1: Enforcing a Region Restriction
Goal: Prevent developers from launching resources in any region except us-east-1 and eu-west-1 to maintain compliance.
Step-by-Step:
- Identify the Policy Type: This requires an SCP applied at the OU level.
- JSON Construction: Use a "Deny" statement with a condition string
StringNotEqualsforaws:RequestedRegion. - Application: Navigate to AWS Organizations > Policies > SCPs. Create the policy and attach it to the
DevelopmentOU. - Verification: Log into a member account and attempt to launch an EC2 instance in
ap-southeast-1. The action should fail with an "Implicit Deny."
Example 2: Resolving a "Muddy" Permission Issue
Scenario: A user has the AdministratorAccess managed policy in a member account but cannot access Amazon S3.
Diagnosis:
- Check the local IAM user/role (It has
AdministratorAccess). - Check Permission Boundaries (None found).
- Check AWS Organizations SCPs. Discovery: An SCP exists at the Root level that says
Deny s3:*for all accounts to prevent data exfiltration during an audit. - Solution: The SCP acts as a filter. Since the SCP denies S3, the user's Administrator permissions are overridden.
Checkpoint Questions
- What is the only account in an AWS Organization capable of performing consolidated billing?
- True or False: An SCP can be used to grant
AdministratorAccessto a new IAM user. - Which service provides "Guardrails" to detect policy violations via AWS Config?
- Can a member account belong to two different Organizations for redundancy?
- What is the primary difference between a Mandatory Guardrail and a Detective Guardrail in Control Tower?
Muddy Points & Cross-Refs
- SCP vs. IAM: Remember that SCPs never grant access. They only define the maximum possible permissions. You still need an IAM policy to grant the specific action.
- Management Account Limitations: You cannot apply SCPs to the Management Account itself. This is a common exam trick—the Management Account always has full power to ensure you don't lock yourself out of the organization.
- Control Tower vs. Organizations: Think of Control Tower as the orchestrator that uses Organizations (for hierarchy) and AWS Config (for rules) under the hood.
Comparison Tables
| Feature | AWS Organizations | AWS Control Tower |
|---|---|---|
| Primary Goal | Centralized management & billing | Automated landing zone setup |
| Policy Type | SCPs, Tag Policies | Guardrails (Mandatory/Detective) |
| Ease of Use | Manual structure creation | Click-through blueprint setup |
| Account Provisioning | Manual or API-based | Automated via "Account Factory" |
| Compliance | User-defined rules | Best-practice blueprints built-in |
| Guardrail Type | Enforcement Mechanism | Purpose |
|---|---|---|
| Mandatory | SCPs (Service Control Policies) | Prevent actions before they happen (Hard Stop). |
| Detective | AWS Config Rules | Identify and alert on non-compliant resources after deployment. |