Before we begin, we should talk about what SCPs are and how they apply to your organization.

An SCP consists of a policy document that defines (by way of filtering) the services and actions that can be used and performed within an OU or in an AWS account.

If you've previously configured an IAM policy, then you will have more than enough background knowledge to get started with SCPs. Apart from a couple of minor exceptions, they look exactly the same.

SCPs can be applied at different levels throughout an organization. The following are the levels, starting from the bottom and going up:

• AWS account level: An SCP that's applied to an AWS account takes effect on only that account. It's important to note that the SCP is very separate from the IAM policies that live inside the account. For example, an SCP might allow full access to S3 for an AWS account but the IAM policies inside the account may deny it (for certain roles and/or users).
• OU level: An SCP that's applied at the OU level will apply to all the AWS accounts that live inside the OU, as well as any child OUs (remember that an OU can be a member of an OU).
• Root level: If an SCP is applied at this level, it will apply to all the AWS accounts inside the organization.

Things can start to get really interesting when you have an SCP applied at multiple levels. The intersection of the policies at the root, OU, account, and IAM levels is evaluated and will determine whether or not an API call is allowed to be made. For example, someone belonging to an IAM role that has full administrator access to an account still won't be able to call any EC2 APIs if any of the SCPs above it (account, OU, or root) deny EC2 access.

In the following example, we have a top-level OU, Austero Bluth, with an SCP that allows access to all AWS resources for all OUs and accounts underneath it:

Austero Bluth has two child OUs; let's focus on Sudden Valley. It has an SCP that allows only EC2 and S3. By using a whitelisting approach, anything except these two services will be denied. Remembering that SCPs act like a filter, any OU or AWS accounts living underneath the Sudden Valley OU will, at most, have access to EC2 and S3.

The Sitwell Enterprises Account also has an SCP attached to it. This particular SCP allows S3 and SQS. Note that the SQS statement will have no effect here because the Sitwell account is inside an OU that does not allow SQS. Also, note that this account has no access to EC2, despite the Sudden Valley OU allowing it; this is because EC2 wasn't explicitly allowed in the SCP attached to the account.

At the IAM level, we have a role in the Sitwell AWS account that allows full administrator privileges. However, because the intersection of the SCPs governing this account will only allow S3, anyone using this role will be denied access if they attempt to use EC2 or SQS, for example.

Let's also take a look at the Bluth Company Account. The SCP that is attached to it allows full AWS access; however, it lives inside an OU (Balboa Bay) that only allows EC2, RDS, and S3. There is an IAM role inside this account that also allows full admin access but, again, administrators in this account will be limited to EC2, RDS, and S3.