SCP evaluation - AWS Organizations

SCP evaluation

Note

The information in this section does not apply to management policy types, including backup policies, tag policies, chatbot policies, or AI services opt-out 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.

Organizational structure diagram showing Root, OU, and Member accounts with SCP permissions.

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

Organizational structure with Root, OUs, and member accounts showing SCP allow and deny actions.

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.

Organizational structure showing Root, OUs, and member accounts with SCP permissions.

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 Deny statements 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.

Organizational structure diagram showing Root, OUs, and member accounts in a hierarchical layout.

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 EC2 access Allow EC2 access Allow EC2 access Allow EC2 access
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