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
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 theResource
element to only have a"*"
entry. -
An
Allow
statement in an SCP can't have aCondition
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 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 FullAWSAccessAllow
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 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 |