Service Control Policy (SCP)

A Service Control Policy (SCP) is a policy type in AWS Organizations that sets the maximum permissions for member accounts. SCPs do not grant permissions - they restrict what permissions are available. Even if an IAM policy in a member account says "Allow": "ec2:*", an SCP can prevent that account from launching instances in certain regions.

Key Characteristics

• SCPs affect all users and roles in the member account, including the root user
• SCPs do NOT affect the management account (the org root)
• SCPs do not restrict service-linked roles, which AWS services use to integrate with your organization
• Since September 2025, SCPs support the full IAM policy language - conditions on Allow statements, wildcards at the beginning or middle of Action strings, the NotAction element with Allow statements, individual resource ARNs, and the NotResource element
• SCPs can be attached to the organization root, organizational units (OUs), or individual accounts

Common SCP Patterns

• Region restriction: deny all actions outside approved regions
• Prevent disabling security: deny guardduty:DeleteDetector, config:StopConfigurationRecorder
• Require encryption: deny s3:PutObject without s3:x-amz-server-side-encryption
• Block public access: deny s3:PutBucketPolicy with public principal

How It Goes Wrong in Practice

The most common SCP incident is self-inflicted lockout. AWS Organizations attaches a default policy called FullAWSAccess to the root, every OU, and every account when SCPs are enabled. If someone detaches or replaces it without providing an equivalent allow statement, every AWS action from the affected member accounts starts failing at once, because with SCPs enabled an action must be permitted by every level of the SCP chain to be usable at all. AWS documents this explicitly: do not remove FullAWSAccess unless you replace it with a policy that still allows the actions you need.

The second failure mode is a false sense of coverage. SCPs never affect users or roles in the management account, and they do not restrict service-linked roles either. A guardrail that denies cloudtrail:StopLogging across the organization still leaves an administrator in the management account able to stop logging there. This is one of the strongest arguments for keeping workloads, users, and daily operations out of the management account entirely.

Finally, region-restriction SCPs are notorious for breaking global services. When you write a deny for all actions outside approved regions, exempt global services such as IAM, Organizations, STS, CloudFront, Route 53, and Support with a NotAction list, and test the policy on a sandbox OU first. AWS recommends moving accounts into a test OU in small numbers rather than attaching an untested SCP to the root, and suggests using IAM service last accessed data to see which services an account actually uses before you cut access.

A Practical Check

List the SCPs that exist in your organization, from the management account or a delegated administrator:

aws organizations list-policies --filter SERVICE_CONTROL_POLICY

Before attaching a new SCP, run it through IAM Access Analyzer policy validation, which has a dedicated policy type for SCPs and will flag syntax errors and unsupported constructs:

aws accessanalyzer validate-policy --policy-document file://scp.json --policy-type SERVICE_CONTROL_POLICY

Quotas Worth Knowing

• Maximum SCP document size: 10,240 characters. All characters count when you save via the CLI or an SDK; the console strips extra white space outside quotation marks.
• You can attach up to 10 SCPs directly to the root, to each OU, and to each account. Policies inherited from parent OUs do not count against this limit.
• OUs can be nested up to five levels deep under the root, and an account is bound by every SCP above it in the hierarchy.
• An organization can contain up to 10,000 SCPs in total, and every entity must keep at least one SCP attached at all times - you cannot detach the last one.

Frequently Asked Questions

Do SCPs grant permissions? No. An SCP is a ceiling, not a grant. A principal can perform an action only if an identity-based or resource-based policy allows it and no applicable SCP blocks it. The effective permissions are the logical intersection of the two, so a brand-new user with no IAM policies has no access even under the most permissive SCP.

Why does my SCP not apply to the management account? That is by design. SCPs affect member accounts only, including member accounts designated as delegated administrators. Nothing you attach will constrain the management account, which is exactly why best practice keeps that account free of workloads and day-to-day users.

What is the difference between an SCP and a permission boundary? Both cap maximum permissions, but at different layers. An SCP is an organization-level control that applies to entire accounts; a permission boundary is an IAM feature applied to an individual user or role. When both are present, the SCP, the boundary, and the identity-based policy must all allow the action for it to succeed.