AWS Service Control Policies (SCPs) Explained with Examples

What are AWS Service Control Policies (simple explanation)

SCPs are policies you attach to your organization root, to organizational units (OUs), or to individual accounts. They define the ceiling. IAM policies grant permissions within that ceiling. If an SCP blocks an action, no IAM policy in that account can override it.

One critical detail: SCPs do not apply to the management account. The management account always has full permissions. This is why best practice is to use the management account only for organization administration and billing, never for workloads.

Why SCPs matter

IAM policies can be created, modified, and deleted by anyone with the right IAM permissions inside an account. If someone has AdministratorAccess, they can change any IAM policy. This means IAM alone cannot enforce organization-wide rules because the people you are trying to restrict can change the restrictions.

SCPs solve this. They are managed exclusively by the management account. No one inside a member account can view, modify, or remove the SCPs applied to their account. This makes SCPs the enforcement layer for non-negotiable security requirements:

• CloudTrail logging must always be enabled.
• Resources must only be created in approved regions.
• Member accounts must not leave the organization.
• Certain security roles must not be modified.

Without SCPs, you are relying on trust and correct IAM configuration across every account. With SCPs, you have hard guardrails that hold even if an account administrator makes a mistake or acts maliciously.

How SCPs work in AWS Organizations

SCPs require AWS Organizations with “all features” enabled. Consolidated-billing-only organizations do not support SCPs.

SCPs work through intersection. For a principal in a member account to perform an action, all of the following must be true:

1. Every SCP in the chain from the organization root down to the account must allow the action (or at least not deny it).
2. The principal’s IAM policy must grant the action.
3. No explicit Deny in any SCP or IAM policy blocks the action.

If any SCP in the hierarchy denies the action, or if the SCP chain does not include an Allow for the action (in an allow-list model), the request is denied regardless of IAM permissions.

Where SCPs are applied (Root, OU, Account)

SCPs flow down the organization hierarchy. A principal in an account must satisfy all SCPs on the path from the Root to their account:

• Root-level SCPs apply to every member account in the organization.
• OU-level SCPs apply to all accounts and child OUs within that OU.
• Account-level SCPs apply to that specific account only.

SCPs are cumulative through inheritance. If the Root has one SCP and a child OU has another, accounts in that OU must satisfy both. You can attach up to 5 SCPs per target, with a combined policy size limit.

SCPs vs IAM policies vs permissions boundaries

These three policy types serve different purposes. Understanding where each one applies prevents confusion when troubleshooting access issues.

SCPs and permissions boundaries are both “ceiling” mechanisms, but at different levels. An SCP is the ceiling for the entire account. A permissions boundary is the ceiling for one specific role or user. Both follow the principle of least privilege, just at different scales.

When to use SCPs

SCPs are the right tool when you need to enforce rules that account administrators cannot override. Common use cases:

• Region and data residency restrictions. Block resource creation outside approved regions. If your compliance requirements say data must stay in eu-west-1, an SCP with an aws:RequestedRegion condition enforces this at the organization level. See Restricting Resource Locations in AWS for the full pattern.

• Preventing risky IAM changes. Protect security-critical roles from modification. If your security team deploys a baseline role into every account, an SCP can prevent anyone in those accounts from deleting or modifying it.

• Protecting logging and security baselines. Deny actions like cloudtrail:StopLogging or guardduty:DeleteDetector so no account can disable audit logging.

• Restricting sandbox accounts to approved services. In sandbox or experimentation OUs, use an allow-list SCP to limit which services are available. Developers can experiment freely within approved services but cannot spin up expensive or unapproved resources.

• Stopping member accounts from leaving the organization. Deny organizations:LeaveOrganization across all member accounts. This prevents a compromised or rogue account from detaching itself from your governance controls.

How to roll out SCPs safely

A misconfigured SCP can lock teams out of their accounts. Follow this approach to avoid outages:

1. Test in a sandbox OU first. Create a dedicated test OU with a non-production account. Apply your new SCP there. Verify that the intended actions are blocked and that everything else still works. Do not skip this step.

2. Start narrow, then expand. Apply the SCP to one OU at a time. Confirm there are no issues before applying it to additional OUs. Rolling out to the entire organization at once is risky.

3. Be careful with allow-list models. If you remove FullAWSAccess and replace it with an explicit allow list, anything you forget to include is denied. This approach is powerful for sandbox accounts but dangerous if you miss services your teams depend on (CloudWatch, IAM, STS are commonly forgotten).

4. Communicate before applying. Let teams know an SCP change is coming. Give them a heads-up about what will be restricted so they can verify their workflows will not break.

5. Use deny-list SCPs for broad restrictions. For most organizations, keeping FullAWSAccess and adding targeted Deny statements is safer and easier to maintain than allow-listing.

Real SCP examples

Deny all actions outside approved regions

This SCP prevents any principal in the account from making API calls to regions outside your approved list. Use this for data residency, compliance, or cost control. The aws:RequestedRegion condition key checks the target region of each request.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
        }
      }
    }
  ]
}

When to use: Compliance requires data to stay in specific geographic regions, or you want to prevent accidental resource creation in regions your team does not monitor.

Prevent member accounts from leaving the organization

This SCP blocks the organizations:LeaveOrganization action. Without it, the root user of a member account could remove the account from your organization, escaping all SCP controls.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

When to use: Always. This should be one of the first SCPs you apply to every member account.

Protect CloudTrail logging

This SCP prevents anyone from disabling, deleting, or modifying CloudTrail trails. If your security baseline depends on CloudTrail being active, this SCP makes it non-negotiable.

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

When to use: Any organization where CloudTrail is part of the audit or compliance baseline.

Deny creating IAM users (force role-based access)

This SCP enforces that accounts use IAM roles instead of long-lived IAM users. If your organization has moved to federated identity, this SCP prevents teams from creating IAM users as a workaround.

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

When to use: Organizations that use SSO or federated access and want to prevent long-lived access keys from being created in member accounts.

Protect a security baseline role from modification

If your security team deploys a standard role into every account for auditing or incident response, this SCP prevents anyone in those accounts from modifying or deleting it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityBaselineRole",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DeleteRole",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:UpdateAssumeRolePolicy"
      ],
      "Resource": "arn:aws:iam::*:role/SecurityBaselineRole"
    }
  ]
}

When to use: You have centrally managed security or audit roles deployed to member accounts.

Restrict a sandbox OU to approved services (allow-list)

This SCP removes FullAWSAccess and replaces it with an explicit list of approved services. Anything not in the list is denied. This is the allow-list strategy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowApprovedServicesOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "lambda:*",
        "dynamodb:*",
        "cloudwatch:*",
        "logs:*",
        "iam:*",
        "sts:*"
      ],
      "Resource": "*"
    }
  ]
}

When to use: Sandbox or experimentation OUs where you want to limit cost exposure and prevent teams from using unapproved services.

Troubleshooting SCP-related AccessDenied errors

If a principal has AdministratorAccess but still gets AccessDenied, an SCP is the most likely cause. Here is how to diagnose it:

1. Confirm the error is SCP-related. Check the error message. If it says “with an explicit deny in a service control policy,” the SCP is the cause. If the error message does not mention SCPs, the problem may be in IAM policies or policy conditions instead. See Fixing IAM AccessDenied Errors for the full diagnostic flow.

2. Identify which SCPs are attached. From the management account, check which SCPs are attached to the affected account and its parent OUs. Use the AWS Organizations console or the CLI: aws organizations list-policies-for-target.

3. Read each SCP in the chain. The action must be allowed (or not denied) at every level: Root, each parent OU, and the account itself. A Deny at any level blocks the action regardless of what lower-level SCPs say.

4. Check for condition key mismatches. SCPs often use conditions like aws:RequestedRegion or aws:PrincipalOrgID. If the condition does not match the request context, the Deny may trigger unexpectedly. Verify the exact condition values.

5. Remember the evaluation order. AWS evaluates SCPs before IAM policies in the permission evaluation chain. An SCP Deny is final. No IAM policy, resource policy, or permissions boundary can override it.