Service Control Policies and AWS Organizations

Service Control Policies (SCPs) are a type of policy that you can use to manage permissions in your AWS Organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. They are not a substitute for IAM policies; rather, they are a boundary that defines what actions an account's IAM users, roles, and services can perform.

SCPs are applied at the organization, organizational unit (OU), or account level. They are inherited by all child entities. For example, if you attach an SCP to an OU, all accounts in that OU are affected. You can also attach SCPs directly to individual accounts.

SCPs operate by specifying a list of AWS services, actions, and conditions that are allowed or denied. The effective permissions for an IAM principal (user or role) in a member account are the intersection of the SCPs that apply to the account and the IAM policies that apply to the principal. In other words, an action is permitted only if it is allowed by BOTH the SCP AND the IAM policy. If either denies it, the action is denied.

SCPs use a similar syntax to IAM policies but with some key differences. They do not grant permissions; they only define a policy boundary. There are two types of SCPs: aws:SourceOrgID and aws:SourceOrgPath conditions can be used in SCPs to restrict access based on the organization.

To create and attach SCPs, you use the AWS Organizations console, AWS CLI, or SDK. Here is an example of an SCP that denies the ability to delete CloudTrail trails:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "cloudtrail:DeleteTrail",
      "Resource": "*"
    }
  ]
}

To attach this SCP to an OU using the CLI:

aws organizations attach-policy --policy-id p-examplepolicyid --target-id ou-exampleouid

To verify the effective permissions, you can use the IAM policy simulator or the organizations list-policies-for-target command:

aws organizations list-policies-for-target --target-id ou-exampleouid --filter SERVICE_CONTROL_POLICY

SCPs do not affect resource-based policies (like S3 bucket policies) directly. However, they can restrict the actions that a principal can perform, which indirectly affects what they can do through resource-based policies. For example, if an SCP denies s3:PutObject, even if a bucket policy allows it, the principal cannot upload objects because the SCP overrides.

SCPs also do not affect the management account by default. The management account is exempt from SCPs unless you explicitly enable them by attaching an SCP to the root. This is a common exam trap: SCPs apply to member accounts, not the management account, unless configured otherwise.

Both SCPs and IAM permissions boundaries define the maximum permissions for a principal, but they operate at different levels. SCPs apply to all principals in an account, while permissions boundaries apply to a specific IAM user or role. They can be used together: the effective permissions are the intersection of the SCP, the permissions boundary, and the IAM policy.

If an action is unexpectedly denied, check the following:

SCPs are a powerful tool for enforcing security guardrails across multiple accounts. They are not a replacement for IAM but a complement. On the exam, remember that SCPs set a maximum boundary, they are inherited, and they do not apply to the management account by default. Master the evaluation order: SCPs -> IAM permissions boundaries -> IAM policies -> Resource-based policies.

A large bank uses AWS Organizations to manage over 200 accounts across development, test, and production environments. The compliance team requires that no account can disable CloudTrail logging or delete logs. They create an SCP that denies cloudtrail:DeleteTrail, cloudtrail:StopLogging, and cloudtrail:UpdateTrail for all accounts except the management account. This SCP is attached to the root, ensuring it applies to all accounts. Additionally, they create an SCP that denies ec2:RunInstances unless the instance is launched with a specific KMS key for encryption. This ensures all EC2 volumes are encrypted at rest. The bank uses AWS Config to monitor for non-compliant resources and remediates automatically using Lambda functions. One challenge they faced was that the SCPs also affected the management account when attached to the root, causing some administrative tasks to fail. They resolved this by detaching the SCP from the root and attaching it only to OUs containing member accounts.

A SaaS company offers a platform where each customer gets a separate AWS account for isolation. They use AWS Organizations to manage hundreds of customer accounts. To prevent customers from modifying their own billing or leaving the organization, they attach an SCP that denies organizations:LeaveOrganization and aws-portal:ModifyAccount to all accounts. They also restrict the regions where customers can deploy resources to US East (N. Virginia) and US West (Oregon) using a condition in the SCP: "Condition": { "StringEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] } }. This ensures data residency compliance. However, they discovered that some customers needed to use services not available in those regions, such as AWS GovCloud. They created a separate OU for those customers with a more permissive SCP. The company uses AWS CloudFormation StackSets to deploy baseline IAM roles and resources across all accounts, but SCPs prevent customers from deleting these resources. A common misconfiguration was attaching SCPs that accidentally blocked essential services like AWS CloudFormation itself, causing stack operations to fail. They now maintain a whitelist of allowed services in the SCP to avoid such issues.

SCPs are evaluated at the time of API call and add minimal latency (typically <10ms). However, with hundreds of accounts and complex policies, the evaluation can become slower. It is best practice to keep SCPs concise and avoid overly complex conditions. Also, note that SCPs are eventually consistent; changes may take a few seconds to propagate across all accounts. During this window, there is a risk of temporary policy mismatch. To mitigate, apply changes during maintenance windows and use the organizations describe-policy command to verify propagation.