Service Control Policies (SCPs) & Organizations

The Morning Theo Almost Bought a Supercomputer

Six weeks after the photo bucket incident, Theo has been rehabilitated. Trailbase now runs three AWS accounts: production, development, and a sandbox where Theo holds AdministratorAccess and is encouraged to break things. One Friday he decides his trail-photo classifier needs more muscle, opens the EC2 launch wizard, and picks a p4d.24xlarge, a GPU monster that costs more per day than Theo earns in a month. He reaches the review screen before Mara glances over and asks what, exactly, he is about to click.

Here is the uncomfortable part: nothing inside the sandbox account could have stopped him. Theo is an administrator there, and IAM policies live inside the account, within reach of that administrator. Any fence Dana builds with IAM, admin-Theo can edit or delete. A guardrail that binds an administrator has to be anchored somewhere the administrator cannot reach, which means above the account itself. That is the job of AWS Organizations, the free service that gathers multiple AWS accounts under one management umbrella, and of Service Control Policies (SCPs), the policies attached to that umbrella which define the maximum permissions available inside each account. Back in lesson 1 you learned the evaluation ladder: explicit deny beats allow, and SCPs cap everything from above. This lesson is about that cap.

One Account Becomes Many

Why did Trailbase split into three accounts at all? Because the account is the strongest isolation boundary AWS offers. A runaway experiment in the sandbox cannot touch production data, blow through production quotas, or appear in production bills. Once you have more than one account, though, someone has to manage the pile, and that is what AWS Organizations does.

Dana creates the organization from a fourth, deliberately empty account. That account becomes the management account: it owns the organization, pays the consolidated bill, and holds the power to create accounts and attach policies. Every other account joins as a member account. Dana keeps the management account as empty as her root credentials vault, and for the same reason: it is exempt from the very guardrails it hands out, so anything running inside it runs unguarded.

Trailbase groups its accounts into organizational units, or OUs: folders in the hierarchy that exist so you can attach policy once and have it apply to every account inside. Production sits in a Workloads OU, development in an SDLC OU, and Theo's playground in a Sandbox OU. The point of the grouping becomes clear the moment Dana writes her first guardrail.

SCPs: The Fence Admins Cannot Move

Monday morning, Dana attaches a policy to the Sandbox OU that denies ec2:RunInstances whenever the requested instance type is large. Theo still has AdministratorAccess. He can still create users, delete buckets, and rearrange the sandbox however he likes. But when he retries the p4d.24xlarge launch, AWS refuses, and no amount of IAM editing inside the account will change that answer, because the refusal comes from a layer he cannot see, let alone modify.

That policy is a Service Control Policy. An SCP works purely by subtraction: it defines the outer boundary of what identities in an account can ever do, and the actual grants still come from IAM policies inside that boundary. Attach an SCP allowing s3:* to an account containing a user with zero IAM policies, and that user can still do nothing. The SCP opened the gate; nobody inside handed the user a key. The JSON is the same policy language you learned in lesson 1, and since 2025 it is the full language.

Inheritance: Guardrails Flow Downhill

Where you attach an SCP decides who it binds, and the rule is simple: policies flow down the tree. Attach at the Root and every OU and account inherits it. Attach to the Workloads OU and only the accounts under Workloads feel it. For an action to succeed, every SCP on the path from the Root down to the account must allow it. Evaluation is an intersection, so a child OU can never re-allow something a parent denied.

Watch it work at Trailbase. After the operations team once terminated a production instance during a deploy scare, Dana added a termination deny at the Production OU, with an MFA-protected exception role exempted by ARN condition for the rare legitimate case. The production account now inherits two layers of policy without a single policy attached to the account itself:

The Exemptions Everyone Forgets

A month in, Dana notices something odd in CloudTrail: an action her root-level SCP denies was performed anyway, from the management account. This is by design, and it is the single most tested SCP fact on the exam.

The management account exemption exists so an organization can never lock itself out of its own steering wheel, and it is exactly why Dana keeps that account empty of workloads. The service-linked role exemption matters for the same reason in miniature: Auto Scaling, for example, acts through a service-linked role, and an SCP that appeared to block EC2 launches would silently fail to stop scaling events. Priya, reviewing Trailbase's setup during her audit, called the empty management account the best decision in the whole architecture.

Two Ways to Run the Guardrails

Every new organization ships with a managed SCP called FullAWSAccess attached everywhere, which allows everything. From that starting point you have two strategies, and choosing between them is a classic exam decision.

Trailbase picks the deny list, and so should almost everyone: the team wants each new AWS service usable on day one, with a short, readable list of forbidden actions. The allow list earns its cost only where a regulator demands that nothing unapproved can ever run.

The Trailbase Guardrail Set

Over the following quarter, Dana and Mara build up five deny-list policies. Each one exists because something happened, or nearly happened, and together they cover the patterns the exam draws from.

The first came from cost review. Development instances kept appearing in far-flung regions where nobody looked at the console, and European hiker data has GDPR residency requirements anyway. So Trailbase pins the whole organization to three approved regions, with an exemption for the admin role so a global operation can never strand them. One caveat for real deployments: global services such as IAM, Route 53, and CloudFront issue their calls through specific regions, so region-pinning SCPs need carve-outs for them.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAdminRole"
        }
      }
    }
  ]
}

The second policy came straight from Priya's audit findings. CloudTrail is the log that caught nothing during the root-credentials era because there was nothing to attribute; now that it attributes everything, the log itself must be untouchable, even by account admins. The same goes for AWS Config, the service recording each resource's configuration history. Attached at the Root, the policy holds for every account Trailbase will ever create, which is the exam answer whenever a scenario says no user in any account may disable CloudTrail:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ProtectConfig",
      "Effect": "Deny",
      "Action": [
        "config:DeleteConfigRule",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

The third enforces encryption. Mara's data pipelines write hiker analytics to S3, and rather than trusting every script to remember the encryption header, the organization denies any unencrypted upload. The Null condition reads as "if the encryption header is absent":

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3Objects",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
  ]
}

The fourth protects the protections. S3 Block Public Access is the account-level switch that keeps buckets private, and this policy stops anyone below the security admin role from flipping it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPublicBucketACL",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeletePublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/SecurityAdminRole"
        }
      }
    }
  ]
}

The fifth closes the loop on lesson 1. Every member account still has root credentials, and each one is a standing risk. Recall that inside an account, root sits above every IAM policy; inside an organization, an SCP sits above member-account root, so it can do what IAM never could and neutralize that root user entirely.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

Designing the OU Tree

With the policies written, the remaining question is where they hang, which means designing the OU tree. AWS publishes a recommended structure, and its guiding rule is to organize by function and compliance need rather than by the company reporting chart:

Two entries deserve a story each. PolicyStaging exists because an SCP typo can take down production in every account at once; Dana tests each new policy against throwaway accounts in that OU before promoting it. Transitional exists for the day Trailbase acquires a smaller trail-mapping startup whose account arrives with unknown workloads: it joins the organization under temporarily permissive policies instead of being strangled by production guardrails on day one.

Trailbase, Governed

The p4d incident ends as a slide in the onboarding deck. Theo keeps his sandbox admin rights and his salary. The organization now has guardrails that no admin can loosen, an audit trail no admin can silence, and a management account that stays empty precisely because it answers to nothing. Priya signs off on the audit.

Common Pitfalls

Quick Reference

# List all SCPs in organization
aws organizations list-policies --filter SERVICE_CONTROL_POLICY

# Get SCP content
aws organizations describe-policy --policy-id p-abc123def

# Create new SCP
aws organizations create-policy \
  --name "DenyUnapprovedRegions" \
  --description "Prevents use of unapproved regions" \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp-deny-regions.json

# Attach SCP to OU
aws organizations attach-policy \
  --policy-id p-abc123def \
  --target-id ou-root-example

# Detach SCP from OU
aws organizations detach-policy \
  --policy-id p-abc123def \
  --target-id ou-root-example

# List OUs in organization
aws organizations list-organizational-units-for-parent \
  --parent-id r-abc1

# Move account to different OU
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id ou-source \
  --destination-parent-id ou-destination

aws:RequestedRegion       - Restrict by AWS region
aws:PrincipalArn         - Match principal ARN pattern
aws:PrincipalOrgID       - Ensure principal is in org
aws:PrincipalTag/*       - Match principal tags
aws:ResourceTag/*        - Match resource tags
aws:SourceIp             - Restrict by source IP
ec2:InstanceType         - Restrict instance types
s3:x-amz-server-side-encryption - Require encryption

Related Services

Further Reading

• Service Control Policies Documentation
• SCP Examples Repository
• Best Practices for OUs
• Multi-Account Strategy Whitepaper
• SCP Full IAM Language Support (2025)