Cargando...
Cargando...
Centrally govern, secure, and manage billing across every AWS account you own — at scale.
AWS Organizations is a global account management service that lets you consolidate multiple AWS accounts into an organization, apply policy-based controls (SCPs), and centralize billing. It serves as the backbone for enterprise governance, enabling you to enforce guardrails across hundreds of accounts without touching each one individually. It integrates deeply with AWS Control Tower, AWS Config, AWS Security Hub, and dozens of other services to form a unified security and compliance posture.
Centrally manage policies, billing, and security guardrails across multiple AWS accounts using a hierarchical structure of Organizational Units (OUs) and Service Control Policies (SCPs).
Use When
Avoid When
Service Control Policies (SCPs)
Permission guardrails that restrict what IAM principals in member accounts can do — even the root user of a member account is subject to SCPs.
Consolidated Billing
Available in ALL features mode AND billing-only mode. Aggregates usage for volume discounts and enables RI/Savings Plan sharing across accounts.
Tag Policies
Enforce standardized tag keys and values across the organization. Requires All Features mode.
Backup Policies
Centrally manage AWS Backup plans across accounts. Requires All Features mode.
AI Services Opt-Out Policies
Opt out of AWS using your content to improve AI/ML services (e.g., Rekognition, Comprehend) across all accounts.
Delegated Administrator
Designate a member account as the admin for a specific AWS service (e.g., Security Hub, GuardDuty), removing the need to use the management account for day-to-day operations.
All Features Mode
Enables SCPs, policy types, and trusted access. Cannot revert to billing-only mode without removing all member accounts.
Consolidated Billing Only Mode
Subset of features — only billing aggregation. No SCPs, no policy types.
AWS CloudFormation StackSets Integration
Deploy stacks across all accounts and regions in an OU automatically using SERVICE_MANAGED deployment model.
Trusted Access for AWS Services
Enables AWS services (Config, Security Hub, etc.) to perform actions across all accounts in the org using the org's management account credentials.
Management Account Protection
SCPs do NOT apply to the management account — this is a critical security design consideration.
Cross-Account Resource Sharing via RAM
AWS Resource Access Manager (RAM) can share resources with the entire organization or specific OUs without needing individual account invitations.
Landing Zone Governance
high freqControl Tower sits on top of Organizations to provide a pre-built multi-account landing zone. It creates OUs (Security, Sandbox), provisions accounts via Account Factory, and enforces guardrails implemented as SCPs and AWS Config Rules. Organizations is the required foundation.
Multi-Account Config Aggregator
high freqEnable AWS Config with Trusted Access in Organizations to create an organization-level aggregator that pulls Config data from all member accounts and regions into a single view. Eliminates the need to manually authorize each account.
Centralized Security Findings
high freqDesignate a Security Hub delegated administrator account. Security Hub automatically aggregates findings from all org accounts. New accounts are auto-enrolled. This is the canonical pattern for enterprise security posture management.
SCP + IAM Permission Boundary
high freqSCPs set the maximum permissions boundary for all IAM principals in member accounts. IAM policies then grant permissions within that SCP boundary. Effective permissions = intersection of SCP allowances AND IAM policy grants.
StackSets SERVICE_MANAGED Deployment
high freqCloudFormation StackSets with SERVICE_MANAGED deployment type uses Organizations to automatically deploy stacks to all existing and future accounts in a target OU. No manual account list needed.
Organization-Wide Resource Sharing
high freqAWS Resource Access Manager (RAM) can share resources (Transit Gateways, Subnets, License Manager configs, etc.) with the entire organization or specific OUs. Members automatically receive shares without needing individual invitations.
Centralized Threat Detection
high freqDesignate a GuardDuty delegated administrator. GuardDuty auto-enables on all existing and new member accounts. Findings are aggregated centrally. Prevents member accounts from disabling GuardDuty.
Central Product Portfolio Distribution
high freqShare Service Catalog portfolios across the organization so member accounts can self-serve approved infrastructure patterns. Ensures compliance with pre-approved architectures.
Centralized Backup Governance
high freqUse Organizations Backup Policies to deploy AWS Backup plans across all accounts and regions from a central location. Combined with Backup Vault Lock for immutable backups.
Centralized SSO and Permission Sets
high freqIAM Identity Center (formerly SSO) integrates with Organizations to provide a single sign-on portal for all member accounts. Permission Sets are assigned to users/groups per account, replacing individual IAM users in each account.
SCPs NEVER apply to the management (master) account — not even a Deny All SCP attached to the root will restrict the management account. Always design with this blind spot in mind and protect the management account separately.
SCPs are permission GUARDRAILS, not grants. An SCP with Allow does NOT grant permissions — it only defines the maximum boundary. An IAM policy must still explicitly grant the permission within that boundary. Effective permissions = SCP Allow ∩ IAM Policy Allow.
The default FullAWSAccess SCP is automatically attached to every entity (root, OU, account) when you enable SCPs. If you remove it without adding explicit Allows, you DENY everything in that account. This is the most common accidental lockout pattern.
Member account limit is 1,200 (not 1,000). The default quota for new organizations is much lower (often 10 accounts) and requires a Service Quotas increase request. Exam questions that say '1,000 account limit' are testing this exact trap.
SCPs NEVER apply to the management account — even a root-level Deny All SCP leaves the management account unrestricted. This is the #1 tested SCP behavior.
SCPs are guardrails (max boundary), NOT grants. An SCP Allow does nothing without a corresponding IAM policy grant. Effective permissions = SCP ∩ IAM.
Max member accounts = 1,200 (not 1,000). Default quota for new orgs is much lower and requires a Service Quotas increase. Any answer option stating 1,000 as the maximum is the trap.
When a member account leaves or is removed from an organization, it loses access to the management account's consolidated billing and any SCPs stop applying immediately. The account reverts to standalone status and needs its own payment method.
Delegated Administrator accounts can perform most administrative tasks for supported services (GuardDuty, Security Hub, Config, etc.) WITHOUT needing access to the management account. This is the recommended security pattern — keep the management account locked down.
All Features mode vs Consolidated Billing mode: SCPs, Tag Policies, Backup Policies, and AI Opt-Out Policies ONLY work in All Features mode. Once you switch to All Features, you cannot revert to Consolidated Billing only mode.
CloudFormation StackSets with SERVICE_MANAGED deployment automatically deploys to new accounts added to a target OU — you don't need to update the StackSet. This is the exam answer for 'automatically deploy infrastructure to new accounts'.
Reserved Instances and Savings Plans are shared across ALL accounts in an organization by default for billing purposes. You can disable this sharing per-account in the Billing console. This is a key cost optimization pattern tested in SAA-C03.
Tag Policies in Organizations do NOT prevent non-compliant tagging by default — they report non-compliance via AWS Config. To enforce tags, you need an SCP that denies resource creation without required tags, OR enable enforcement mode in Tag Policies.
For the SCS-C02 exam: Use an SCP deny list strategy (attach FullAWSAccess then add explicit Denies) for most use cases. Use an allow list strategy (remove FullAWSAccess, add explicit Allows) when you need maximum restriction — but this is harder to maintain.
An account can only belong to ONE organization at a time. To move an account between organizations, it must first leave or be removed from the current org, then be invited to the new one.
Common Mistake
The maximum number of AWS accounts in an organization is 1,000.
Correct
The actual maximum is 1,200 accounts per organization (after quota increases). The default for new organizations is much lower and requires a Service Quotas increase request.
Older AWS documentation, third-party study guides, and practice exams used 1,000 as the limit. AWS increased this to 1,200 and it now appears directly in certification exams. If you see '1,000' as an answer choice, it is the trap.
Common Mistake
SCPs grant permissions to IAM principals in member accounts — attaching an SCP with Allow actions gives users those permissions.
Correct
SCPs only define the MAXIMUM permission boundary — they never grant permissions. An IAM policy (identity or resource-based) must independently grant the permission. Effective access = what the SCP allows AND what IAM grants.
This is the #1 SCP misunderstanding. A common exam scenario: 'Why can't the user in the member account perform action X even though the SCP allows it?' — Answer: Because no IAM policy grants it. SCPs are guardrails, not grants.
Common Mistake
SCPs apply to all accounts in the organization, including the management (master) account.
Correct
SCPs explicitly DO NOT apply to the management account. Even a Deny * SCP attached to the root will not restrict users or roles in the management account. This is by design but is a critical security gap.
Exam questions will describe a scenario where an SCP should block an action, but the action is being performed from the management account. The SCP has no effect there. This is also why AWS recommends using the management account only for organizational tasks, not workloads.
Common Mistake
Removing the FullAWSAccess SCP from an OU and replacing it with a more restrictive SCP is safe because the new SCP will allow the needed actions.
Correct
If you remove FullAWSAccess and your new SCP does not explicitly Allow an action, that action is IMPLICITLY DENIED for all accounts in that OU — even if IAM policies grant it. Always test SCP changes in a non-production OU first.
The implicit deny at the SCP layer overrides any IAM grant. This is how accidental lockouts happen. The FullAWSAccess SCP is a safety net — removing it is a high-risk operation.
Common Mistake
Confusing AWS Backup Vault Lock with S3 Object Lock for backup immutability at the organizational level.
Correct
For immutable backups managed centrally across an organization, the correct solution is AWS Backup Vault Lock (WORM protection on Backup Vaults) combined with Organizations Backup Policies — NOT S3 Object Lock, which is specific to S3 objects.
Exam questions about 'preventing backup deletion across all accounts in an organization' point to Backup Vault Lock + Organizations Backup Policies. S3 Object Lock only protects S3 objects and cannot be centrally enforced via Organizations policies.
Common Mistake
An SCP attached to a parent OU automatically restricts service-linked roles and AWS service actions in member accounts.
Correct
SCPs do NOT apply to service-linked roles. Service-linked roles are exempt from SCPs because they are required for AWS services to function. Restricting them via SCP would break those services.
This is a subtle but tested distinction. If an exam question asks why an SCP isn't blocking an action performed by a service-linked role (e.g., RDS creating snapshots), the answer is that SCPs don't apply to service-linked roles.
Common Mistake
You can use AWS Organizations to directly control resource-level permissions (e.g., which S3 buckets a member account can access).
Correct
SCPs control WHAT ACTIONS IAM principals can perform, not which specific resources they can access. Resource-level control still requires IAM policies, resource-based policies, or AWS RAM. SCPs operate at the action/service level, not the resource ARN level (though you can include resource conditions in SCPs).
Organizations is a governance layer, not a resource access control layer. Confusing these leads to incorrect architecture designs on exam scenario questions.
SCP = 'Security Ceiling Policy' — it sets the CEILING of what's allowed, never the floor. IAM policies build UP from the floor, SCPs push DOWN from the ceiling.
ROME = Root → OU → Member → Effective permissions. The hierarchy flows top-down, and each level can only restrict, never expand, what the level above allows.
Management account = 'The Untouchable' — SCPs, no matter how restrictive, never touch the management account. Treat it like the nuclear launch codes — lock it down manually.
1-1-5 Rule: 1 Root, 1 Org per account, 5 levels deep for OUs.
FREE = Foundational, Root-based, Enables-consolidation, Everyone-gets-it — Organizations costs nothing but enables everything.
CertAI Tutor · SAP-C02, SAA-C03, DOP-C02, SCS-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns