5.2 Service Control Policies (SCPs) & Multi-Account Guardrails

Service Control Policies (SCPs) Mechanics & Evaluation Engine

Service Control Policies (SCPs) are the primary preventative governance mechanism in AWS Organizations. Understanding how SCPs interact with other AWS identity and access management layers is essential for the DOP-C02 exam.

The Guardrail Principle: Boundaries vs. Grants

[!IMPORTANT] Core Rule: An SCP never grants permissions. It specifies the maximum available permissions (a permission boundary) for the accounts or Organizational Units (OUs) to which it is attached.

Even if an IAM user or role inside a member account is assigned the AWS-managed policy AdministratorAccess ("Action": "*", "Resource": "*"), if an attached SCP does not allow an action—or explicitly denies it—the caller cannot perform that action under any circumstances.

   [ Service Control Policy (SCP) ] ── (Maximum Allowed Permissions Boundary)
                   ∩
   [ IAM Permissions Boundary ]      ── (Identity-Level Upper Bound)
                   ∩
   [ IAM Policy (User / Role) ]     ── (Actual Identity Grants)
                   ∩
   [ Resource-Based Policy / Session Boundary ]
                   │
                   ▼
   [ Effective Runtime Authorization ]

Entities Subject to SCPs

• Impacted Entities: All IAM users, federated IAM roles, applications, and the account root user within target member accounts.
• Exempt Entities:
  1. The Management Account: SCPs do not restrict any actions taken within the Organization's Management account, regardless of where policies are attached.
  2. Service-Linked Roles: Predefined roles utilized by AWS services to execute cross-service operations (e.g., AWSServiceRoleForAutoScaling) cannot be blocked by SCPs.
  3. Resource-Based Policies: If an IAM principal in an external AWS account accesses a resource in your member account (e.g., an S3 bucket with a permissive bucket policy), the member account's SCP does not filter that external principal's permissions.

---

Policy Inheritance & Evaluation Logic

AWS Organizations evaluates SCPs hierarchically from the Root, down through parent OUs, child OUs, and finally to the individual Account.

Full-List Authorization & The Default FullAWSAccess Policy

By default, AWS Organizations attaches an AWS-managed SCP named FullAWSAccess to the Root, every OU, and every newly created account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

For an API call to be authorized at the member account level, there must be an explicit Allow present at every single level of the hierarchy between Root and the target account:

$\text{Permitted Actions} = \text{Root Allow} \cap \text{Parent OU Allow} \cap \text{Child OU Allow} \cap \text{Account Allow} - \text{Any Explicit Deny}$

Deny List Strategy vs. Allow List Strategy

[!CAUTION] The Accidental Black Hole: If an engineer detaches FullAWSAccess from an OU before attaching an alternative Allow policy, the effective permission boundary becomes an empty set. Every IAM user, role, and workload in every account beneath that OU immediately loses access to all AWS services.

---

Critical Enterprise SCP Guardrail Patterns

Production landing zones enforce non-negotiable security controls using standardized SCP patterns.

1. Restricting Allowed AWS Regions (aws:RequestedRegion)

To prevent data exfiltration, shadow IT, and unexpected infrastructure spend in unmonitored geographic regions, organizations restrict API activity to designated operating regions (e.g., us-east-1 and us-west-2).

However, naive region-blocking SCPs break global AWS services (IAM, Route 53, CloudFront, AWS Organizations, AWS Support, AWS WAF global) that operate out of us-east-1 or without regional endpoints. The SCP must explicitly exclude global service actions using NotAction:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictAllowedRegionsWithGlobalExclusions",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "acm:*",
        "aws-marketplace-management:*",
        "aws-marketplace:*",
        "aws-portal:*",
        "budgets:*",
        "ce:*",
        "chime:*",
        "cloudfront:*",
        "config:*",
        "cur:*",
        "directconnect:*",
        "ec2:DescribeRegions",
        "ec2:DescribeAvailabilityZones",
        "fms:*",
        "globalaccelerator:*",
        "health:*",
        "iam:*",
        "importexport:*",
        "kms:*",
        "mobileanalytics:*",
        "networkmanager:*",
        "organizations:*",
        "pricing:*",
        "route53:*",
        "route53domains:*",
        "s3:GetAccountPublicAccessBlock",
        "s3:ListAllMyBuckets",
        "s3:PutAccountPublicAccessBlock",
        "shield:*",
        "sts:*",
        "support:*",
        "trustedadvisor:*",
        "waf:*",
        "wafv2:*",
        "wellarchitected:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

2. Protecting Security & Compliance Tooling

To guarantee auditability, member account administrators must be blocked from stopping logging, disabling monitoring, or tampering with centralized security infrastructure:

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

3. Preventing Accounts from Leaving the Organization

To prevent rogue administrators or compromised accounts from detaching from corporate oversight and removing all inherited SCPs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": [
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    }
  ]
}

4. Restricting the Member Account Root User

Best practices demand that all operational tasks be performed via federated IAM Identity Center roles with Multi-Factor Authentication (MFA). The member account root user should have no day-to-day operational capability:

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

5. Enforcing In-Transit Encryption (SSL/TLS)

To satisfy regulatory standards (such as PCI-DSS and FedRAMP), an SCP can enforce that Amazon S3 API requests use HTTPS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceSecureTransport",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

---

Break-Glass Roles and Condition Exceptions

During high-severity operational incidents or infrastructure outages, emergency incident responders (the "break-glass" team) may require temporary, unrestricted access to recover systems or modify baseline infrastructure.

Implementing Safe SCP Exemptions

An SCP containing an unconditional Deny will block even emergency responders. To create an exception, include a Condition block utilizing ArnNotEquals or StringNotLike targeting the designated break-glass role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3BucketDeletionExceptBreakGlass",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteBucketPolicy"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/EmergencyBreakGlassRole",
            "arn:aws:iam::*:role/aws-service-role/*"
          ]
        }
      }
    }
  ]
}

[!TIP] DOP-C02 Exam Trap — Assumed-Role vs. Role ARN Evaluation: When an engineer assumes an IAM role, AWS STS issues temporary credentials where aws:PrincipalArn evaluates to the IAM role ARN (arn:aws:iam::<AccountID>:role/EmergencyBreakGlassRole). However, the session ARN is arn:aws:sts::<AccountID>:assumed-role/EmergencyBreakGlassRole/<SessionName>. The aws:PrincipalArn condition key evaluates the underlying IAM role ARN, making ArnNotEquals on arn:aws:iam::*:role/EmergencyBreakGlassRole work reliably for assumed roles.