Service Control Policies (SCPs) are a powerful governance feature within AWS Organizations that enable centralized control over the maximum available permissions for all accounts in your organization. SCPs act as permission boundaries, defining guardrails that restrict what actions member accounts …Service Control Policies (SCPs) are a powerful governance feature within AWS Organizations that enable centralized control over the maximum available permissions for all accounts in your organization. SCPs act as permission boundaries, defining guardrails that restrict what actions member accounts can perform, even if IAM policies within those accounts would otherwise allow such actions.
SCPs operate at the organizational level and can be attached to the organization root, organizational units (OUs), or individual member accounts. They follow an inheritance model where policies attached to parent nodes affect all children beneath them. This hierarchical structure allows architects to implement tiered permission models across complex organizational structures.
Key characteristics of SCPs include:
1. **Deny by Default**: When SCPs are enabled, an implicit deny applies to all actions not explicitly allowed. You can use either allow lists (whitelisting permitted services) or deny lists (blacklisting prohibited actions).
2. **No Permission Granting**: SCPs do not grant permissions themselves. They only limit what permissions IAM policies can effectively provide. Users still need appropriate IAM policies to perform actions.
3. **Management Account Exception**: The management account (formerly master account) is not affected by SCPs, maintaining full administrative access regardless of applied policies.
4. **Service-Linked Roles**: SCPs do not restrict service-linked roles, ensuring AWS services can continue functioning properly.
Common use cases include preventing member accounts from leaving the organization, restricting access to specific AWS regions, enforcing encryption requirements, preventing the deletion of critical resources like CloudTrail logs, and limiting which EC2 instance types can be launched.
When designing solutions for organizational complexity, SCPs provide essential compliance and security controls. They complement IAM policies by establishing organization-wide boundaries that individual account administrators cannot override, ensuring consistent governance across hundreds or thousands of AWS accounts in enterprise environments.
Service Control Policies (SCPs) - Complete Guide for AWS Solutions Architect Professional
Why Service Control Policies (SCPs) Are Important
Service Control Policies are a critical governance mechanism in AWS Organizations that enable centralized control over the maximum available permissions for all accounts in your organization. For Solutions Architects, understanding SCPs is essential because they form the foundation of enterprise-wide security boundaries and compliance enforcement across multi-account AWS environments.
SCPs are particularly important because they: • Establish guardrails that cannot be overridden by individual account administrators • Enable compliance with regulatory requirements across all organizational accounts • Prevent accidental or intentional misconfigurations that could compromise security • Support the principle of least privilege at an organizational scale
What Are Service Control Policies?
SCPs are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. They help ensure your accounts stay within your organization's access control guidelines.
Key characteristics of SCPs: • SCPs are available only in organizations that have all features enabled • SCPs affect only IAM users and roles managed by accounts that are part of the organization • SCPs do NOT affect resource-based policies • SCPs do NOT grant permissions; they only set permission boundaries • SCPs affect all users and roles in attached accounts, including the root user • SCPs do NOT affect service-linked roles
How Service Control Policies Work
Permission Evaluation: When an IAM principal makes a request, AWS evaluates all applicable policies. For a permission to be granted, it must be allowed by: 1. The SCP attached to the account (or inherited from parent OUs) 2. The identity-based policy attached to the principal 3. Any applicable resource-based policies 4. Permission boundaries (if applicable)
Inheritance Model: SCPs use an inheritance model where policies attached to the organization root flow down to all organizational units (OUs) and accounts. Policies attached to an OU flow down to all child OUs and accounts within that OU. The effective permissions for an account are the intersection of all SCPs in the hierarchy from the root to the account.
SCP Strategies:
Deny List Strategy (Default): • Start with the AWS-managed FullAWSAccess policy attached • Add explicit deny statements for services or actions you want to restrict • Easier to implement and maintain • Best for organizations that want to restrict specific actions
Allow List Strategy: • Remove the FullAWSAccess policy • Explicitly allow only the services and actions needed • More restrictive and secure • Requires more maintenance as new services are added
Common SCP Use Cases
• Preventing accounts from leaving the organization • Restricting which AWS regions can be used • Preventing deletion of critical resources like CloudTrail logs • Enforcing encryption requirements • Restricting root user actions • Limiting which services can be used • Enforcing tagging requirements
Exam Tips: Answering Questions on Service Control Policies
Remember these key points:
1. SCPs do NOT grant permissions - They only define the maximum permissions boundary. A common exam trap is suggesting SCPs can be used to grant access.
2. SCPs affect the root user - Unlike IAM policies, SCPs apply to the root user of member accounts. However, SCPs do NOT affect the management account.
3. Management account exception - The management account is never affected by SCPs, even if an SCP is attached at the root level. This is a frequent exam topic.
4. Service-linked roles are exempt - SCPs do not restrict service-linked roles, which allow AWS services to perform actions on your behalf.
5. Intersection of permissions - When multiple SCPs apply, the effective permissions are the intersection (AND logic), not the union. All SCPs in the hierarchy must allow an action.
6. SCPs vs IAM Policies - If a question asks about restricting permissions across multiple accounts simultaneously, SCPs are typically the answer. For single-account restrictions, IAM policies or permission boundaries may be more appropriate.
7. Explicit Deny wins - An explicit deny in any SCP in the hierarchy will override any allow statements.
8. OU structure matters - Questions about applying different restrictions to different groups of accounts point toward using OUs with different SCPs attached.
9. Resource-based policies - Remember that SCPs do not affect resource-based policies. If a question involves cross-account access via resource-based policies, the SCP must allow the action for the principal making the request.
10. Consolidated Billing vs All Features - SCPs require All Features to be enabled in AWS Organizations. Questions mentioning only Consolidated Billing indicate SCPs cannot be used.
Common Exam Scenarios: • Preventing specific regions from being used organization-wide: Use SCP with region condition keys • Ensuring CloudTrail cannot be disabled: Use SCP to deny cloudtrail:StopLogging and cloudtrail:DeleteTrail • Restricting which EC2 instance types can be launched: Use SCP with condition keys for instance types • Preventing member accounts from leaving: Use SCP to deny organizations:LeaveOrganization