AWS Service Control Policies Explained: SCPs and Denials

AWS service control policies (SCPs) are AWS Organizations policies that set the maximum permissions available to identities in member accounts. They never grant access, and an administrator with AdministratorAccess still gets Access Denied when an applicable SCP blocks the request.

This guide explains that denial from the organization tree down to the calling role. It covers inheritance, the Allow required at every level, exceptions, deny lists and allow lists, common policy patterns, and the services used alongside SCPs. It also walks through troubleshooting, rollout decisions, and practice questions for Solutions Architect Associate and DevOps Engineer Professional.

What are service control policies?

An SCP is a centrally managed permission limit. You attach it to an organization root, an organizational unit (OU), or an individual member account, and it constrains the identities within that scope. This gives you a place to enforce requirements that administrators inside those accounts cannot override by changing their local IAM policies.

The distinction between a limit and a grant matters whenever you see Allow in an SCP. It means the organization permits that action to remain available; the identity still needs permission through the relevant identity-based or resource-based policies. An otherwise unprivileged user does not become an administrator because the organization's SCPs allow every service.

SCPs use JSON syntax similar to IAM policies, but they belong to AWS Organizations. Your organization must have all features enabled to use them; consolidated billing alone does not provide policy management. AWS explains these prerequisites and the permission ceiling in its SCP overview.

For the foundations of users, roles, and policies, read the AWS IAM users, roles and policies guide. Here, the focus is the organizational limit applied around those permissions.

Why admins get Access Denied

Suppose your member-account administrator can manage AWS resources through AdministratorAccess, but the account belongs to an OU that denies requests outside approved Regions. A request to launch a server in an excluded Region fails. Adding another broad IAM Allow inside that account cannot change the organizational restriction.

The effective permissions are the overlap between the relevant grants and limits. For a request using identity-based permissions, the role's policy must allow it, any permissions boundary must permit it, and the SCPs must leave it available. An explicit Deny can block the request even when all the other policies contain matching Allows.

A useful troubleshooting order

Use this order to separate an organizational restriction from a missing local permission. It is a way to apply the evaluation rules, not an assumption that every access error comes from an SCP.

1. Identify the caller and account. Establish which user or role made the request and whether it belongs to a member account. A management-account identity has a different SCP scope.
2. Identify the requested operation. Check the action, resource, and relevant conditions, including the requested Region. A permission that works in an approved Region can fail elsewhere under the same role.
3. Trace the account's organization path. Review SCPs attached to the root, every parent OU, and the account. Looking only at policies directly attached to the account misses inherited restrictions.
4. Check both kinds of SCP rejection. Look for a matching explicit Deny and for a missing applicable Allow at any level. A missing Deny doesn't prove the SCPs permit access.
5. Check the remaining policies. Review the identity's permissions, any boundary, and relevant resource policies or RCPs. Clearing the SCP restriction does not supply a missing grant.

CloudTrail API activity and IAM service last accessed data can help establish which services an account uses while you investigate or prepare a policy change. Use that evidence to understand the effect of a restriction before broadening it. AWS's IAM policy evaluation guidance explains how the other policy types participate.

How an SCP is evaluated

Organizations arranges accounts in a tree with a root, OUs, and member accounts. The management account administers the organization; the organization root is a container, not the root user of an AWS account. OUs group accounts and can nest up to five levels below that container.

An SCP attached to an OU affects the member accounts below it, including accounts inside nested OUs. Those accounts also inherit applicable SCPs from higher levels. AWS describes the structure in its Organizations concepts.

Allow must survive every level

For an action to remain available, an applicable SCP Allow must exist at the root, at each OU on the direct path, and at the target account. This is a requirement at every level, not a requirement that every attached policy repeat the same Allow. A deny-only policy can coexist with another policy that supplies the Allow at that level.

AWS automatically attaches the managed SCP FullAWSAccess to the root, OUs, and accounts. It permits all services and actions through the SCP layer, which supplies the broad Allow baseline for a deny-list design. Its name does not mean that it grants IAM administrator permissions.

Imagine the root permits all services, the production OU permits only EC2 and S3, and the account permits all services. The OU still limits the account to EC2 and S3 at the SCP layer. The account's broad Allow cannot restore a service that the parent OU leaves out.

An explicit Deny wins

Now suppose the root explicitly denies S3 while a lower OU allows it. The S3 request remains blocked, because a lower-level Allow cannot reverse an inherited Deny. A matching Deny directly on the account has the same blocking effect for that account.

Keep these rejection paths separate: an explicit Deny blocks a matching request, while an implicit denial results from the absence of a required Allow. A deny-only SCP replacing the root's broad Allow can therefore remove service access even for actions it never names. The SCP evaluation examples show both forms of rejection.

This is also why moving an account or attaching a policy requires checking the whole path. An account's directly attached SCPs do not tell you its complete permission ceiling. Review the ancestors along with the account before deciding whether a request should pass.

What SCPs do not affect

SCPs do not restrict users or roles in the management account, even when the policy is attached to the organization root. Keep workloads in member accounts if they need these organizational limits. Attaching another root-level SCP does not bring management-account identities into scope.

SCPs also do not restrict service-linked roles, the other main exception (AWS lists a few narrower ones, such as signing up for an Enterprise support plan as root). An ordinary IAM role is not exempt merely because it performs administration or automation. The relevant exception is the role type, not the importance of its job.

Conversely, SCPs do affect the root user of a member account and identities in member accounts designated as delegated administrators. Delegating administration does not turn a member account into the management account. A member-account root user cannot bypass a matching SCP Deny.

An external principal accessing your S3 bucket through a bucket policy is outside your SCP's principal scope. The bucket being in your organization does not make that external identity subject to your SCPs. Resource control policies address the resource side of that problem, as explained in AWS's SCP and RCP comparison.

Deny list vs allow list

Both strategies use the same evaluation rules. The difference is the baseline you maintain and what happens when an action has not been considered explicitly.

• Deny list: keep FullAWSAccess and add specific Deny statements. / Allow list: replace the broad baseline with SCPs permitting only selected services or actions.
• Deny list: actions remain available at the SCP layer unless denied. / Allow list: actions omitted from the applicable Allows are unavailable.
• Deny list: a new service can remain available unless a Deny matches it. / Allow list: a new service stays unavailable until the allow list permits it.

An allow-list SCP attached beside FullAWSAccess at the same location does not narrow that location's broad Allow. The policies' Allows combine there; the shorter list does not subtract permissions from the broader one. Likewise, an overlapping broad Allow can undermine the restriction you intended a narrower Allow to create.

Policy limits and a safe rollout

AWS's Organizations limits allow up to 10 SCPs attached directly to each root, OU, or account. Inherited policies do not count toward that direct attachment limit. Each entity must retain at least one attached SCP while the policy type is enabled.

An SCP can contain up to 10,240 characters, including whitespace. The console removes extra whitespace outside quoted text when saving, while CLI and SDK submissions retain the document as supplied. Check the actual document size when a policy approaches the limit.

AWS recommends testing new SCPs in a test OU and moving accounts into it gradually before applying the policy at the root. Use CloudTrail activity and service last accessed information to check the services the policy would affect. For an allow-list transition, establish a replacement Allow before removing FullAWSAccess; otherwise, actions beneath that level fail.

Disabling and re-enabling the SCP policy type is not a way to preserve your policy assignments. Disabling it detaches the SCPs, and re-enabling restores the default FullAWSAccess attachments rather than the old custom attachments. Treat that operation as a governance change with its own consequences.

Common SCP examples

You can understand the policy patterns without memorizing a JSON document. For each pattern, identify what is denied, where the policy attaches, and which conditions or exceptions apply.

Restrict requests to approved Regions

The common Region pattern uses Deny with StringNotEquals on aws:RequestedRegion. In AWS's example, requests outside eu-central-1 and eu-west-1 match the deny condition. Attaching the policy to an OU applies the restriction to its member accounts, including local administrators.

Global services need careful handling because a blanket Region denial can disrupt them. The example uses NotAction to exclude cloudfront:*, iam:*, route53:*, and support:* from that Deny. You can inspect the pattern in AWS's SCP syntax examples.

An exclusion from this statement is not a grant of access or an exemption from every other SCP. The action still needs the required Allows and must survive any other applicable Deny. Read NotAction together with the statement's effect and condition.

Prevent logging from being disabled

AWS recommends an SCP denying cloudtrail:StopLogging and cloudtrail:DeleteTrail to prevent users from switching off logging. The important target is the ability to interrupt collection; having a trail configured does not by itself explain which identities can administer it. See the CloudTrail protection guidance.

A condition using aws:PrincipalArn can exclude a specific administration or break-glass role from a Deny statement. That exception removes this particular obstacle; the role still needs permission and must satisfy the other applicable limits. A broadly privileged role without the exception remains subject to the Deny.

Control Tower's older trail protection illustrates this arrangement: on landing zones below version 4.0, its SCP restricts changes to Control Tower trails while excluding its execution role. Control Tower no longer deploys that control from version 4.0, as the mandatory controls reference explains.

Use the current policy language

AWS added full IAM policy language support for SCPs on September 19, 2025. Allow statements can use conditions, individual resource ARNs, and NotAction; the update also supports NotResource and wildcards at the beginning or middle of action strings. The AWS announcement describes the change.

Older study material may say SCP Allow statements cannot contain conditions or individual resource ARNs. That describes the earlier restrictions, so use the announcement when older wording conflicts with the expanded language. SCPs still do not support Principal or NotPrincipal; selecting role exceptions through a condition is a different mechanism.

Services used with SCPs

SCPs supply a permission ceiling within a wider governance design. Separate the service that organizes accounts, the policies granting access, the controls preventing requests, and the tools detecting configuration problems.

Organizations and Control Tower

AWS Organizations creates and groups accounts, centralizes their governance, and supports consolidated billing. An SCP is a policy type within that service. AWS Control Tower builds a governed multi-account landing zone using services including Organizations and IAM Identity Center.

Control Tower implements preventive controls through SCPs, RCPs, and declarative policies; detective controls use AWS Config rules. Its control behavior reference explains the distinction. A Config finding identifies a problem after the configuration exists, whereas an applicable SCP can reject the prohibited request.

Do not edit or detach SCPs created by Control Tower. Add your own SCPs through Organizations and attach them to the appropriate OU instead, following the Control Tower Organizations guidance.

IAM, permissions boundaries, and Identity Center

IAM Identity Center permission sets define policies used to create roles in target accounts. People assume those roles, and their requests remain subject to the account's SCPs. Permission sets can also carry a permissions boundary, as the permission set documentation explains. Compare the scope of these policies when deciding which layer to use:

• IAM identity policy: grants permissions to its user or role. / SCP: limits permissions available to member-account identities under its organization scope.
• Permissions boundary: caps the permissions an identity policy can grant an individual user or role. / SCP: supplies a centrally managed limit across accounts or OUs.
• Permission set: supplies policy configuration for account roles created through Identity Center. / SCP: continues to constrain those roles after they are created.

A boundary does not grant access either. For the identity-based permission path, the role's policy, boundary, and applicable SCPs must all permit the action. AWS walks through this overlap in its permissions boundaries guide.

RCPs, CloudTrail, and Access Analyzer

Resource control policies set maximum permissions on supported resources, including requests from principals outside your organization. They complement SCPs, which constrain your own member-account principals. Neither policy type supplies the underlying permission grant; AWS's RCP documentation explains the resource scope.

A CloudTrail organization trail records events for the management account and member accounts. It provides activity evidence alongside the permission restrictions, while member accounts cannot change or delete the organization trail. The organization trail documentation describes that central arrangement.

IAM Access Analyzer helps validate policies and identify unused access, and it can report resources shared outside an organization's zone of trust. IAM service last accessed data helps you examine allowed services that are not being used before tightening an SCP. The Access Analyzer overview explains its analysis features.

Who uses them

AWS lists GE and Bancolombia on its Organizations customers page. GE's testimonial describes central governance through Organizations and SCPs while business units administer their own identity-based and resource-based policies. Bancolombia's testimonial describes grouping workloads with similar risk profiles into accounts and enforcing SCP controls that member-account administrators cannot override.

AWS's management and governance guide also describes BPX Energy, a BP company, using Control Tower with preventive SCP controls and detective AWS Config controls. The example pairs a control that rejects prohibited operations with one that flags noncompliant configurations.

SCP exam traps

For Solutions Architect Associate (SAA-C03), the official exam guide names SCPs in secure multi-account design. For DevOps Engineer Professional (DOP-C02), SCPs appear in multi-account IAM and Security and Compliance. The recurring skill is choosing the control whose scope and timing match the requirement.

Prevention across accounts vs detection after a change

If local administrators must be unable to violate an organization-wide Region restriction, look beyond their editable IAM policies. An SCP on the OU supplies the central preventive limit, while the global-service exemptions preserve the intended exceptions. Work through a practice question on Region restrictions for member-account administrators to distinguish it from a Config rule that reports a violation afterward.

Delegating role creation vs blocking it

Preventing every role-creation request can defeat a requirement for developers to create their own roles. A permissions boundary can cap those created roles while identity policies provide the permissions to create them under the required conditions. A practice question on permissions boundaries for delegated role creation tests that distinction; remember that neither the boundary nor an SCP grants access by itself.

Protecting logging vs reporting its interruption

A requirement to prevent disabling logging points toward a request-time Deny rather than detecting the interruption and repairing it later. If an exception role lives in a member account, it remains subject to SCPs unless the policy makes the required exception. A practice question on protecting an organization trail with an SCP combines the preventive control, member-root scope, and role exception.

Your identities vs external principals

Tightening your SCP does not place an external principal under your organization. When the requirement is a central limit on access to supported resources, including access from outside, consider the RCP scope. A practice question on resource control policies and an external-access perimeter turns on this difference.

Request-time enforcement vs checks before deployment

An SCP can block an action when it is requested without making a deployment pipeline reject the policy that would otherwise grant it. If the requirement is to fail the pipeline before deployment, inspect the proposed policy with the appropriate Access Analyzer check. A practice question on Access Analyzer checks in a deployment pipeline tests that timing difference.

Also remember the inheritance traps: an account-level Allow cannot override a parent Deny, and FullAWSAccess beside a narrow allow list preserves the broad Allow at that level. For more practice, use the SAA-C03 question list and DOP-C02 question list. The CloudOps Engineer Associate guide places these governance concepts in an operations study path.

Frequently asked questions

Does an SCP grant permissions in AWS?

No, it sets the maximum permissions available within its scope. The identity still needs the relevant permission grant, even if every applicable SCP permits the action.

Can AdministratorAccess override an SCP?

No, an applicable SCP restriction still limits a member-account administrator. A broader IAM Allow cannot override an explicit SCP Deny or restore an Allow missing higher in the tree.

Do SCPs apply to the management account or root user?

They do not restrict management-account identities. They do restrict the root user of a member account, while service-linked roles are exempt.

What is the difference between an SCP and a permissions boundary?

An SCP applies a central limit to identities across its member-account scope. A permissions boundary caps the permissions an identity-based policy can grant an individual IAM user or role, and neither type grants access.

Why does an SCP allow list seem to have no effect?

Check whether FullAWSAccess or another broad Allow remains attached at the same level. Additional Allows there combine, so adding a narrower list does not subtract the broader policy's permissions.

Can an SCP stop an outsider accessing my S3 bucket?

Your SCP does not constrain a principal belonging to an account outside your organization. An RCP supplies resource-side permission limits that can include external principals accessing supported member-account resources.

Watch the whiteboard video

The whiteboard animation follows a request through the organization tree and shows where its available permissions narrow, making the inherited limits easier to see together. It also walks through the administrator's Region-restriction scenario: AWS Service Control Policies Explained: Why Admins Get Access Denied on YouTube.