SCP evaluation

Note

The information in this section does not apply to management policy types, including AI services opt-out policies, backup policies, or tag policies. For more information, see Understanding management policy inheritance.

As you can attach multiple service control policies (SCPs) at different levels in AWS Organizations, understanding how SCPs are evaluated can help you write SCPs that yield the right outcome.

How SCPs work with Allow

For a permission to be allowed for a specific account, there must be an explicit Allow statement at every level from the root through each OU in the direct path to the account (including the target account itself). This is why when you enable SCPs, AWS Organizations attaches an AWS managed SCP policy named FullAWSAccess which allows all services and actions. If this policy is removed and not replaced at any level of the organization, all OUs and accounts under that level would be blocked from taking any actions.

For example, let's walk through the scenario shown in figures 1 and 2. For a permission or a service to be allowed at Account B, a SCP that allows the permission or service should be attached to Root, the Production OU, and to Account B itself.

SCP evaluation follows a deny-by-default model, meaning that any permissions not explicitly allowed in the SCPs are denied. If an allow statement is not present in the SCPs at any of the levels such as Root, Production OU or Account B, the access is denied.

Notes

• An Allow statement in an SCP permits the Resource element to only have a "*" entry.

• An Allow statement in an SCP can't have a Condition element at all.

Figure 1: Example organization structure with an Allow statement attached at Root, Production OU and Account B

Figure 2: Example organization structure with an Allow statement missing at Production OU and its impact on Account B

How SCPs work with Deny

For a permission to be denied for a specific account, any SCP from the root through each OU in the direct path to the account (including the target account itself) can deny that permission.

For example, let’s say there is an SCP attached to the Production OU that has an explicit Deny statement specified for a given service. There also happens to be another SCP attached to Root and to Account B that explicitly allows access to that same service, as shown in Figure 3. As a result, both Account A and Account B will be denied access to the service as a deny policy attached to any level in the organization is evaluated for all the OUs and member accounts underneath it.

Figure 3: Example organization structure with an Deny statement attached at Production OU and its impact on Account B

Strategy for using SCPs

While writing SCPs you can make use of a combination of Allow and Deny statements to allow intended actions and services in your organization. Deny statements are a powerful way to implement restrictions that should be true for a broader part of your organization or OUs because when they are applied at the root or the OU level they affect all the accounts under it.

For example, you can implement a policy using to Prevent member accounts from leaving the organization at the root level, which will be effective for all the accounts in the organization. Deny statements also support condition element which can be helpful to create exceptions.

Tip

You can use service last accessed data in IAM to update your SCPs to restrict access to only the AWS services that you need. For more information, see Viewing Organizations Service Last Accessed Data for Organizations in the IAM User Guide.

AWS Organizations attaches an AWS managed SCP named FullAWSAccess to every root, OU and account when it's created. This policy allows all services and actions. You can replace FullAWSAccess with a policy allowing only a set of services so that new AWS services are not allowed unless they are explicitly allowed by updating SCPs. For example, if your organization wants to only allow the use of a subset of services in your environment, you can use an Allow statement to only allow specific services.

{
"Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        }
    ]
}

A policy combining the two statements might look like the following example, which prevents member accounts from leaving the organization and allows use of desired AWS services. The organization administrator can detach the FullAWSAccess policy and attach this one instead.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny", 
            "Action":"organizations:LeaveOrganization",
            "Resource": "*" 
        }
    ]
}

Now, consider the following sample organization structure to understand how you can apply multiple SCPs at different levels in an organization.

The following table shows the effective policies in the Sandbox OU.

Scenario	SCP at Root	SCP at Sandbox OU	SCP at Account A	Resultant policy at Account A	Resultant policy at Account B and Account C
1	Full AWS access	Full AWS access + deny S3 access	Full AWS access + deny EC2 access	No S3, no EC2 access	No S3 access
2	Full AWS access	Allow Amazon Elastic Compute Cloud (Amazon EC2) access	Allow EC2 access	Allows EC2 access only	Allows EC2 access only
3	Deny S3 access	Allow S3 access	Full AWS access	No service access	No service access

The following table shows the effective policies in the Workloads OU.

Scenario	SCP at Root	SCP at Workloads OU	SCP at Test OU	Resultant policy at Account D	Resultant policies at Production OU, Account E and Account F
1	Full AWS access	Full AWS access	Full AWS access + deny EC2 access	No EC2 access	Full AWS access
2	Full AWS access	Full AWS access	Allow EC2 access	Allow EC2 access	Full AWS access
3	Deny S3 access	Full AWS access	Allow S3 access	No service access	No service access