AWS Multi-Account Governance: Evaluating and Implementing Organizational Structures

This study guide focuses on the critical competency of designing and managing a multi-account AWS environment. It covers the architectural patterns, security guardrails, and billing strategies required for complex, large-scale organizational requirements.

Learning Objectives

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

• Evaluate various account structures (Business Unit, Environment, Project) to meet organizational needs.
• Architect an Organizational Unit (OU) hierarchy that scales and maintains security.
• Design Service Control Policies (SCPs) to establish effective security guardrails.
• Implement a centralized billing and cost allocation strategy using AWS Organizations.
• Recommend best practices for account identity and communication (functional aliases).

Key Terms & Glossary

• AWS Organizations: An account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage.
• Management Account: The account that creates the organization. It has the authority to manage member accounts and handles consolidated billing.
• Organizational Unit (OU): A container for accounts within an organization. OUs can contain other OUs, enabling a hierarchical structure.
• Service Control Policy (SCP): A type of organization policy that you can use to manage permissions in your organization, acting as a filter for what actions are allowed.
• Consolidated Billing: A feature of AWS Organizations that consolidates payment for all member accounts under the management account.
• Root: The parent container for all the accounts for your organization.

The "Big Idea"

In a single-account setup, security and blast radius management are difficult. The "Big Idea" of multi-account governance is isolation by design. By partitioning workloads into separate accounts grouped by logical OUs, organizations can achieve high degrees of security, simplified billing, and autonomous development environments while maintaining centralized oversight through global guardrails (SCPs).

Formula / Concept Box

SCP Permission Logic

[!IMPORTANT] Hierarchy Limit: AWS Organizations supports a maximum depth of 5 levels of OUs below the root.

Hierarchical Outline

1. Organizational Structures
   • Business Unit (BU) Style: Matches the company's internal hierarchy (e.g., HR, Finance, Engineering).
   • Environment Style: Segregates by SDLC stage (e.g., Dev, Test, Prod).
   • Project Style: Isolates specific initiatives or product lines regardless of department.
2. Resource Isolation and Governance
   • OUs: Logical grouping for policy application.
   • SCPs: Top-down permission boundaries; do not grant permissions, only limit them.
3. Billing and Cost Management
   • Consolidated Billing: Single payment method, volume discounts shared across accounts.
   • Tagging Strategy: Using Cost Allocation Tags (e.g., CostCenter, ProjectID) for internal chargebacks.
4. Administrative Best Practices
   • Email Aliases: Use functional group aliases (e.g., cloud-ops+prod@company.com) instead of personal emails.
   • Cross-Account Access: Using IAM Roles instead of long-term credentials.

Visual Anchors

Account Hierarchy Model (BU + Environment Hybrid)

SCP Intersection Logic

This TikZ diagram illustrates how permissions are restricted as they flow down the hierarchy.

\begin{tikzpicture} [node distance=1.5cm, block/.style={rectangle, draw, fill=blue!10, text width=5cm, text centered, rounded corners, minimum height=1cm}]

\node [block] (root) {\textbf{Root SCP}: Allow All}; \node [block, below of=root] (ou) {\textbf{OU SCP}: Deny \texttt{us-east-1}}; \node [block, below of=ou] (account) {\textbf{Account SCP}: Deny \texttt{iam:DeleteRole}}; \node [block, fill=green!10, below of=account, node distance=2cm] (result) {\textbf{Effective Permissions}:\ Any action EXCEPT in \texttt{us-east-1}\ AND NO \texttt{iam:DeleteRole}};

\draw [->, thick] (root) -- (ou); \draw [->, thick] (ou) -- (account); \draw [->, thick] (account) -- (result);

\end{tikzpicture}

Definition-Example Pairs

• Term: Functional Email Alias

  • Definition: A mailing list or group address used as the root user email for an AWS account.
  • Example: Using aws-admins+billing@example.com ensures that even if the primary admin leaves the company, the billing notifications are still accessible by the finance team.

• Term: Tag-Based Cost Allocation

  • Definition: Assigning metadata to resources that AWS uses to categorize costs in billing reports.
  • Example: Tagging an EC2 instance with Project: Apollo. At the end of the month, the CFO can see exactly how much of the $10,000 bill was spent specifically on Project Apollo.

Worked Examples

Scenario: The Global Multi-National

Challenge: A company operates in 3 continents with strict data sovereignty laws (GDPR). They have 50 different internal apps. How should they structure accounts?

Solution Breakdown:

1. Top Level: Create a Region-Based OU structure (Europe, Americas, Asia) to apply regional SCPs (e.g., restrict data movement outside Europe for the Europe OU).
2. Second Level: Create Environment OUs (Prod, Non-Prod) within each region to ensure different security baselines for live data.
3. Governance: Apply an SCP at the Root to prevent anyone from leaving the Organization or disabling CloudTrail.

Checkpoint Questions

1. What is the maximum number of OU levels allowed in AWS Organizations?
2. Does an SCP attached to a member account grant permissions to an IAM user in that account?
3. Why should a company avoid using john.doe@company.com as the root email for a production account?
4. Which account in an organization is responsible for paying the charges of all other accounts?

▶Click to see answers

1. 5 levels.
2. No, SCPs only filter permissions; IAM policies are still required to grant them.
3. Business continuity; if John leaves, the company may lose access to the root credentials.
4. The Management Account.

Muddy Points & Cross-Refs

• SCP vs. IAM Permission Boundaries: This is often confused. Remember: SCPs apply to the entire account (including the root user), whereas IAM Permission Boundaries apply to specific users or roles within an account.
• Consolidated Billing vs. Cost Explorer: Consolidated billing is the mechanism for payment; Cost Explorer is the tool used to visualize and analyze the data generated by that billing.

Comparison Tables

Account Structure Patterns

[!TIP] Most modern enterprises use a Hybrid Model: Top-level OUs for Security/Infrastructure, followed by Business Unit OUs, with Environment sub-OUs beneath them.