Service Control Policy

A service control policy limits actions by IAM principals in covered AWS accounts through the organization hierarchy. It does not govern every request to a resource merely because that resource resides in the account. These properties describe AWS SCPs; other providers have different policy and inheritance models.

It restricts and never grants

An SCP supplies no permission grant. It limits what covered principals can do even when other policies grant them access. Local administrator privileges cannot override an applicable SCP deny.

Effective access depends on the applicable IAM grants and restrictions, including resource-based policies, boundaries, session policies, SCPs, and resource control policies where supported. Which principal makes the request and which policy supplies the grant matter.

• A permissive SCP grants nothing. A principal still needs an applicable permission grant. Depending on the request, this may come from an identity-based policy or a resource-based policy.
• A local administrator cannot override it. Attaching AdministratorAccess does not make an action allowed when an applicable SCP denies it.

SCPs set limits for covered principals; identity-based and resource-based policies can supply grants within applicable restrictions. Designing those grants for least privilege remains a separate exercise.

Inherited, cumulative, and binding on root

Policies attach at the root, organizational units, and accounts. The required allow must exist at every level on the path, and any applicable explicit deny wins. Multiple SCPs at a level can contribute allows; one policy omitting an action does not by itself mean every policy at that level omits it.

SCPs apply to covered member-account principals, including the root user. This is a restriction a local identity administrator cannot undo by changing an IAM grant.

For an identity-based grant, an attached permissions boundary limits the grant, and applicable SCP restrictions also have to permit the action. Do not generalize that intersection to every resource-based grant. Within the same account, a resource policy granting directly to an IAM user ARN or a role session ARN can escape implicit denies in the relevant identity policy or permissions boundary. A grant to a role ARN has different boundary behavior. Applicable explicit denies and SCP restrictions still hold: these IAM evaluation rules do not provide an SCP bypass. Check the principal type and grant path when diagnosing access.

The exceptions, and what they imply

The exceptions are documented, and they are not all of the same kind — an account can sit outside the mechanism, a role can, and something that looks like an exemption can turn out not to be one. Mixing them up is common and produces the wrong conclusion in both directions.

Kind	Covered?	What the documentation says
Management-account principals	No	Apply other IAM, resource, and operational controls
Member account acting as a delegated administrator	Yes	Delegated administration does not exempt its otherwise covered principals
Service-linked roles	No	SCPs do not restrict their permissions
Other covered member-account IAM principals, including root	Yes	A local IAM allow cannot override applicable SCP restrictions
External principal using a direct resource-policy grant	Not by the resource-owning account’s SCP	Evaluate restrictions on that principal and controls on the resource. Assuming a covered target-account role instead changes the principal and its applicable SCPs

These gaps require different responses. Keep the management account tightly controlled and record its use in an audit log. Protect resource access with resource policies and, where supported, resource control policies; do not assume an SCP on the resource owner blocks external principals. A member account providing delegated administration still needs its covered actions allowed by applicable SCPs.

Alongside those, the documentation lists specific tasks that cannot be restricted this way — actions by the management account, anything using a service-linked role’s permissions, registering for the Enterprise support plan as the root user, and a handful of others. Read that list before designing a control that depends on total coverage, rather than discovering the gap from an audit finding.

Rolling one out without locking people out

AWS recommends testing SCPs on a limited set of accounts before broad application, for example by moving accounts into a test organizational unit gradually. Include service integration and recovery paths in the tests.

Preserve the allows needed at each hierarchy level. Removing FullAWSAccess without sufficient remaining or replacement allows can block actions even when IAM grants remain. The policy name itself is not a special bypass; what matters is the effective set of SCP allows and denies.

For deciding what a policy should actually say, the documentation points at evidence rather than intuition: service last accessed data shows which permitted services accounts never use, which lets you tighten a policy toward what is actually needed instead of guessing.

What to put in one

The failure modes are symmetrical. Too broad and it blocks work, collects exceptions, and eventually means nothing. Too narrow and it prevents nothing the organization cared about.

Use SCPs for baseline restrictions that must apply to covered principals across the chosen account scope, such as supported regional, service, or audit-protection rules. Keep the restriction tied to an owned requirement and test its exceptions. Choose identity policies, resource policies, resource control policies, or other controls for rules whose principal, resource, or operation scope requires them; an SCP does not replace those mechanisms.

Because these are configuration with organization-wide effect, they belong under version control and review — policy as code — and each one needs an owner who can say why it exists, since a guardrail nobody owns accumulates exceptions until it is decoration.

How guardrails fit with the account hierarchy, identity, network topology, and cost allocation is worked through in Before the First Workload.

References:

• AWS Organizations User Guide, Service control policies (SCPs)
• AWS IAM, Permissions boundaries