Service Control Policies, Inheritance, and Permission Guardrails
Key Takeaways
- SCPs never grant permissions; effective access is the intersection of SCPs, resource control policies (RCPs), identity-based policies, and resource-based policies
- AWS Organizations attaches the AWS managed FullAWSAccess SCP to the root, every OU, and every account; removing it without a replacement Allow blocks all actions in member accounts under that point
- An explicit Deny anywhere on the path from root to the account wins; an Allow must exist at every level on that path for the action to remain available
- SCPs do not affect the management account or service-linked roles, but they do restrict member-account IAM users, IAM roles, the member root user, and delegated-administrator member accounts
- Most enterprises keep FullAWSAccess and add explicit Deny guardrails (leave-organization, unapproved Regions, disabling logging); test those SCPs in a staging OU before attaching them at the root
Service Control Policies, Inheritance, and Permission Guardrails
Quick Answer: A service control policy (SCP) sets the maximum permissions for IAM users and roles in member accounts. It never grants access. Effective permission is the intersection of the SCP, any resource control policy (RCP), identity-based IAM policies, and resource-based policies. Keep FullAWSAccess unless you intentionally allow-list services, and never assume an SCP will constrain the management account.
SCPs exist only in an organization with all features enabled. If the organization still uses consolidated billing only, you cannot attach SCPs at all. Once enabled, SCPs become the preventive backbone of Task 1.4 governance: they stop member accounts from leaving the organization, from operating in unapproved Regions, and from disabling the logging you placed in the Security OU.
SCPs versus other policy types
Professional scenarios mix five related controls. Name the layer that actually solves the stem.
| Control | What it limits | Grants access? | Applies to management account? | Typical use |
|---|---|---|---|---|
| SCP | Maximum permissions for principals in member accounts | No | No | Organization-wide deny of organizations:LeaveOrganization, Region restriction, “do not disable CloudTrail” |
| IAM identity policy | What a user or role can do | Yes (Allow or Deny) | Yes, like any account | Day-to-day least privilege inside one account |
| Resource-based policy | Who may call a specific resource (bucket, KMS key, event bus, queue) | Yes | N/A (lives on the resource) | Partner access to a bucket; EventBridge events:PutEvents from other accounts |
| RCP | Maximum permissions on resources in member accounts | No | No (authorization policies skip the management account) | Force member resources to accept only principals from your organization |
| Permissions boundary | Maximum permissions an IAM principal can ever receive inside one account | No | Yes, if you attach it there | Delegating IAM administration without handing over iam:* |
If a permissions boundary and an SCP are both present, the boundary, the SCP, and the identity policy must all allow the action. Administrators who attach AdministratorAccess in a member account still cannot exceed the SCP. That includes the member account root user. The only way around an SCP is to operate from the management account, to use a service-linked role (SCPs do not restrict those), or to move the account out from under the policy—which is why you deny organizations:LeaveOrganization in the first place.
Declarative policies (backup policies, tag policies, EC2 declarative policies, AI services opt-out, and similar) are a different family. Their inheritance is not the SCP deny-by-default model. Do not treat a tag policy as a substitute for an SCP, and do not treat an SCP as a way to declare backup plans.
Inheritance: Allow, Deny, and FullAWSAccess
AWS Organizations attaches the AWS managed SCP named FullAWSAccess to the root, to every OU, and to every account when those objects are created. That policy allows all services and actions. It exists because SCP evaluation is deny-by-default for Allow statements: for a permission to remain available to an account, an explicit Allow must be present at every level on the path from the root through each parent OU to the account itself.
| Evaluation rule | Practical consequence |
|---|---|
| Allow must exist at every level on the path | If you detach FullAWSAccess from Production OU and do not replace it with another Allow, Production accounts cannot call any AWS API, even if Root and the account still have FullAWSAccess |
| An explicit Deny anywhere on the path wins | A root Deny of organizations:LeaveOrganization blocks every member account, even if a child OU Allow lists that action |
| Multiple SCPs at one level combine | A Deny in any attached SCP is enough; overlapping Allows can also widen the allow list, which is why pure allow-list designs need care |
If you disable the SCP policy type at the root, Organizations detaches every SCP from every entity. Re-enabling SCPs restores only FullAWSAccess. Custom attachments are not recovered automatically. Treat that as a last-resort break-glass, not a troubleshooting step.
Deny-list versus allow-list strategies
Most regulated enterprises use a deny-list (sometimes called a blacklist guardrail) on top of FullAWSAccess:
- Deny
organizations:LeaveOrganizationandaccount:CloseAccountat the root so a member administrator cannot walk away from logging and billing. - Deny unapproved Regions with a condition on
aws:RequestedRegion, while leaving global services that you still need carefully excepted in the same statement. - Deny disabling organization trails, public S3, or other high-risk actions that your Control Tower or security baseline already forbids.
Deny lists scale: a new AWS service is usable until you explicitly deny it, which matches how application teams adopt features. The tradeoff is that you must keep the deny list current for the risks you care about.
An allow-list replaces FullAWSAccess with a policy that Allows only named services. That is appropriate for highly locked Sandbox or PCI OUs where “anything not listed is forbidden,” including brand-new services. AWS documentation warns you not to remove FullAWSAccess unless you replace it with another Allow; otherwise all member actions fail. Attach an allow-list at the most specific OU you can. Putting a narrow allow-list at the root silently freezes every account in the organization, including security tooling that must call many APIs.
AWS recommends you do not attach a new SCP to the root without testing. Create a Policy Staging or Sandbox OU, move a canary account, and watch IAM service last accessed data and CloudTrail. After the canary survives, attach the policy more broadly.
Management-account caveats and what SCPs do not cover
SCPs do not affect users or roles in the management account. They do affect delegated-administrator member accounts. That is why security tooling belongs in the Audit account, not in the payer account: you want the same guardrails that production has, plus detective controls, without creating an SCP-exempt fortress that also pays the bill.
SCPs also do not:
- Grant any permission. A user with no IAM policy still has no access even if every SCP Allows
*. - Directly filter resource-based policies for principals outside the organization. If member account A’s bucket policy allows partner account B, an SCP on A does not evaluate B’s callers. Close that hole with a tighter bucket policy or with an RCP that sets a resource-side ceiling for member resources.
- Restrict service-linked roles, some root-only support tasks, or a short list of AWS-related services documented as out of SCP scope.
Because SCPs skip the management account, break-glass must be designed, not accidental. Limit who can assume roles in the management account, prefer delegated administrators, and send every management-account API call to the log archive. Control Tower continues to log management-account actions in the log archive even when a control would have denied the same action in a member account.
Exam scenario: SCP blocking leave-organization
A product VP in a member account holds AdministratorAccess and tries to leave the organization after a dispute with central security. CloudTrail in the log archive shows organizations:LeaveOrganization denied. The VP then attaches a bucket policy that allows an external integrator to read production objects, and that access succeeds.
Both outcomes are consistent with SCP evaluation. The leave call is a principal action inside the member account, so the root Deny SCP wins over AdministratorAccess. The partner GetObject call is performed by a principal outside the organization, so the member SCP never evaluates it. The architect’s follow-up is an RCP (or a bucket policy conditioned on aws:PrincipalOrgID) plus a detective Config rule, not “the SCP is broken.”
A second scenario: a platform team replaces FullAWSAccess at the root with an allow-list that omitted cloudformation:* the night before a Control Tower account update. Account Factory and StackSets fail in every member account. The fix is to restore an Allow for the orchestration services at the root (or restore FullAWSAccess) and move the tight allow-list down to Sandbox only.
SAP-C02 decision rules
- If the stem needs a ceiling on every principal in many accounts, choose an SCP (or RCP for the resource side)—not 200 copies of an IAM Deny.
- If the stem needs someone to do work, choose an identity policy, a permission set, or a resource policy; an SCP cannot grant that.
- If the actor is in the management account, an SCP will not save you; redesign the topology.
- Prefer deny-list + FullAWSAccess unless the OU is meant to be a service prison.
- Test inheritance with a staging OU. Remember Allow-at-every-level and Deny-anywhere-wins before you detach FullAWSAccess.
A member-account administrator attaches the AWS managed AdministratorAccess policy to an IAM role and still cannot call organizations:LeaveOrganization. The same role can launch Amazon EC2 instances. What explains this?
A platform team wants preventive guardrails that block disabling CloudTrail, leaving the organization, and using an unapproved Region, without accidentally denying new AWS services that application teams will adopt next quarter. How should they structure SCPs?
An Amazon S3 bucket in a member account has a bucket policy that allows a partner AWS account outside the organization to call s3:GetObject. An SCP on that member account denies s3:GetObject. What is the effective result for the partner?