Enabling Service Control Policies to Scope Account Permissions

Welcome back! In this lesson, we dive deeper into Service Control Policies (SCPs) and their role in managing permissions across multiple accounts within AWS Organizations. Previously, we covered permission boundaries for scoping account permissions. Now, let’s explore how SCPs function as essential guardrails to enforce compliance and governance.

SCPs are a core feature of AWS Organizations designed to manage permissions across your entire organization, individual organizational units (OUs), or specific accounts. It is important to know that SCPs do not grant permissions by themselves. Instead, they serve as limits on the maximum set of permissions that can be granted through identity-based or resource-based policies.

In the screenshot above, notice the display of AI services, backup, and tag policies. Although our focus is on SCPs, be aware that additional policies—such as backup and tag policies—are also important and may appear in certification exams.

Before SCPs take effect, they must be explicitly enabled within your organization. If you are using AWS Control Tower, SCPs are enabled by default.

Consider these important points:

• SCPs set the maximum permissions allowed within an account—they don't grant any permissions.
• If both an identity-based policy and an SCP permit an action, the user can perform that action.
• If an SCP denies an action, that denial takes precedence, even if IAM or resource-based policies grant access.
• SCPs apply only to IAM users and roles within the organization; they do not affect resource-based policies or policies for accounts outside the organization.
• SCPs can restrict actions for the root user, which is not a characteristic of standard IAM policies.

Every IAM user or role within your organization will only be able to execute actions if those actions are allowed by SCPs and subsequently granted by their individual policies. If an IAM user or role does not have any policies attached, no access is permitted—even if the SCP may allow specific actions.

Additionally, SCPs do not impact service-linked roles or resource-based policies. Their influence is limited exclusively to identity-based policies within your AWS Organization.

Components of an SCP

An SCP is written in JSON, very similar to IAM policies. Consider the example below, which explicitly denies access to EC2 and S3 actions on all resources unless the request originates from the "us-west-2" region (Oregon):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",  // Denies specific actions for all resources if not in the specified region
      "Action": [
        "ec2:*",  // Denies all EC2 actions
        "s3:*"    // Denies all S3 actions
      ],
      "Resource": "*",  // Applies to all resources
      "Condition": {    // Specifies conditions to enforce the restriction
        "StringNotEquals": {
          "aws:RequestedRegion": "us-west-2" // Denies actions if not in the "us-west-2" region
        }
      }
    }
  ]
}

In this example, the condition restricts EC2 and S3 actions to only the "us-west-2" region. If the condition is not met, access to these services is denied.

By design, SCPs require explicit allow statements to enable access to particular services. An SCP that grants broad permissions can enable various actions, but if no explicit allow statement exists, the default behavior is to deny access. Similarly, an explicit deny statement within an SCP overrides any permissions granted through identity-based policies.

Be cautious when implementing SCPs. Removing an SCP that granted broad permissions without having another explicit allow statement can result in a state where no actions are permitted. For example, if you deny all access to machine learning services through an SCP, no identity-based policy can override that denial.

Summary of Key Points

SCPs in AWS Organizations are a powerful way to enforce permission boundaries across your environment. They ensure that member accounts can only perform actions explicitly allowed by both the SCPs and attached identity-based policies.

Thank you for reading this lesson on Service Control Policies. Use this guidance to enhance your understanding of managing permissions and improving governance across your AWS Organization.

For further information, explore:

• AWS Organizations Documentation
• Understanding AWS Service Control Policies