Designing a Multi-Account AWS Environment

This guide focuses on Domain 1.4 of the AWS Certified Solutions Architect - Professional (SAP-C02) exam. It covers the transition from single-account management to a robust, governed multi-account strategy using AWS Organizations and AWS Control Tower.

Learning Objectives

After studying this guide, you should be able to:

• Evaluate the benefits of resource and billing isolation across multiple AWS accounts.
• Design an organizational structure using Organizational Units (OUs) that aligns with business units or environments.
• Implement Service Control Policies (SCPs) to establish security guardrails at scale.
• Leverage AWS Control Tower for automated Landing Zone deployment and governance.
• Analyze the intersection of SCPs and IAM permissions to determine effective access.

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.
• Organizational Unit (OU): A container for accounts within an organization. OUs can contain other OUs, creating a hierarchy up to five levels deep.
• 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 in member accounts.
• Landing Zone: A well-architected, multi-account AWS environment that is a starting point from which you can deploy workloads and applications.
• Management Account: The account used to create the organization, manage billing, and apply policies to the entire structure.

The "Big Idea"

In a single AWS account, the "blast radius" is large—a security breach or a billing spike impacts everything. The Big Idea behind a multi-account strategy is Isolation as a Governance Tool. By splitting workloads into separate accounts, you create hard boundaries for security, simplify cost allocation (billing isolation), and allow different teams to operate with autonomy while staying under central guardrails.

Formula / Concept Box

Hierarchical Outline

• I. AWS Organizations Structure
  • Root: The top-level parent for all OUs and accounts.
  • OUs (Organizational Units): Logical groupings (e.g., Security, Infrastructure, Workloads).
  • Member Accounts: The actual AWS accounts where resources live.
• II. Policy Management
  • Service Control Policies (SCPs): Applied at Root, OU, or Account level. Inherited downwards.
  • Inheritance Logic: Deny overrides Allow; the resulting permission is the intersection of all levels.
• III. Automation & Governance
  • AWS Control Tower: Orchestrates Organizations, IAM Identity Center, and Service Catalog.
  • Guardrails: Detective (Config rules) vs. Preventive (SCPs).

Visual Anchors

Organizational Hierarchy Flow

SCP Evaluation Logic

\begin{tikzpicture} \draw[thick] (0,0) circle (2cm) node[below=1.8cm] {IAM Permissions (User/Role)}; \draw[thick] (1.5,0) circle (2cm) node[below=1.8cm, right] {SCP (Organization Level)}; \begin{scope} \clip (0,0) circle (2cm); \fill[gray!30] (1.5,0) circle (2cm); \end{scope} \node at (0.75,0) {\textbf{Allowed}}; \node at (0.75,-0.5) {\small Intersection}; \end{tikzpicture}

Definition-Example Pairs

• Preventive Guardrail: A control that prevents an action from happening in the first place.
  • Example: An SCP that denies the s3:DeleteBucket action to ensure data persistence across all accounts in a Production OU.
• Detective Guardrail: A control that monitors for non-compliance and alerts you after the fact.
  • Example: An AWS Config rule that triggers an SNS notification if any EBS volume in the organization is not encrypted.

Worked Examples

Scenario: Restricting Regions

Problem: A global company wants to ensure that no resources are created outside of us-east-1 and eu-west-1 to comply with data residency and cost policies.

Step-by-Step Solution:

1. Identify the Level: The policy should apply to all Workload OUs but perhaps not the Global Security OU.
2. Draft the SCP:
   jsonCopy

   { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "NotAction": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "eu-west-1"] } } } ] }
3. Apply to OU: Attach this SCP to the Workload OU. All accounts under this OU (Production, Development) will now be restricted, regardless of their local IAM settings.

Checkpoint Questions

1. What is the maximum depth allowed for nesting Organizational Units (OUs)?
2. Does an SCP grant permissions to a user if the user's IAM policy is empty?
3. If an SCP at the Root level denies ec2:RunInstances but an SCP at the Member Account level allows it, what is the result?
4. Which service provides a pre-configured "Landing Zone" and automates the setup of a multi-account environment?

▶Click to see answers

1. 5 levels deep.
2. No. SCPs only limit permissions; IAM policies must still explicitly grant them.
3. The action is Denied. (Deny always overrides Allow in AWS policy evaluation).
4. AWS Control Tower.

Muddy Points & Cross-Refs

• SCP vs. IAM: A common point of confusion is thinking SCPs replace IAM. They don't. Think of the SCP as the "ceiling" of what is possible. If the ceiling is lower than the IAM permission, the IAM permission is clipped.
• Control Tower vs. Organizations: Control Tower uses Organizations. Think of Organizations as the engine and Control Tower as the luxury dashboard that configures the engine, steering wheel, and safety features for you.
• Billing vs. Security: While Organizations provides Consolidated Billing, its primary architectural value in SAP-C02 is security isolation and centralized policy management.

Comparison Tables

SCP vs. IAM Permissions Boundary

Multi-Account Strategies