Mastering Multi-Account Governance on AWS

This study guide covers the architectural and administrative strategies required to manage complex organizational structures in AWS using multiple accounts. It focuses on governance, security isolation, and centralized billing.

Learning Objectives

After studying this material, you should be able to:

• Evaluate the most appropriate account structure (BU-style vs. Environment-style) for organizational requirements.
• Implement centralized billing and cost-allocation tagging strategies.
• Design a governance model using AWS Organizations and Organizational Units (OUs).
• Configure Service Control Policies (SCPs) to enforce security boundaries.
• Leverage AWS Control Tower for automated landing zone deployment.

Key Terms & Glossary

• Management Account: The central account in an organization that handles billing and administrative tasks for the entire entity.
• Member Account: An individual AWS account that belongs to an organization but is managed by the management account.
• Organizational Unit (OU): A logical container for accounts within an organization, allowing for hierarchical management.
• Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization, acting as a filter for what actions can be performed.
• Consolidated Billing: A feature that combines the costs of all accounts in an organization into a single bill, allowing for volume discounts and simplified payment.

The "Big Idea"

As organizations grow, a single AWS account becomes a bottleneck for security, billing, and resource management. The Multi-Account Governance Model shifts the paradigm from managing individual resources to managing "containers" of resources (accounts). By using AWS Organizations, enterprises can enforce global guardrails, automate account creation, and gain total cost visibility, ensuring that the cloud environment scales safely alongside the business.

Formula / Concept Box

Hierarchical Outline

• I. Multi-Account Strategy Basics
  • Resource Isolation: Limits the "blast radius" of security incidents or service failures.
  • Billing Isolation: Simplifies chargebacks to specific departments.
• II. AWS Organizations Structure
  • The Root: Top-level container.
  • Organizational Units (OUs): Hierarchical grouping (e.g., Prod, Dev, HR).
  • Member Accounts: The actual resource containers.
• III. Security & Governance
  • Service Control Policies (SCPs): JSON policies that specify the maximum available permissions.
  • Guardrails: Automated security checks provided by AWS Control Tower.
• IV. Financial Governance
  • Consolidated Billing: One bill for all accounts.
  • Tagging Strategy: Use CostCenter, Project, and Environment tags for reporting.

Visual Anchors

Multi-Account Organizational Hierarchy

SCP Permission Filtering Logic

\begin{tikzpicture}[scale=0.8] \draw[thick, fill=blue!10] (0,0) circle (3cm); \node at (0,2.2) {IAM Permissions (User/Role)}; \draw[thick, fill=red!20, opacity=0.7] (0,-1) circle (2.5cm); \node at (0,-2.8) {Service Control Policy (Boundary)}; \begin{scope} \clip (0,0) circle (3cm); \fill[green!30] (0,-1) circle (2.5cm); \end{scope} \node at (0,-0.5) {\textbf{Effective}}; \node at (0,-1) {\textbf{Permissions}}; \end{tikzpicture}

Definition-Example Pairs

• Account Email Alias: A functional mailbox address used for root access.
  • Example: Instead of using john.doe@company.com, use aws-root-admin@company.com. If John leaves the company, the business retains access to the account.
• Chargeback: The process of attributing cloud costs back to the specific business unit that generated them.
  • Example: A Marketing team runs a large campaign; using a "Department: Marketing" tag, the finance team can bill the Marketing budget specifically for that S3 and EC2 usage.
• Inheritance: The mechanism where a policy applied at a high level (OU) automatically applies to all children (Sub-OUs and Accounts).
  • Example: Denying the StopLogging action at the Root level ensures no account in the entire company can turn off CloudTrail.

Worked Examples

Scenario: Enforcing Region Restrictions

Problem: A European company wants to ensure that no developer accidentally launches resources in US regions to remain compliant with data residency laws.

Step-by-Step Solution:

1. Identify the tool: Use an SCP within AWS Organizations.
2. Define the Policy: Create a JSON policy with a Deny effect on all actions if the aws:RequestedRegion is not eu-central-1 or eu-west-1.
3. Target the OU: Apply this SCP to the "Development" OU.
4. Verification: Log into a developer account and attempt to launch an EC2 instance in us-east-1. The action will return an "Access Denied" error, even if the user has AdministratorAccess in IAM.

Checkpoint Questions

1. What is the main benefit of using a group email alias for the AWS root user account?
2. True or False: An SCP can grant permissions to a user who has no IAM policy attached.
3. In a multi-account environment, which account is responsible for paying the total bill?
4. What service automates the setup of a "Landing Zone" with pre-configured OUs and guardrails?

▶Click to reveal answers

1. Business continuity (the account isn't tied to one person who might leave).
2. False. SCPs only filter permissions; they never grant them.
3. The Management Account.
4. AWS Control Tower.

Muddy Points & Cross-Refs

• SCP vs. IAM: This is the most common confusion. Remember: IAM says "What can this person do?" while SCP says "What is the maximum this account is allowed to do?"
• The Root User: Even with Organizations, the root user of the management account should be highly protected (MFA in a physical vault).
• Cross-Account Access: For deeper study, look into IAM Roles and the sts:AssumeRole action to allow users to jump between accounts securely.

Comparison Tables

BU Style vs. Environment Style Structure

[!IMPORTANT] Always tag your resources during creation. Without a standardized tagging policy, consolidated billing becomes a "black box" where it is impossible to see which project is consuming the most budget.