Multi-account architecture is one of the most heavily tested areas on the AWS Certified Solutions Architect Professional (SAP-C02) exam. Nearly every scenario-based question assumes you are working across multiple AWS accounts, and you are expected to design solutions that balance security, scalability, and operational efficiency at the organizational level.
This guide provides a deep dive into AWS Organizations, Service Control Policies (SCPs), Control Tower, cross-account access patterns, and landing zone architecture — all essential topics for Domain 1 of the SAP-C02 exam. If you are looking for an overview of all exam domains, see our SAP-C02 exam guide.
Why Multi-Account Architecture Matters for SAP-C02
The SAP-C02 exam tests your ability to design enterprise-grade solutions. In practice, no serious enterprise runs everything in a single AWS account. Multiple accounts provide:
- Blast radius reduction — A security breach or misconfiguration in one account does not affect others
- Billing isolation — Clear cost attribution across business units, projects, or environments
- Service limit isolation — Each account has its own service quotas, preventing one workload from starving another
- Regulatory compliance — Separate accounts for PCI, HIPAA, or other compliance boundaries
- Team autonomy — Development teams can operate independently within guardrails
On the exam, you will encounter questions that ask you to choose between single-account and multi-account designs, or to optimize an existing multi-account setup. Understanding the trade-offs is critical.
AWS Organizations: The Foundation
AWS Organizations is the service that enables centralized management of multiple AWS accounts. It provides a hierarchical structure using Organizational Units (OUs), consolidated billing, and policy-based governance.
Organizations Hierarchy
The hierarchy in AWS Organizations follows this structure:
| Level | Description | Example |
|---|---|---|
| Management Account | The root account that creates and manages the organization. Cannot be moved or restricted by SCPs. | Company master account |
| Root | The top-level container for all accounts in the organization | Organization root |
| Organizational Unit (OU) | A logical grouping of accounts. OUs can be nested up to 5 levels deep. | Production OU, Development OU, Security OU |
| Member Account | An individual AWS account that belongs to the organization | App-team-prod, data-team-dev |
Key Design Principles
Management account isolation. The management account should contain no workloads. It exists solely for organization management, billing, and root-level administrative tasks. This is a principle the exam tests repeatedly.
OU structure should mirror your governance model, not your org chart. A common mistake is creating OUs that map 1:1 to business departments. Instead, OUs should reflect how you want to apply policies. Common OU patterns include:
- Security OU — Log archive account, security tooling account
- Infrastructure OU — Shared services, networking, DNS
- Sandbox OU — Developer experimentation accounts with aggressive cost controls
- Workloads OU — Subdivided into Production and Non-Production
- Suspended OU — For accounts being decommissioned (SCPs deny all actions)
Consolidated Billing Benefits
All accounts in an organization share a single payment method and receive consolidated billing. This provides:
- Volume pricing discounts across all accounts (S3, EC2, etc.)
- Reserved Instance and Savings Plans sharing across the organization (or specific linked accounts)
- Cost allocation tags for granular cost tracking
On the SAP-C02 exam, expect questions about how Reserved Instances apply across accounts within an organization, and how to restrict RI sharing to specific accounts.
Service Control Policies (SCPs): Guardrails at Scale
SCPs are the primary governance mechanism in AWS Organizations. They define the maximum available permissions for accounts within an OU or for individual member accounts.
How SCPs Work
SCPs do not grant permissions. They set permission boundaries. Even if an IAM user has full administrator access, an SCP can prevent them from performing certain actions. Think of SCPs as a filter:
Effective permissions = IAM policies INTERSECTION SCP policies
Critical facts for the exam:
- SCPs do not affect the management account — this is a common exam trap
- SCPs affect all users and roles in member accounts, including the root user
- SCPs do not affect service-linked roles
- SCPs use the same JSON policy language as IAM policies
- SCPs can be attached to the root, OUs, or individual accounts
- An explicit Deny in an SCP always wins
SCP Design Patterns
Pattern 1: Deny List (Recommended)
Start with the default FullAWSAccess SCP and add deny statements for actions you want to block. This is the most common and flexible approach.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyLeavingOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
}
]
}Pattern 2: Allow List
Remove the default FullAWSAccess SCP and explicitly allow only the services you want. This is more restrictive but harder to manage at scale.
Common SCP Use Cases on the SAP-C02 Exam:
| Use Case | SCP Strategy |
|---|---|
| Prevent accounts from leaving the organization | Deny organizations:LeaveOrganization |
| Restrict regions | Deny all actions with a StringNotEquals condition on aws:RequestedRegion |
| Enforce encryption | Deny S3 PutObject without s3:x-amz-server-side-encryption |
| Prevent disabling CloudTrail | Deny cloudtrail:StopLogging and cloudtrail:DeleteTrail |
| Block public S3 access | Deny s3:PutBucketPublicAccessBlock when set to false |
| Restrict root user activity | Deny all actions with condition on aws:PrincipalArn matching root |
SCP Inheritance and Evaluation
SCPs are inherited from parent OUs. The effective SCP for an account is the intersection of all SCPs from the root down to the account. If a parent OU denies an action, no child OU or account can allow it.
On the exam, you may see a scenario where a developer account inside Root > Workloads > Development has different SCPs at each level. You must trace the inheritance to determine what is allowed.
AWS Control Tower: Automated Landing Zones
AWS Control Tower provides an automated, opinionated way to set up and govern a multi-account environment. It builds on top of AWS Organizations, AWS SSO (IAM Identity Center), and AWS Config.
What Control Tower Provides
- Automated account provisioning via Account Factory
- Pre-configured OUs (Security and Sandbox by default)
- Guardrails — Preventive (implemented as SCPs) and Detective (implemented as AWS Config rules)
- Dashboard for compliance visibility across all accounts
- Centralized logging in a dedicated Log Archive account
- Audit account for security team access
Control Tower Guardrails
Control Tower guardrails come in three categories:
| Category | Implementation | Behavior |
|---|---|---|
| Preventive | Service Control Policies | Blocks disallowed actions before they occur |
| Detective | AWS Config Rules | Identifies non-compliant resources after creation |
| Proactive | CloudFormation Hooks | Checks resource compliance before provisioning |
Guardrails also have enforcement levels:
- Mandatory — Always enabled, cannot be turned off (e.g., disallow changes to log archive)
- Strongly recommended — Best practices that should be enabled in most cases
- Elective — Optional guardrails for specific use cases
Account Factory
Account Factory is the mechanism for creating new accounts in Control Tower. It integrates with AWS Service Catalog to provide a self-service account provisioning workflow. Key features:
- Pre-configured networking (VPC, subnets, NAT gateways)
- Automatic enrollment in guardrails
- SSO integration for identity management
- Customizable account blueprints (via Account Factory Customization or AFC)
For SAP-C02, understand that Account Factory for Terraform (AFT) exists for organizations that prefer Terraform-based account provisioning.
Cross-Account Access Patterns
Cross-account access is a constant theme on the SAP-C02. You need to know multiple patterns and when to use each.
Pattern 1: IAM Role Assumption (AssumeRole)
The most common cross-account access pattern. An IAM principal in Account A assumes a role in Account B.
Setup:
- Account B creates a role with a trust policy allowing Account A
- Account A’s IAM user or role has permission to call
sts:AssumeRoletargeting Account B’s role - The principal calls AssumeRole and receives temporary credentials
When to use: Most cross-account scenarios — accessing S3 buckets, DynamoDB tables, managing resources in another account.
Pattern 2: Resource-Based Policies
Some AWS services support resource-based policies that allow cross-account access without role assumption. These include S3 buckets, KMS keys, SNS topics, SQS queues, and Lambda functions.
When to use: When you need direct access to a specific resource without the overhead of role assumption, or when you need to retain the original caller’s identity.
Pattern 3: AWS RAM (Resource Access Manager)
AWS RAM allows you to share resources across accounts within your organization without creating duplicate resources. Shareable resources include:
- Transit Gateway
- Subnets
- License Manager configurations
- Route 53 Resolver rules
- AWS Network Firewall policies
When to use: Sharing infrastructure resources across accounts, especially networking components.
Pattern 4: IAM Identity Center (AWS SSO)
For human users, IAM Identity Center provides centralized access management across all accounts in your organization. It integrates with external identity providers (Okta, Azure AD, etc.) via SAML 2.0 or SCIM.
When to use: Human user access to the AWS Console and CLI across multiple accounts.
Landing Zone Architecture Patterns
A landing zone is the pre-configured, secure, multi-account environment that serves as the foundation for your AWS workloads. The SAP-C02 tests your ability to design and evaluate landing zones.
Standard Landing Zone Components
A well-architected landing zone includes:
- Management account — Organization management only, no workloads
- Log archive account — Centralized CloudTrail logs, VPC Flow Logs, Config logs (write-once, read-by-security-team)
- Security/audit account — Security tooling, GuardDuty delegated administrator, Security Hub aggregation
- Shared services account — Active Directory, DNS, CI/CD pipelines, container registries
- Networking account — Transit Gateway, Direct Connect, shared VPCs, DNS resolution
- Workload accounts — Separated by environment (prod, staging, dev) and team or application
Networking in a Landing Zone
The networking design in a multi-account landing zone is a frequent exam topic. Common patterns include:
Hub-and-spoke with Transit Gateway: A central networking account owns the Transit Gateway and shares it via RAM. Workload account VPCs attach to the Transit Gateway. This enables centralized routing, inspection, and egress.
Shared VPC model: The networking account creates VPCs and shares subnets with workload accounts via RAM. Workload accounts launch resources into shared subnets but do not manage the VPC itself.
For more on networking patterns, see our advanced networking deep dive.
Centralized Logging Architecture
Every account should send logs to a centralized log archive account:
- CloudTrail — Organization trail enabled in the management account, logs delivered to the log archive S3 bucket
- VPC Flow Logs — Sent to a centralized S3 bucket or CloudWatch Logs in the log archive account
- AWS Config — Aggregator in the security account collects Config data from all member accounts
- GuardDuty — Delegated administrator in the security account with auto-enable for new accounts
Real-World Scenario: Designing a Landing Zone
Scenario: A financial services company is migrating to AWS. They have 50 application teams, strict regulatory requirements (PCI-DSS and SOC 2), and need separate environments for development, staging, and production.
Solution approach:
- OU structure: Security OU, Infrastructure OU, Workloads OU (with Prod and Non-Prod child OUs), Sandbox OU, Suspended OU
- SCPs: Region restriction (us-east-1 and eu-west-1 only), deny public S3 access, enforce encryption, prevent CloudTrail modification
- Networking: Transit Gateway in a central networking account, shared via RAM, with inspection VPC for egress traffic
- Identity: IAM Identity Center with external SAML provider, permission sets per OU
- Logging: Organization CloudTrail, centralized Config aggregation, delegated GuardDuty administrator
- Account provisioning: Control Tower Account Factory with customized blueprints for each OU
This type of holistic design question is exactly what the SAP-C02 tests.
Exam Tips for Multi-Account Architecture
- The management account is never restricted by SCPs — questions that suggest otherwise are traps
- When a question mentions “least privilege across accounts,” think SCP + IAM intersection
- Control Tower is the answer when the question asks for an “automated” or “scalable” way to set up a multi-account environment
- AWS RAM is the answer for sharing infrastructure resources (Transit Gateway, subnets) without duplication
- Cross-account role assumption is the default pattern; resource-based policies are for specific services
- “Centralized logging” almost always means a dedicated log archive account with organization-wide trails
- For compliance-heavy scenarios, look for answers that combine preventive guardrails (SCPs) with detective controls (Config rules)
Frequently Asked Questions
What is the difference between SCPs and IAM policies?
IAM policies grant permissions to principals within an account. SCPs set the maximum permissions boundary for all principals in an account (or OU). SCPs never grant permissions — they only restrict what IAM policies can allow. The effective permission is the intersection of both.
Can SCPs restrict the root user of a member account?
Yes. SCPs restrict all IAM principals in member accounts, including the root user. However, SCPs do not affect the management account at all, including its root user.
When should I use Control Tower vs. manual Organizations setup?
Use Control Tower when you want an opinionated, automated setup with pre-built guardrails and account provisioning. Use manual Organizations setup when you need full customization, have unique OU structures, or when Control Tower does not support your required regions or configurations.
How many accounts should a typical enterprise have?
There is no fixed number. The principle is one account per workload per environment. A company with 10 applications across 3 environments (dev, staging, prod) would have at least 30 workload accounts, plus shared accounts for security, logging, networking, and shared services.
Can I nest OUs inside other OUs?
Yes. AWS Organizations supports nesting OUs up to 5 levels deep. SCPs are inherited at each level, and the effective policy is the intersection of all ancestor SCPs.
What happens if I apply conflicting SCPs at different OU levels?
SCPs follow an intersection model. If a parent OU denies an action, no child OU or account can allow it. An explicit Deny always overrides an Allow at any level.
How does cross-account access work with KMS keys?
KMS keys require both a key policy (resource-based) in the key’s account and IAM permissions in the calling account. For cross-account access, the key policy must grant access to the external account’s principal, and the caller must have IAM permissions to use the key.
Does Control Tower work with existing AWS Organizations?
Yes. Control Tower can be enabled on an existing organization, but it requires the organization to meet certain prerequisites. It will create the required OUs (Security, Sandbox) and accounts (Log Archive, Audit) if they do not already exist.
Conclusion
Multi-account architecture is foundational to the SAP-C02 exam. Mastering AWS Organizations, SCPs, Control Tower, cross-account access patterns, and landing zone design will prepare you for a significant portion of Domain 1 questions. These topics do not exist in isolation — they connect directly to networking, security, and disaster recovery patterns you will also see on the exam.
The best way to solidify this knowledge is through realistic practice questions that present multi-account scenarios. Try Sailor.sh’s SAP-C02 mock exams to test your understanding with exam-style questions that mirror the complexity and depth of the real SAP-C02.