This chapter covers multi-account architecture using AWS Organizations, a core topic for the SOA-C02 exam. You'll learn how to design, implement, and manage multiple AWS accounts under a central governance model. Approximately 10-15% of exam questions touch on AWS Organizations, Service Control Policies (SCPs), and consolidated billing. Mastering this topic is critical for the Security domain (Objective 4.1) and for understanding how enterprises scale securely in AWS.
Jump to a section
Imagine a large corporate holding company that owns several subsidiaries. The holding company (AWS Organizations) creates a master account (management account) that sets overall policies for all subsidiaries (member accounts). Each subsidiary operates its own bank accounts, employees, and resources, but the holding company can enforce rules like spending limits (Service Control Policies) or require that all subsidiaries use approved vendors (e.g., only AWS services from certain regions). The holding company can also create new subsidiaries (create accounts) and group them by business unit (Organizational Units). If a subsidiary is acquired (invited account), it can join the holding company but retain some independence. The holding company's CFO can view consolidated billing across all subsidiaries, but each subsidiary's day-to-day operations remain separate. This mirrors how AWS Organizations centralizes governance, billing, and policy enforcement while maintaining account-level isolation.
What is AWS Organizations?
AWS Organizations is a free account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. It provides hierarchical grouping of accounts (Organizational Units or OUs), policy-based management via Service Control Policies (SCPs), and consolidated billing. The service is foundational for enterprises that need to separate environments (dev, test, prod) or business units while maintaining centralized control.
How AWS Organizations Works Internally
When you create an organization, you designate a management account (formerly called master account). This account has special privileges: it can create new member accounts, invite existing accounts to join, apply SCPs, and view consolidated billing. Member accounts are standard AWS accounts that can be created programmatically or via invitation. The management account pays for all member account usage through consolidated billing, which aggregates usage and applies volume discounts.
Key Components and Defaults
Organization Root: The top-level container in the hierarchy. All accounts in the organization are descendants of the root. You can attach policies (SCPs) at the root level, which apply to all accounts.
Organizational Units (OUs): Logical containers within the root that group accounts. OUs can have nested OUs (up to 5 levels deep). Policies attached to an OU apply to all accounts in that OU and its sub-OUs.
Service Control Policies (SCPs): JSON-based policies that specify the maximum permissions for accounts in the organization. SCPs do not grant permissions; they define an upper boundary. They can be attached to the root, OUs, or individual accounts. By default, the FullAWSAccess SCP is attached, allowing all actions. When you create a custom SCP, you must explicitly allow actions; deny rules override allows.
Consolidated Billing: All accounts share the billing of the management account. This allows you to receive a single bill, aggregate usage for volume discounts, and track costs by account. There is no additional cost for consolidated billing.
Account Creation: You can create up to 1000 accounts per organization (soft limit). New accounts are created with no IAM users or roles; you must log in as the root user (email and password) initially.
Invitation Process: Existing AWS accounts can be invited to join an organization. The invited account receives an email and must accept the invitation via the AWS Organizations console. Once accepted, the account becomes a member account.
Configuration and Verification Commands
Using the AWS CLI, you can manage organizations:
Create an organization: aws organizations create-organization --feature-set ALL
Create an account: aws organizations create-account --email admin@example.com --account-name "ProdAccount"
List accounts: aws organizations list-accounts
Create an OU: aws organizations create-organizational-unit --parent-id r-xxxx --name "Production"
Attach SCP: aws organizations attach-policy --policy-id p-xxxx --target-id ou-xxxx
List policies: aws organizations list-policies --filter SERVICE_CONTROL_POLICY
How SCPs Work
SCPs are evaluated before IAM policies. If an SCP denies an action, it is blocked regardless of IAM permissions. SCPs use an allow list model by default (except when you explicitly deny). For example, to deny EC2 instance creation in a specific region, you can create an SCP that denies ec2:RunInstances if the request comes from that region. SCPs do not affect the management account; the management account always has full access.
Interplay with IAM and Resource-Based Policies
SCPs work in conjunction with IAM policies. The effective permissions for a principal are the intersection of the SCP boundary and the IAM policy. Resource-based policies (like S3 bucket policies) are not affected by SCPs if the principal is in the same account, but cross-account access is subject to SCPs. For example, if an SCP denies s3:GetObject, even an IAM policy granting it will not work.
Migration from Consolidated Billing Only
If you were previously using consolidated billing without organizations (legacy), you can upgrade to AWS Organizations. This enables SCPs and other features. The process is irreversible once you enable all features.
Service Limits and Quotas
Maximum accounts per organization: 1000 (can be increased by AWS Support)
Maximum OUs per root: 1000
Maximum SCPs per account: 1000
Maximum SCP size: 5120 characters
Maximum nesting depth of OUs: 5 levels
Security Considerations
The management account should be heavily secured with MFA, strong passwords, and limited IAM access. Use AWS CloudTrail to log all management account activities. Consider using AWS Control Tower for automated multi-account setup and governance.
How It Interacts with Other Services
AWS Single Sign-On (SSO): Can be integrated with Organizations to provide federated access across accounts.
AWS CloudTrail: Can be configured to log API calls in all accounts centrally.
AWS Config: Can aggregate compliance data across accounts.
AWS Budgets: Can track spending across accounts.
AWS Service Catalog: Can deploy standardized products across accounts.
Exam Tips
Remember that SCPs do not grant permissions; they only deny or allow actions within a boundary.
The management account is not affected by SCPs.
By default, the FullAWSAccess SCP is attached; removing it effectively denies all actions (unless you attach a permissive SCP).
SCPs can be used to enforce that only certain instance types are used or that encryption is enabled.
Consolidated billing does not require any additional configuration beyond creating the organization.
Create the Organization
Sign in to the management account (typically a dedicated account for administration). Navigate to the AWS Organizations console and click 'Create organization'. You can choose 'All features' (recommended) or 'Consolidated billing features only'. All features enable SCPs and other advanced capabilities. Once created, the organization root is created automatically. The management account becomes the payer account for consolidated billing. Note: This action cannot be undone; you cannot revert to a standalone account without contacting AWS Support.
Create Organizational Units (OUs)
Design a hierarchy that reflects your business structure or environment separation. Common OUs include 'Security', 'Infrastructure', 'Workloads', 'Sandbox', 'Suspended'. Create OUs under the root using the console, CLI, or SDK. For example, create 'Production' and 'Development' OUs. You can nest OUs up to 5 levels deep. Each OU can have policies attached. Best practice: Use OUs to group accounts that require similar governance (e.g., all production accounts under one OU).
Create or Invite Member Accounts
You can create new accounts directly from the Organizations console. Provide an email address (must be unique per account) and an account name. AWS will create the account and send a verification email. Alternatively, invite existing AWS accounts by entering the account ID or email. The invited account must accept the invitation within 30 days. Once accepted, the account becomes a member. New accounts have no IAM users; you must access them via the root user credentials sent to the email. For automation, use the AWS CLI or SDK.
Move Accounts into OUs
After accounts are created or invited, you can move them into the appropriate OUs. For example, move the production account into the 'Production' OU. You can move accounts between OUs at any time. Moving an account may affect which SCPs apply. The management account always remains in the root and cannot be moved. Use the console or CLI: `aws organizations move-account --account-id 123456789012 --source-parent-id r-xxxx --destination-parent-id ou-xxxx`.
Attach Service Control Policies (SCPs)
Create SCPs that enforce your governance requirements. For example, create an SCP that denies the ability to disable CloudTrail or to create resources outside of allowed regions. Attach the SCP to the root, an OU, or directly to an account. SCPs are inherited: policies attached to the root apply to all accounts; those attached to an OU apply to all accounts in that OU. The management account is not affected by SCPs. Test SCPs using the SCP simulator (available in the console). Remember: SCPs are evaluated before IAM; if an action is denied by SCP, it cannot be performed even if IAM allows it.
Enable Consolidated Billing and Cost Management
Consolidated billing is automatically enabled when you create the organization with all features. The management account receives a single bill for all member accounts. You can view cost data in AWS Cost Explorer, create budgets, and use cost allocation tags. To separate costs, tag resources consistently across accounts. Note that member accounts can still access their own billing console but cannot see other accounts' costs. The management account can see all costs. Use AWS Organizations to set up a cost allocation report by account or tag.
Enterprise Scenario 1: Multi-Environment Isolation
A financial services company needs to separate development, testing, and production environments for compliance. They create an organization with three OUs: 'Dev', 'Test', and 'Prod'. Each OU has multiple accounts (e.g., 'Dev-Account-1', 'Dev-Account-2'). SCPs are attached at the OU level: for 'Dev', they allow all services but restrict instance types to t2.micro; for 'Test', they allow more instance types but deny production-level services like AWS Shield; for 'Prod', they enforce encryption and require MFA for all API calls. The management account is used only for billing and administration. This prevents developers from accidentally accessing production resources. A common misconfiguration is failing to tag resources, making cost allocation difficult. The company uses AWS Budgets in the management account to set alerts for each OU.
Enterprise Scenario 2: Centralized Security and Logging
A large e-commerce company wants to centralize security monitoring across hundreds of accounts. They create a 'Security' OU containing accounts for CloudTrail, AWS Config, and GuardDuty. They use SCPs to enforce that all member accounts must deliver CloudTrail logs to a centralized S3 bucket in the security account. They also attach an SCP that denies any action that would disable CloudTrail or delete the S3 bucket. The security team uses AWS Single Sign-On to manage access across accounts. They set up AWS Config rules to check for compliance. A common issue is that SCPs cannot enforce resource-based policies like S3 bucket policies; they rely on the account administrator to configure them correctly. To mitigate, they use AWS Config rules to detect non-compliant buckets.
Enterprise Scenario 3: Mergers and Acquisitions
A company acquires a smaller firm that already uses AWS. They invite the acquired company's account to join their organization. The acquired account must accept the invitation. Once joined, the account is moved into a 'Suspended' OU initially, where an SCP denies all actions except those needed for migration. The team then audits the account's resources and gradually moves them into the appropriate OUs. A challenge is that the acquired account may have existing IAM users and roles; SCPs can restrict them, but the management account cannot modify the member account's IAM policies directly. They use AWS CloudFormation StackSets to deploy standard IAM roles across all accounts. A common mistake is not removing the FullAWSAccess SCP from the acquired account, which would leave it unrestricted.
Exam Focus: AWS Organizations on SOA-C02
This topic falls under Domain 4: Security, Objective 4.1: Implement and manage security and compliance controls. The exam tests your ability to design and troubleshoot multi-account architectures using AWS Organizations, SCPs, and consolidated billing. Expect 3-5 questions on this topic.
Common Wrong Answers and Why
SCPs grant permissions: Many candidates think SCPs work like IAM policies that grant access. In reality, SCPs define a permission boundary; they never grant permissions. The correct answer is that SCPs only allow or deny actions within the boundary, and IAM policies still need to grant access.
Management account is subject to SCPs: Some think the management account is also restricted by SCPs. The exam highlights that the management account is exempt from SCPs. This is a frequent trap.
SCPs affect resource-based policies: Candidates may think SCPs can override resource-based policies like S3 bucket policies. However, SCPs only affect IAM principals; resource-based policies are evaluated separately. The effective permission is the union of SCP, IAM, and resource-based policies (for same-account access).
Consolidated billing requires separate payment methods: Some believe each account needs its own payment method. In reality, the management account's payment method is used for all accounts.
Specific Numbers and Terms to Memorize
Maximum 1000 accounts per organization (soft limit)
OU nesting depth: 5 levels
SCP size limit: 5120 characters
Default SCP: FullAWSAccess
Invitation expiry: 30 days
Feature sets: 'All features' vs 'Consolidated billing features only'
Edge Cases the Exam Loves
Removing FullAWSAccess: If you remove the default SCP without attaching another, all actions are implicitly denied. The exam may ask what happens when you detach FullAWSAccess.
SCP evaluation order: SCPs are evaluated in order of hierarchy (root, OU, account). Deny always overrides allow. The exam may test that a deny at the root blocks an action even if an OU-level SCP allows it.
Moving accounts between OUs: When you move an account, the new SCPs apply immediately. The exam may ask about the timing.
Creating accounts via API: The email address must be unique; if you try to create an account with an email already used, it fails.
How to Eliminate Wrong Answers
If a question asks about restricting permissions, look for answers that mention SCPs as a boundary, not as a grant.
If an answer says 'management account can be restricted by SCPs', eliminate it.
For questions about cross-account access, remember that SCPs affect the principal's account, not the resource account. If a user in account A tries to access a resource in account B, SCPs in account A apply to the user, but the resource account's SCPs do not directly block the access (unless the resource account has a resource-based policy).
AWS Organizations allows you to centrally manage multiple AWS accounts with consolidated billing and policy-based governance.
Service Control Policies (SCPs) define permission boundaries; they never grant permissions and do not affect the management account.
The management account is the only account that can create new accounts and invite existing ones.
By default, the FullAWSAccess SCP is attached to all accounts; removing it without attaching another SCP denies all actions.
SCPs are evaluated hierarchically: root -> OU -> account. Deny always overrides allow.
Consolidated billing aggregates usage across all accounts, enabling volume discounts and a single bill.
Maximum 1000 accounts per organization, OU nesting depth of 5 levels, SCP size limit of 5120 characters.
These come up on the exam all the time. Here's how to tell them apart.
All Features
Supports SCPs for permission boundaries
Supports central logging and CloudTrail aggregation
Allows integration with AWS SSO
Can create accounts programmatically
Supports tagging of accounts
Consolidated Billing Only
Only provides consolidated billing
No SCPs or policy enforcement
No integration with SSO
Cannot create accounts; must invite existing accounts
No account tagging
Mistake
SCPs grant permissions to users and roles in member accounts.
Correct
SCPs never grant permissions. They define the maximum allowed permissions. IAM policies still need to grant the specific actions. SCPs act as a guardrail, not an access grant.
Mistake
The management account is also subject to SCPs.
Correct
The management account is not affected by SCPs. It always has full administrative access. This is a key distinction tested on the exam.
Mistake
SCPs can override resource-based policies like S3 bucket policies.
Correct
SCPs affect IAM principals only. Resource-based policies are evaluated independently. For same-account access, the effective permission is the union of SCP, IAM, and resource-based policies. For cross-account access, SCPs apply to the principal's account, but the resource-based policy must also allow access.
Mistake
Consolidated billing requires each account to have its own payment method.
Correct
All member accounts use the management account's payment method. No separate payment method is needed for member accounts.
Mistake
You can have multiple management accounts in a single organization.
Correct
An organization has exactly one management account. All other accounts are member accounts. The management account cannot be changed without contacting AWS Support.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, each organization has exactly one management account. The management account is the account that created the organization and has special privileges. Member accounts can be created or invited, but only one account serves as the management account. To change the management account, you must contact AWS Support or create a new organization.
No, SCPs do not affect the management account. The management account always has full administrative access. This is a critical point for the exam. SCPs are only applied to member accounts and OUs.
If you detach the FullAWSAccess SCP from an account or OU without attaching any other SCP, all actions are implicitly denied because no permissions are allowed. The account will lose access to all AWS services. To restore access, you must attach an SCP that allows the necessary actions.
Yes, you can create an SCP that denies the `ec2:RunInstances` action if the request does not include an encrypted EBS volume. However, SCPs cannot enforce encryption on existing instances; they only affect new actions. For compliance, use AWS Config rules to detect non-compliant resources.
Go to the AWS Organizations console, click 'Add account', then 'Invite account'. Enter the account ID or email address of the account to invite. An email is sent to the account's root email. The account must accept the invitation within 30 days. The invited account can also reject the invitation.
'All features' enables SCPs, central logging, and integration with other AWS services like SSO. 'Consolidated billing only' provides only consolidated billing without policy control. You can upgrade from 'Consolidated billing only' to 'All features' but not downgrade.
Yes, you can move accounts between OUs at any time. When you move an account, the SCPs attached to the new OU apply immediately. The management account cannot be moved; it always resides in the root.
You've just covered Multi-Account Architecture with AWS Organizations — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?