Service Control Policies and SCPs

Service Control Policies (SCPs) are a feature of AWS Organizations that enable you to centrally manage permissions across multiple AWS accounts. They are not a substitute for IAM policies; rather, they act as a guardrail that defines the maximum permissions that any principal (user, group, or role) in a member account can have. The core problem SCPs solve is the lack of centralized control in multi-account environments. Without SCPs, each account administrator can grant any permission to any user, potentially leading to security breaches or compliance violations. For example, a developer in a sandbox account could accidentally grant themselves full administrative access, which is risky in production. SCPs allow a central governance team to enforce policies like "No account can delete S3 buckets" or "Only approved services can be used."

SCPs are JSON policy documents that you attach to an AWS Organization root, an organizational unit (OU), or a specific member account. They affect all IAM users, groups, and roles within the target accounts, including the root user. However, SCPs do not grant permissions; they only define a filter. For an action to be allowed, both the SCP and the IAM policy must allow it (explicit allow). If either denies it, the action is denied. This is known as the "effective permissions" model: the intersection of the SCP and the IAM policy.

SCPs support two types of policies: - Allow lists: By default, all actions are denied. You explicitly list allowed actions. This is more restrictive and is commonly used for high-security environments. - Deny lists: By default, all actions are allowed. You explicitly list denied actions. This is more permissive and is typical for most organizations.

Key details:

SCPs are a feature of AWS Organizations, which is free of charge. However, you must enable all features in your organization to use SCPs. There is no additional cost for SCPs themselves. The only pricing consideration is the number of policies you create and the number of attachments, but these are within generous limits (up to 1,000 SCPs per organization, up to 15 policies per target).

In an on-premises environment, you might use Active Directory Group Policy Objects (GPOs) to enforce settings across computers. However, GPOs control operating system settings, not cloud API permissions. SCPs are more analogous to a centralized IAM governance layer. Competing cloud providers like Google Cloud have Organization Policies, which function similarly but use a different syntax. Azure has Azure Policy, which can enforce tags or resource types but also includes Azure RBAC for role assignments. SCPs are unique in that they apply to all principals in an account, including the root user.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser"
      ],
      "Resource": "*"
    }
  ]
}

This SCP denies the ability to create or delete IAM users in any account it is attached to.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:GetObject"
      ],
      "Resource": "*"
    }
  ]
}

This SCP only allows EC2 describe actions and S3 GetObject. Everything else is implicitly denied.