AWS Organizations and Service Control Policies

The security team asks for a promise: no account in the company can turn off CloudTrail. You could write an IAM policy that denies cloudtrail:StopLogging and attach it to every role in all 40 accounts. It would work until the first account administrator, who has AdministratorAccess, detaches it.

That is the gap. Inside a single account, the account administrator is the top of the tree, and anything you write there they can rewrite. A promise that holds needs a control point above the account, owned by somebody the account administrator cannot overrule. AWS Organizations is that control point, and a service control policy is how you express the promise.

The previous topic ended with the enforcement order for a single request. Two of those gates, SCPs and RCPs, live in this lesson.

The shape of an organization

An organization is a tree of AWS accounts with a single root at the top. Under the root you create organizational units (OUs), and OUs can nest inside other OUs. Counting the root and the accounts at the bottom, the hierarchy goes 5 levels deep.

There are exactly 2 kinds of account:

• The management account is the one that created the organization. It attaches policies, creates and invites accounts, designates delegated administrators, and pays the bill for everyone. You cannot transfer this role to a different account later.
• Every other account is a member account. A member account belongs to exactly one organization at a time.

Accounts join in 1 of 2 ways: the management account creates them directly, or it invites an existing standalone account, which the account owner must accept. The invitation runs as a handshake, a term you meet only if you use the CLI or API, where invitations are objects with types like INVITE and ENABLE_ALL_FEATURES.

One setup choice decides whether this lesson applies at all. An organization runs with either the consolidated billing feature set, which gives you a single bill and nothing else, or all features, which adds policies and service integrations. SCPs, RCPs, and every cross-account service integration require all features. Upgrading from consolidated billing means every invited member account has to accept a handshake approving the change.

The management account is not governed

This is the fact that makes multi-account design what it is: SCPs have no effect on users or roles in the management account.

Not "limited effect". None. An SCP attached to the root applies to every OU and member account beneath it and skips the management account entirely. The same is true of RCPs and the resources in the management account.

The consequence is the standard AWS recommendation: keep workloads, data, and day-to-day users out of the management account. Anything living there is outside every guardrail you write. When the management account still needs work done, designate a delegated administrator, which is an ordinary member account registered to administer a specific service or to manage organization policies. Delegated administrators are convenient, but note the trap: a delegated administrator is a member account, so SCPs do apply to it. Being trusted to manage Config for the organization does not lift the guardrails on the account doing the managing.

What an SCP is, and what it is not

An SCP looks almost exactly like an IAM policy. Same Version, Statement, Effect, Action, Resource, Condition elements, same JSON.

It behaves nothing like one in a single respect that decides most exam questions: an SCP grants no permissions. It sets the maximum available permissions for IAM users and roles in member accounts. Permissions still come from identity-based and resource-based policies, and the effective permission is the intersection.

Read that as an equation you can apply under pressure:

what a principal can actually do
  = (what the SCP allows)
  AND (what the identity-based policy allows)
  AND (what the permissions boundary allows, if one exists)

Both halves of the failure mode follow from it. A user with AdministratorAccess and an SCP that never mentions S3 cannot touch S3. A user with no IAM policy at all and an SCP allowing every service can do nothing. The SCP is a ceiling, and a ceiling without a floor leaves you standing on the ground.

One extra rule when boundaries enter: if both a permissions boundary and an SCP apply, the boundary, the SCP, and the identity-based policy must all allow the action. Three intersections, no unions.

How SCPs inherit: an Allow needs every level, a Deny needs one

Attaching a policy at the root, an OU, or an account is easy. Predicting the result across a 4-level tree is where people go wrong, because Allow and Deny travel differently.

For a permission to be allowed, an explicit Allow must exist at every level on the direct path from the root, through each OU, down to the account itself. Miss one, and the account is denied. SCP evaluation is deny by default: anything not explicitly allowed at every level is denied.

For a permission to be denied, a single Deny anywhere on that path is enough. Root, any OU on the way down, or the account itself.

Work an example. Root has FullAWSAccess. The Production OU has a custom policy allowing only ec2:* and cloudwatch:*. Account B, inside Production, has FullAWSAccess attached directly. A user in Account B holds AdministratorAccess and calls s3:ListBucket.

Denied. The root allows S3 and the account allows S3, but the Production OU never did, and the chain broke there. Notice what this means in practice: the narrowest Allow on the path defines the ceiling for everything under it. Put an allow-list at the root and it silently governs the whole organization no matter what any OU below attaches.

Now the mirror case. Root has FullAWSAccess. The Sandbox OU has FullAWSAccess plus a policy denying s3:*. Account A and Account B are both in Sandbox and have no S3-related policy of their own. Both are denied S3. Neither account did anything wrong, and neither can fix it locally.

This asymmetry is the whole design. Denies are for controls that must hold broadly, because attaching one high up covers everything beneath it. Allows are for defining a permitted surface, and they are fragile, because every level has to cooperate.

FullAWSAccess, and the quietest way to break an organization

When you enable SCPs, AWS attaches an AWS managed policy named FullAWSAccess to the root, every OU, and every account. It allows all actions on all resources. New OUs and accounts get it automatically at creation.

It exists only because of the allow rule above. Without an Allow at every level, nothing works, so AWS pre-attaches a blanket allow so the deny-by-default model does not lock you out on day one.

Which produces the failure mode worth naming: detaching FullAWSAccess without attaching a replacement allow breaks every account below that point. Every API call fails, and the error message points at an SCP, not at anything in the account. There is no warning dialog that stops you. If you detach it at the root, the entire organization stops working.

The related trap: disabling the SCP policy type in a root detaches every SCP from every entity in that root, and those attachments are not recoverable. Re-enabling gives you a clean slate with only FullAWSAccess back in place, and you reattach everything by hand.

Allow list or deny list

Two strategies, and the exam expects you to know which one a scenario is describing.

Deny lists are the common case, and most published example policies assume one, which is why they say "you also need FullAWSAccess attached" in the fine print. Their statements only subtract, so without an allow somewhere on the path they subtract from nothing.

A note the docs make explicitly: relying only on allow statements and the deny-by-default model can still produce unintended access, because a broad Allow at one level does not undo a broader one somewhere else on the path. Denies are the sharper tool.

A worked guardrail

The CloudTrail promise from the opening, written properly:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectAuditAndComplianceServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "guardduty:DeleteDetector"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/OrgSecurityBreakGlass"
        }
      }
    },
    {
      "Sid": "KeepAccountsInTheOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

Three things are doing work here.

The Sid values are not decoration. When a call is denied by an SCP, the error message names the policy type, and readable statement IDs shorten the conversation that follows.

The ArnNotLike condition carves out one break-glass role in every account, using the wildcard in the account ID position. This is the negated-operator behavior from the previous lesson: aws:PrincipalArn is present in every request, so the condition is doing an honest comparison and the exemption behaves as written. If you ever build an exemption on a key that can be absent, remember that a negated operator returns true for a missing key, and the deny would fire on requests you never meant to cover.

organizations:LeaveOrganization is the statement people forget. An account that can leave the organization can walk out from under every other guardrail you wrote.

Attach this at the root as a deny list, alongside FullAWSAccess, and it holds for every member account. Not for the management account.

What SCPs cannot restrict

Even inside member accounts, a short list sits outside SCP control:

• Anything the management account does.
• Anything done with the permissions of a service-linked role. Service-linked roles are how AWS services act on your behalf, and SCPs cannot narrow them.
• Registering for the Enterprise support plan as the root user.
• Trusted signer functionality for CloudFront private content.
• Configuring reverse DNS for a Lightsail email server or an EC2 instance as the root user.
• A handful of AWS-related services outside the normal API surface, including Amazon Mechanical Turk.

The first 2 matter for the exam. The rest is trivia you can recognize without memorizing.

RCPs: the same idea, aimed at resources

An SCP caps what your principals can do. That leaves a hole: a bucket policy in one of your accounts can grant an outside account access, and no SCP touches that request, because the caller is not managed by your organization.

A resource control policy closes it. RCPs cap the maximum permissions available for resources in member accounts, whoever is calling. Same JSON shape, same never-grants rule, same intersection behavior, same management account exemption, same immunity for service-linked roles.

The keyword split is reliable. A scenario about restricting your people is an SCP. A scenario about restricting who can reach your data, especially when an external principal appears, is an RCP.

Test before you attach

AWS says this in bold in the documentation, and it belongs in your habits: do not attach a new SCP straight to the root. Create a test OU, move accounts in a few at a time, and watch.

Two tools tell you what a policy would break before it breaks:

• Service last accessed data, viewable per organization entity or per policy from the IAM console when signed in with management account credentials. It shows which services the principals in an account actually attempted, which is how you turn a guess about an allow list into evidence.
• CloudTrail, for API-level usage and, after the fact, for the AccessDenied errors a new policy produces.

The failure mode you are avoiding is not subtle: an SCP mistake does not degrade one workload, it removes a service from every account beneath the attachment point at once.

Exam tips

• "An SCP does not grant permissions" is the single most tested sentence about this service. A principal with no identity-based policy has no access no matter what the SCP says.
• An SCP with no applicable Allow denies. It is not just a deny list.
• Allow needs every level from the root down. Deny needs one level anywhere. If a scenario walks you through a hierarchy, trace the path twice, once for each rule.
• A scenario where "the account administrator has AdministratorAccess but the call still fails" and Organizations is mentioned is an SCP question.
• SCPs never affect the management account or service-linked roles. They do affect the member account root user and delegated administrator accounts.
• Detaching FullAWSAccess with no replacement is how organizations break. If a question describes total failure across an OU right after a policy change, look for a missing allow.
• Allow list means new AWS services are blocked until you edit the SCP. Deny list means they are permitted on launch day.
• External principal in the scenario, or "only identities in my organization may access this data", points at an RCP, not an SCP.
• SCPs and RCPs both need all features enabled. Consolidated billing only means neither is available.

The decision rule to carry: ask whether the control has to survive a local administrator. If yes, it belongs above the account in an SCP or RCP, and you accept the coarse granularity that comes with it. If no, an IAM policy or permissions boundary inside the account is cheaper and easier to change. Guardrails answer the question of what is possible in an account. The next lesson answers the other half, which is how a human being gets a signed-in session in 40 accounts without 40 sets of credentials.