AWS Organizations and Service Control Policies (SCPs) – Complete Guide
Why AWS Organizations and SCPs Matter
AWS Organizations and Service Control Policies (SCPs) are foundational topics for the AWS Security Specialty exam. They represent the highest level of access governance in an AWS environment and are critical to understanding how enterprises enforce security boundaries across multiple AWS accounts. Without a solid understanding of Organizations and SCPs, you cannot properly answer questions about multi-account security strategy, permission boundaries, and centralized governance — all of which are heavily tested.
What Are AWS Organizations?
AWS Organizations is a service that allows you to centrally manage and govern multiple AWS accounts. It provides:
• Consolidated Billing: All member accounts roll up billing to a single management (formerly called master) account, simplifying cost tracking.
• Organizational Units (OUs): Logical groupings of accounts that allow hierarchical structuring of your organization (e.g., Production OU, Development OU, Security OU).
• Service Control Policies (SCPs): Centralized permission guardrails that apply to all accounts within the organization or specific OUs.
• Account Management: The ability to programmatically create new AWS accounts and invite existing ones into the organization.
The account that creates the organization is called the management account (previously the master account). This account has special privileges and is not affected by SCPs.
Key Concepts of AWS Organizations
• Root: The top-level container in your organizational hierarchy. All OUs and accounts exist under the root.
• Organizational Units (OUs): Containers within the root that can hold accounts and other OUs, allowing nested hierarchies up to 5 levels deep.
• Management Account: The account that created the organization. It has full administrative control and is never restricted by SCPs.
• Member Accounts: All other accounts in the organization. These accounts are subject to SCPs.
• Features: Organizations can operate in consolidated billing only mode or all features mode. SCPs require all features mode to be enabled.
What Are Service Control Policies (SCPs)?
SCPs are a type of organization policy that defines the maximum available permissions for IAM entities (users and roles) in member accounts. They act as permission guardrails — they do not grant permissions themselves but instead set the boundaries within which IAM policies can operate.
How SCPs Work
1. SCPs Are Permission Boundaries: An SCP defines what actions are allowed or denied at the account level. Even if an IAM policy within an account grants a permission, the action will be denied if the SCP does not allow it. Think of SCPs as a filter — actions must pass through both the SCP and the IAM policy to be effective.
2. SCPs Use the Same JSON Policy Language as IAM: SCPs support Effect, Action, Resource, and Condition elements, just like IAM policies. However, SCPs do not support all IAM policy features (for example, they do not support resource-based policy grants across accounts).
3. Deny List vs. Allow List Strategy:
• Deny List (Default): By default, AWS Organizations attaches a FullAWSAccess SCP to the root, every OU, and every account. This means everything is allowed by default. You then attach additional SCPs that explicitly deny specific actions. This is the most common and recommended approach.
• Allow List: You remove the FullAWSAccess SCP and only attach SCPs that explicitly allow specific services. This is more restrictive but more complex to manage. Any service not explicitly allowed is implicitly denied.
4. Inheritance: SCPs are inherited down the organizational hierarchy. If you attach an SCP to the root, it applies to all OUs and accounts. If you attach it to a specific OU, it applies to all accounts within that OU and any child OUs. The effective permissions for an account are the intersection of all SCPs applied at every level from the root down to the account.
5. SCPs Do Not Affect the Management Account: This is a critical exam point. The management account is never affected by SCPs, regardless of where the SCP is attached. This is why the management account should be used sparingly and protected with additional controls.
6. SCPs Do Not Affect Service-Linked Roles: Service-linked roles are not restricted by SCPs. This means AWS services that use service-linked roles can continue to operate even if an SCP would otherwise block the action.
7. SCPs Affect Only IAM Principals in Member Accounts: They do not affect resource-based policies directly. For example, if an S3 bucket policy in Account A grants access to a user in Account B, and Account B has an SCP that denies S3 access, the user in Account B will be denied. However, if Account A's bucket policy grants access to an external entity, the SCP in Account A does not apply to that external entity's request (though it would apply to any IAM principal in Account A).
How SCPs Interact with IAM Policies
For an action to be allowed, it must be permitted by:
• The SCP at every level of the hierarchy (root → OU → account)
• The IAM identity-based policy attached to the user or role
• Any applicable resource-based policy (in some cross-account scenarios)
• Any applicable permissions boundary
If any of these denies the action or fails to allow it, the action is denied. This is the intersection model of permissions evaluation.
Common SCP Use Cases
• Preventing accounts from leaving the organization: Deny the organizations:LeaveOrganization action.
• Restricting regions: Deny all actions except in approved AWS regions using the aws:RequestedRegion condition key.
• Preventing disabling of security services: Deny actions like guardduty:DeleteDetector, config:StopConfigurationRecorder, cloudtrail:StopLogging, or securityhub:DisableSecurityHub.
• Preventing root user activity: Deny all actions for the root user in member accounts using the aws:PrincipalArn condition.
• Enforcing encryption: Deny S3 PutObject unless server-side encryption is enabled.
• Restricting instance types: Deny EC2 RunInstances unless specific instance families are used.
• Preventing deletion of critical resources: Deny delete actions on specific resource types.
SCP Policy Structure Example
A deny-based SCP to restrict regions might look like this (conceptually):
The policy would have Effect: Deny, with a NotAction list for global services (like IAM, STS, Organizations, CloudFront) and a Condition using aws:RequestedRegion with a list of approved regions. The NotAction ensures that global services remain accessible while regional services are restricted.
Important Limitations of SCPs
• SCPs do not grant any permissions — they only restrict or allow the scope of permissions.
• SCPs do not apply to the management account.
• SCPs do not affect service-linked roles.
• SCPs have a maximum size of 5,120 characters.
• You can attach a maximum of 5 SCPs per OU or account.
• SCPs affect only member accounts' IAM principals, not external principals accessing resources via resource-based policies.
• SCPs do not apply to actions performed by AWS services on your behalf (service-linked roles).
AWS Organizations Trusted Access and Delegated Administration
• Trusted Access: Allows AWS services (like AWS Config, CloudTrail, GuardDuty, Security Hub) to perform actions across all accounts in the organization. This is enabled from the management account.
• Delegated Administrator: Allows you to designate a member account as a delegated administrator for specific AWS services, reducing the need to operate from the management account for day-to-day tasks.
Best Practices
• Use the deny list strategy (keep FullAWSAccess and add deny SCPs) for simpler management.
• Apply SCPs at the OU level rather than individual accounts for scalability.
• Protect the management account with strong controls since SCPs do not apply to it.
• Use SCPs to enforce preventive guardrails for compliance requirements.
• Test SCPs thoroughly before applying to production OUs — a misconfigured SCP can lock out entire accounts.
• Combine SCPs with IAM permissions boundaries for defense in depth.
Exam Tips: Answering Questions on AWS Organizations and SCPs
1. Remember that SCPs do NOT grant permissions: This is the most commonly tested concept. SCPs only define the ceiling of what is possible. You still need IAM policies to actually grant access. If a question asks how to give a user access to a service, attaching an SCP alone is never the answer.
2. Management account is immune to SCPs: If a question involves restricting the management account, SCPs will NOT work. You need other mechanisms like IAM policies directly on the management account or AWS Control Tower guardrails.
3. SCPs use an intersection model: The effective permission is the intersection of all SCPs from root to account AND the IAM policies. If any layer denies or doesn't allow, the action is denied. Questions may test this by presenting multiple SCP levels.
4. Service-linked roles are not affected: If a question asks why an AWS service can still perform an action despite an SCP deny, the answer is likely that the service uses a service-linked role.
5. Deny list vs. allow list: Know the difference. The default strategy is deny list (FullAWSAccess + explicit denies). Allow list requires removing FullAWSAccess and explicitly permitting services. Questions may describe a scenario where services are unexpectedly blocked — check if FullAWSAccess was removed.
6. Region restriction questions: When you see a question about limiting AWS usage to specific regions, think SCPs with the aws:RequestedRegion condition key. Remember to exclude global services using NotAction.
7. Preventing security service tampering: Questions about ensuring GuardDuty, CloudTrail, Config, or Security Hub cannot be disabled should point you toward SCPs with explicit deny on the relevant delete/stop/disable actions.
8. Root user in member accounts: SCPs CAN restrict the root user of member accounts (but NOT the root user of the management account). This is a common exam question.
9. Cross-account access: If a question involves cross-account access via resource-based policies, remember that SCPs apply to the requesting principal's account, not the resource's account. If Account B's SCP denies S3 access, a user in Account B cannot access S3 in Account A even if Account A's bucket policy allows it.
10. SCP size and limits: Be aware of the 5,120-character limit and 5 SCPs per target limit. If a scenario describes many fine-grained restrictions, consider whether consolidation or restructuring OUs might be the answer.
11. OU hierarchy matters: SCPs at every level must allow the action. A common trap is a scenario where an SCP at the root allows a service, but a child OU's SCP does not include it (in an allow list strategy), resulting in denial.
12. Preventive vs. Detective controls: SCPs are preventive controls. They stop actions before they happen. AWS Config rules and GuardDuty are detective controls. Know when a question is asking for prevention (SCP) vs. detection (Config, GuardDuty, CloudTrail).
13. Control Tower context: If a question mentions AWS Control Tower, know that it uses SCPs to implement preventive guardrails. Control Tower automates the setup of Organizations with best-practice multi-account structures.
14. Look for keywords: Questions mentioning 'centrally restrict,' 'prevent across all accounts,' 'enforce compliance organization-wide,' or 'guardrails' almost always involve SCPs.
15. Tag policies and other policy types: AWS Organizations supports multiple policy types (SCPs, tag policies, backup policies, AI services opt-out policies). Don't confuse them. Only SCPs control access permissions.
