Service control policies - AWS Organizations

Service control policies

Service control policies (SCPs) are one type of policy that you can use to manage your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization’s access control guidelines. SCPs are available only in an organization that has all features enabled. SCPs aren't available if your organization has enabled only the consolidated billing features. For instructions on enabling SCPs, see Enabling and disabling SCPs.

SCPs alone are not sufficient for allowing access in the accounts in your organization. Attaching an SCP to an AWS Organizations entity (root, OU, or account) defines a guardrail for what actions the principals can perform. You still need to attach identity-based or resource-based policies to principals or resources in your organization's accounts to actually grant permissions to them. When a principal belongs to an account that is a member of an organization, the SCPs contribute to the principal's effective permissions.

Testing effects of SCPs

AWS strongly recommends that you don't attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key services. One way to determine whether a service is used by an account is to examine the service last accessed data in IAM. Another way is to use AWS CloudTrail to log service usage at the API level.

Maximum size of SCPs

All characters in your SCP count against its maximum size. The examples in this guide show the SCPs formatted with extra white space to improve their readability. However, to save space if your policy size approaches the maximum size, you can delete any white space, such as space characters and line breaks that are outside quotation marks.


Use the visual editor to build your SCP. It automatically removes extra white space.

Effects on permissions

SCPs are similar to IAM permission policies and use almost the same syntax. However, an SCP never grants permissions. Instead, SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU). For more information, see Policy Evaluation Logic in the IAM User Guide.

  • SCPs affect only principals that are managed by accounts that are part of the organization. SCPs don't affect resource-based policies directly. They also don't affect users or roles from accounts outside the organization. For example, consider an Amazon S3 bucket that's owned by account A in an organization. The bucket policy (a resource-based policy) grants access to users from accounts outside the organization. Account A has an SCP attached. That SCP doesn't apply to those outside users. It applies only to users that are managed by account A in the organization.

  • An SCP restricts permissions for principals in member accounts, including each AWS account root user. Any account has only those permissions permitted by every parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an Allow policy statement) or explicitly (by being included in a Deny policy statement), a user or role in the affected account can't use that permission, even if the account administrator attaches the AdministratorAccess IAM policy with */* permissions to the user.

  • Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access at all, even if the applicable SCPs allow all services and all actions.

  • If a user or role has an IAM permission policy that grants access to an action that is also allowed by the applicable SCPs, the user or role can perform that action.

  • If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action.

  • SCPs affect all users and roles in attached accounts, including the root user. The only exceptions are those described in Tasks and entities not restricted by SCPs.

  • SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.

  • When you disable the SCP policy type in a root, all SCPs are automatically detached from all AWS Organizations entities in that root. AWS Organizations entities include organizational units, organizations, and accounts. If you reenable SCPs in a root, that root reverts to only the default FullAWSAccess policy automatically attached to all entities in the root. Any attachments of SCPs to AWS Organizations entities from before SCPs were disabled are lost and aren't automatically recoverable, although you can manually reattach them.

  • If both a permissions boundary (an advanced IAM feature) and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action.

Using access data to improve SCPs

When signed in with master account credentials, you can view service last accessed data for an AWS Organizations entity or policy in the AWS Organizations section of the IAM console. You can also use the AWS CLI or AWS API in IAM to retrieve service last accessed data. This data includes information about which allowed services that principals in an AWS Organizations account last attempted to access and when. You can use this information to identify unnecessary permissions so that you can refine your SCPs to better adhere to the principle of least privilege.

For example, you might have a deny list SCP that prohibits access to three AWS services. All services that aren't listed in the SCP's Deny statement are allowed. The service last accessed data in IAM tells you which AWS services are allowed by the SCP but are never used. With that information, you can update the SCP to deny access to services that you don't need.

For more information, see the following pages in the IAM User Guide:

Tasks and entities not restricted by SCPs

The following tasks and AWS Organizations entities are not restricted by SCPs:

  • Actions performed by the master account.

  • Any action performed using permissions that are attached to a service-linked role.

  • Managing root credentials. No matter what SCPs are attached, the root user in an account can always do the following:

    • Changing the root user's password

    • Creating, updating, or deleting root access keys


      For some accounts created before 9/15/2017, this restriction doesn't apply. AWS recommends that you don't rely on this restriction for these accounts.

    • Enabling or disabling multi-factor authentication on the root user

    • Creating, updating, or deleting x.509 keys for the root user

  • Registering for the Enterprise support plan as the root user

  • Changing the AWS support level as the root user

  • Managing Amazon CloudFront keys

  • Trusted signer functionality for CloudFront private content

  • Modifying AWS account email allowance/reverse DNS

  • Performing tasks on some AWS-related services:

    • Alexa Top Sites

    • Alexa Web Information Service

    • Amazon Mechanical Turk

    • Amazon Product Marketing API