AWS Organizations, OUs and SCPs

By the end of this lesson you will be able to

• Explain why companies run many AWS accounts instead of one, and what an AWS account gives you as a boundary: blast radius, quotas, billing and security.
• Describe an organization: the management account and member accounts, the root, OUs, creating versus inviting accounts, OrganizationAccountAccessRole, leaving and moving accounts.
• Explain consolidated billing: one bill, volume pricing across accounts, and Reserved Instance and Savings Plans discount sharing, including when to turn sharing off.
• Design an OU tree (business unit, environment, project, and the AWS recommended OUs) so that policies follow it.
• Work out what an SCP allows anywhere in the tree: the default FullAWSAccess, deny-list and allow-list strategies, inheritance, and who SCPs do not affect.
• Write the classic SCPs (deny leaving, Region lock, protect logging, block the root user, protect a role) and know their limits.
• Tell SCPs, RCPs, declarative policies and the other policy types apart, and use tag policies correctly, including what they cannot do.
• Share resources across accounts with AWS Resource Access Manager and run security services from a delegated administrator account.

#Why one account is not enough

In chapter 2 you met IAM inside one account. Real companies rarely stay with one. A mobile-banking company in Dhaka may have twenty accounts, a large bank hundreds. The reason is simple: an AWS account is the strongest boundary AWS has. Almost everything is scoped to it:

• Blast radius. A leaked access key, a buggy script that deletes resources, or a developer with too many rights can only damage the account it lives in. A test in the Dev account cannot touch the payment database in the Prod account, because the two share no IAM users, roles or resources unless you deliberately connect them.
• Quotas. Service quotas (Lambda concurrency, EC2 vCPUs, API rate limits) are per account and per Region. A load test or a runaway job in one account cannot eat the quota of another. Lesson 15.2 promised this: separate accounts are the hard way to isolate critical paths.
• Billing. Every account has its own bill lines, so the cost of each team, product or customer is visible without any tagging.
• Security and compliance. Auditors can be told “cardholder data lives only in these two accounts”, which keeps the scope of an audit small. Different accounts can have different rules.

The alternative, one account with many VPCs, keeps everybody inside the same IAM, the same quotas and the same bill. One mistake in an IAM policy can open everything. The slides call this “multi account vs one account multi VPC”, and for anything beyond a small project, AWS recommends multiple accounts.

Many accounts bring a new problem: how do you manage forty sets of users, forty bills and forty sets of rules? That is what this chapter is about. This lesson covers the structure (Organizations, OUs, policies). Lesson 20.2 puts SCPs and RCPs into the complete evaluation flow with conditions and boundaries, and lesson 20.3 gives people one sign-in to all accounts with IAM Identity Center and builds a ready-made organization with Control Tower.

#AWS Organizations

#Management account and member accounts

AWS Organizations is a free, global service that groups AWS accounts into one organization:

• The account that creates the organization becomes the management account. Older documents, the old notes and some API fields (for example MasterAccountId) still say master account: same thing, renamed. It pays the bill, creates and invites accounts, and manages policies. It can never be changed to another account; to change it you would delete the organization.
• Every other account is a member account. An account can belong to only one organization at a time.
• The organization has exactly one root, the top of the tree. Under it you create organizational units (OUs), folders that hold accounts and other OUs. OUs can be nested five levels deep under the root, and an organization can have up to 2,000 OUs. An account sits in exactly one place: the root or one OU.
• A new organization can hold 10 accounts by default (an invitation that is still open counts too). The management account can ask for more in Service Quotas; large companies run thousands. Brand-new organizations sometimes start with a lower quota.

Because the management account is all-powerful and is not limited by SCPs (below), AWS’s advice is to keep it nearly empty: no workloads, very few people, only the organization’s administration and billing.

#Creating and inviting accounts

There are two ways to get an account into the organization.

OrganizationAccountAccessRole is the classic cross-account admin role from lesson 2.4: administrators in the management account call sts:AssumeRole into it. Many companies later replace it with IAM Identity Center permission sets (lesson 20.3) and restrict who may assume it.

#Leaving, removing and moving accounts

• A member account can leave (LeaveOrganization) or the management account can remove it. Either way the account must be able to stand alone: it needs its own payment method, contact details and support plan, and an account created by Organizations must be at least 4 days old.
• Since November 2025, an account can move directly from one organization to another: the new organization invites it, it accepts, and it never becomes standalone in between. Before that, the only way was leave → standalone → accept. Exam questions written earlier describe the old path, which still works.
• Moving an account between OUs inside one organization (move-account) is instant, and the account immediately gets the policies of its new place in the tree. Test the move: a stricter OU can break running workloads.
• The management account cannot leave. To get rid of an organization you remove every member and then delete it.

The exam’s favourite phrase here is “prevent member accounts from leaving the organization”: the answer is an SCP that denies organizations:LeaveOrganization.

#All features or consolidated billing only

An organization runs in one of two feature sets:

• All features (the default for new organizations): consolidated billing plus SCPs, RCPs, tag policies and every other policy type, trusted access for AWS services, and delegated administrators.
• Consolidated billing only: just the shared bill. No policies of any kind.

An old organization that started with billing only can switch to all features. Every invited account must approve the change (accounts that were created inside the organization approve automatically). Once all features are on, you cannot go back. On the exam, if the question needs SCPs, the organization needs all features.

#Consolidated billing

Consolidated billing is on in every organization and costs nothing. It gives three things:

1. One bill, one payment method. Every member’s charges appear on the management account’s invoice. Cost Explorer still shows the costs per account, so each team sees its own spending. Member accounts cannot see each other’s bills.
2. Volume pricing across accounts. Prices that fall with volume (S3 storage tiers, data transfer, some other services) are calculated on the total usage of all accounts, as if they were one. Two teams with 30 TB and 40 TB of S3 Standard each stay in the first 50 TB tier alone; together they have 70 TB, and the last 20 TB are billed at the cheaper next tier.
3. Shared Reserved Instance and Savings Plans discounts. A commitment bought in one account first covers that account’s usage; whatever is left over applies to matching usage in other accounts (lesson 4.4). Nothing is wasted while some account in the organization can use it.

Sharing is on by default, and the management account can turn it off for any account (including itself) in the billing preferences. An account with sharing off neither gives its leftover discount to others nor receives theirs. Use this when a company in the group has its own profit and loss and must not subsidise, or be subsidised by, others.

#Designing the OU tree

OUs exist so that policies can follow the structure. A policy attached to an OU applies to every account and OU inside it. So design the tree around how differently you want to govern things, not around your org chart.

The slides show three common patterns:

They combine: a business-unit OU can contain Prod and Dev sub-OUs. AWS’s own guidance (“Organizing your AWS environment using multiple accounts”) recommends a set of OUs that most organizations end up with:

Others appear as needed: Deployments (CI/CD), Exceptions (an account that needs special rules), Transitional (accounts just moved in from an acquisition), Individual business users.

The slides also list what a multi-account setup lets you do centrally: tagging standards for billing, CloudTrail in every account sending logs to a central bucket in a log account (lesson 19.6), CloudWatch Logs collected in a central logging account, and cross-account roles for administration. All of these are covered below or in lessons 20.3 and 19.6.

#Service control policies

#What an SCP is, and what it is not

A service control policy (SCP) is a JSON policy, with nearly the same syntax as an IAM policy, attached to the root, an OU or an account. It sets the maximum permissions for the IAM users and roles in the affected member accounts. Lesson 2.2 introduced it; here are all the rules:

• An SCP never grants anything. Effective permissions are the intersection of the SCPs and the IAM policies (and boundaries, and RCPs). A user with no IAM policies can do nothing, even if the SCPs allow every action.
• It affects every IAM user and role in member accounts, including the member account’s root user and including administrators with AdministratorAccess. That is what makes it a real guard rail: nobody inside the account can remove it.
• It never affects the management account. Users and roles there are limited only by their own IAM policies, whatever SCP you attach.
• It never affects service-linked roles. The roles AWS services use on your behalf (Auto Scaling, GuardDuty, Organizations itself) keep working, so a strict SCP cannot break AWS’s own integration.
• It only affects principals of your own member accounts. If a bucket policy in a member account lets an outside account read it, an SCP does nothing about that outsider. That gap is what RCPs fill (below).
• A few root-only tasks cannot be restricted by SCPs at all (for example signing up for the Enterprise Support plan as root).

#Inheritance: Allow at every level, Deny anywhere

The tree is Root → OU → sub-OU → account. For a request from a principal in an account, AWS looks at every SCP attached along the direct path from the root to that account:

1. Deny anywhere wins. If any SCP attached at any level of the path denies the action, the request is denied. A Deny on the root reaches every member account; a Deny on an OU reaches everything inside it.
2. Allow at every level. Each level on the path (the root, each OU, the account itself) must have at least one attached SCP that allows the action. If one level has none, the action is denied, even if every other level allows it. With FullAWSAccess everywhere this is automatic; with allow-lists it is the thing you must get right.
3. Then IAM. Only if the SCPs let the action through do the account’s own IAM policies matter, and they must allow it.

Note the asymmetry: a Deny is inherited downwards on its own, but an Allow is not. An SCP allowing EC2 on the root does not give an OU that has detached FullAWSAccess anything; that OU must allow EC2 itself.

#Deny-list or allow-list strategy

Most organizations mix them: deny-list for workloads, an allow-list for the Sandbox OU.

#The slides’ hierarchy example

The slides’ tree is worth working through, because the exam uses exactly this kind of diagram:

In every case, the account’s IAM policies still have to grant the permission.

#Classic SCPs

Deny leaving the organization (attach to the root):

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

Region lock with exceptions for the global services (lesson 2.2 explained why NotAction is needed):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideSingaporeAndMumbai",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "sts:*", "organizations:*", "route53:*", "cloudfront:*",
      "support:*", "budgets:*", "waf:*", "globalaccelerator:*", "health:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1", "ap-south-1"] },
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/break-glass-admin" }
    }
  }]
}

The ArnNotLike condition exempts one emergency role; both conditions must be true for the Deny to apply.

Protect logging and security services:

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

Block the root user of member accounts:

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

Protect a security role in every account, except from the security team itself:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectSecurityAuditRole",
    "Effect": "Deny",
    "Action": [
      "iam:DeleteRole", "iam:UpdateAssumeRolePolicy", "iam:AttachRolePolicy",
      "iam:DetachRolePolicy", "iam:PutRolePolicy", "iam:DeleteRolePolicy"
    ],
    "Resource": "arn:aws:iam::*:role/security-audit",
    "Condition": {
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/security-team-admin" }
    }
  }]
}

Other well-known ones: deny creating IAM users or access keys (people use Identity Center instead), deny buying Reserved Instances outside finance, allow only certain EC2 instance types, deny making S3 buckets public, require IMDSv2.

#SCP syntax and limits

The syntax is IAM’s, with one big exception: SCPs have no Principal or NotPrincipal element, because they always apply to the principals of the accounts they are attached to. To target a principal, use a condition on aws:PrincipalArn, as in the examples. Since September 2025, SCPs support the full IAM policy language: conditions, NotAction, NotResource and specific resource ARNs work in Allow statements too, not only in Deny statements as before. Older material (and the slides) says Allow statements in SCPs can only use "Resource": "*" without conditions; that is no longer true, though the exam may still be written from that time.

#Beyond SCPs: RCPs and declarative policies

#Resource control policies

A resource control policy (RCP), available since November 2024, is the other authorization policy type. Where an SCP limits what your principals can do, an RCP limits what can be done to your resources, by anyone: your own principals, principals in other organizations, even anonymous ones.

• Attached to the root, OUs or accounts, inherited like SCPs, and they also grant nothing.
• RCPFullAWSAccess is attached everywhere when you enable RCPs and cannot be detached, so in practice you write RCPs as Deny statements with "Principal": "*".
• Up to 5 per entity (including RCPFullAWSAccess), 5,120 characters each.
• They apply only to services that support them. The list started with S3, STS, KMS, SQS and Secrets Manager and has grown (DynamoDB, CloudWatch Logs, ECR, Cognito, OpenSearch Serverless and many more by late 2026). EC2 is not on it.
• Like SCPs, they never affect the management account’s resources or service-linked roles, and they do not apply to AWS managed KMS keys.

The typical RCP is a data perimeter: deny access to every S3 bucket, queue, key and secret in the organization unless the caller is in the organization (aws:PrincipalOrgID) or is an AWS service acting for you. Then a developer who writes "Principal": "*" in a bucket policy by mistake does not expose customer documents.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OnlyOurOrgCanTouchOurData",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:*", "sqs:*", "kms:*", "secretsmanager:*", "sts:AssumeRole"],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}

Where SCPs and RCPs sit in the full evaluation order, together with resource-based policies, boundaries and session policies, is in lesson 20.2.

#Declarative policies

Declarative policies (December 2024) do not evaluate API requests at all. They set a configuration of a service for every account they cover, and AWS keeps it that way, even for APIs and features added later. The first one, for Amazon EC2, can enforce for example: IMDSv2 as the default for new instances, block public sharing of AMIs and EBS snapshots, VPC Block Public Access, no serial console access, and only images from allowed providers. Users who try something blocked get a custom error message you write. Unlike SCPs, declarative policies do apply to the management account.

#The other policy types

AWS’s guide now puts every policy type that is not an SCP or RCP into a second category it calls declarative policies (the EC2 policy above is one of them). Each must be enabled on the root before use. The ones you should recognise:

All of these (unlike SCPs and RCPs) also apply to the management account, and you can look up the effective policy of any account: the result after inheritance.

#Tag policies

#What a tag policy does

A tag policy standardises tags across the organization. Tags only help cost reports and access control if everybody writes them the same way: CostCenter, costcenter and Cost-Center are three different keys to AWS, and a cost report grouped by one of them misses the other two.

A tag policy can define, for each tag:

• the exact casing of the key (CostCenter),
• the allowed values (retail, cards, treasury, or a wildcard pattern),
• for which resource types the policy is enforced (ec2:instance, s3:bucket…).

{
  "tags": {
    "costcenter": {
      "tag_key": { "@@assign": "CostCenter" },
      "tag_value": { "@@assign": ["retail", "cards", "treasury"] },
      "enforced_for": { "@@assign": ["ec2:instance"] }
    }
  }
}

Without enforced_for, the policy only reports: the management account (or a delegated administrator) generates an organization-wide tag compliance report in Tag Editor, and EventBridge can react to non-compliant tag changes. With enforced_for, a tagging operation that breaks the rule on that resource type is rejected. Tag policies use inheritance operators (@@assign, @@append, @@remove) so an OU can add values to what the root defined, and you can view the effective tag policy of any account.

#What a tag policy does not do

#Tags, costs and access

Two things build on consistent tags:

• Cost allocation tags. Tag keys must still be activated in the Billing console before they appear in Cost Explorer and the Cost and Usage Report (lesson 1.4). A tag policy keeps them consistent; it does not activate them.
• ABAC (attribute-based access control): IAM policies that compare the caller’s tags with the resource’s tags, for example “you may stop instances whose Team tag equals your own”. A typo in a tag silently breaks such a rule, so tag policies protect it (lesson 20.2).

#Running services across the organization

#Trusted access and delegated administrators

Many AWS services understand Organizations: CloudTrail, Config, GuardDuty, Security Hub, IAM Identity Center, Firewall Manager, AWS Backup, CloudFormation stack sets, IAM Access Analyzer and others. Two switches connect them:

• Trusted access lets the service work across all accounts, for example to turn GuardDuty on in every new account automatically or to create an organization trail in CloudTrail that records every account into one bucket.
• A delegated administrator is a member account that the management account registers to administer a service for the whole organization. GuardDuty, Security Hub and Config are usually delegated to the security tooling account, so the security team works there and nobody needs the management account day to day. SCPs do apply to delegated administrator accounts, because they are member accounts.

Organizations itself can also delegate policy management to a member account with a resource-based delegation policy, so a platform team can manage SCPs without access to the management account.

#AWS Resource Access Manager

With many accounts you often want one copy of a resource used by several accounts. AWS Resource Access Manager shares resources across accounts without copying them. You create a resource share, add resources, and add principals: accounts, OUs or the whole organization.

What is commonly shared:

• VPC subnets (VPC sharing): one network account owns the VPC; application accounts launch their instances, databases and load balancers into the shared subnets. Participants cannot change or delete the VPC, subnets or route tables, or each other’s resources. Subnets can be shared only inside the organization.
• Transit Gateways, so other accounts attach their VPCs to one central hub (lesson 22.6).
• Route 53 Resolver rules (lesson 8.5), prefix lists, IPAM pools, License Manager configurations, Aurora DB clusters, Network Firewall policies, capacity reservations and more.

After the management account turns on sharing with AWS Organizations, shares inside the organization take effect without invitations. A share to an account outside the organization is an invitation that must be accepted.

#What goes wrong

• An admin in a member account gets AccessDenied for something their IAM policy allows. Look above the account: an SCP Deny on the path, or an allow-list level that does not list the service. The error message usually says “with an explicit deny in a service control policy” or “because no service control policy allows”.
• A new SCP on the root breaks production. It reached every member account at once. Test on a staging OU first.
• FullAWSAccess was detached “to tighten things” and everything stopped. Without it a level allows only what its other SCPs list. Every level of every path needs an Allow.
• A Region lock locks admins out of IAM. The Deny used Action: "*" instead of NotAction with the global services.
• A guard rail seems to work in tests but not for one account. That account is the management account, where SCPs never apply. Or the action was performed by a service-linked role.
• The central team cannot get into an invited account. Invited accounts do not get OrganizationAccountAccessRole; someone must create it.
• An account cannot leave or be removed. It lacks a payment method, contact details or support plan for standalone use, it is too new, or an SCP denies leaving.
• Tag reports show compliance, but the bill still has untagged costs. Tag policies do not see untagged resources, and cost allocation tags must be activated.
• An outside account reads a bucket despite the SCPs. SCPs do not limit outsiders; use an RCP or aws:PrincipalOrgID in the resource policy.

#How it is used in system design and on the exam

• Start multi-account. Separate accounts for production, non-production, security logs, shared network and sandboxes. Keep the management account empty. In practice, Control Tower builds this structure for you.
• Guard rails, not gatekeepers. A few SCPs on the root (deny leaving, protect logging, Region lock, block root), stricter allow-lists on Sandbox, a near-total Deny on Suspended.
• Data perimeter. RCPs (or aws:PrincipalOrgID in resource policies) so only your organization can reach your data.
• Central everything. One organization trail, Config aggregator, GuardDuty and Security Hub run from a delegated administrator account; logs in a log archive account nobody can delete from.
• Share, do not copy. Network and DNS resources are shared with AWS Resource Access Manager.

#Try it yourself

From the management account of a test organization (never your company’s real one), with the CLI configured. Organizations is global; its endpoint is in us-east-1.

# What organization am I in? (Note the old "Master" names in the output.)
aws organizations describe-organization
# {
#   "Organization": {
#     "Id": "o-a1b2c3d4e5",
#     "Arn": "arn:aws:organizations::111122223333:organization/o-a1b2c3d4e5",
#     "FeatureSet": "ALL",
#     "MasterAccountArn": "arn:aws:organizations::111122223333:account/o-a1b2c3d4e5/111122223333",
#     "MasterAccountId": "111122223333",
#     "MasterAccountEmail": "aws-root@example.com"
#   }
# }

# The root, then a Workloads OU under it
aws organizations list-roots --query 'Roots[].[Id,Name]' --output text
# r-ab12  Root
aws organizations create-organizational-unit --parent-id r-ab12 --name Workloads
# { "OrganizationalUnit": { "Id": "ou-ab12-cdef3456", "Name": "Workloads", ... } }

# Create an account directly in the organization (asynchronous)
aws organizations create-account --email payments-prod@example.com --account-name payments-prod
# { "CreateAccountStatus": { "Id": "car-0a1b2c3d4e5f", "State": "IN_PROGRESS", ... } }
aws organizations describe-create-account-status --create-account-request-id car-0a1b2c3d4e5f \
  --query 'CreateAccountStatus.[State,AccountId]' --output text
# SUCCEEDED  444455556666
aws organizations move-account --account-id 444455556666 \
  --source-parent-id r-ab12 --destination-parent-id ou-ab12-cdef3456
aws organizations list-accounts-for-parent --parent-id ou-ab12-cdef3456 \
  --query 'Accounts[].[Id,Name,Status]' --output table

# An SCP that denies leaving, attached to the root
aws organizations create-policy --type SERVICE_CONTROL_POLICY --name DenyLeaveOrg \
  --description "Member accounts cannot leave" --content file://deny-leave.json
# { "Policy": { "PolicySummary": { "Id": "p-a1b2c3d4", "Name": "DenyLeaveOrg", ... } } }
aws organizations attach-policy --policy-id p-a1b2c3d4 --target-id r-ab12
aws organizations list-policies-for-target --target-id 444455556666 \
  --filter SERVICE_CONTROL_POLICY --query 'Policies[].Name'
# [ "FullAWSAccess" ]   <- only policies attached directly; the root's DenyLeaveOrg is inherited

# Tag policies: enable the type, attach one, then see what an account really gets
aws organizations enable-policy-type --root-id r-ab12 --policy-type TAG_POLICY
aws organizations create-policy --type TAG_POLICY --name CostCenterTags --content file://tags.json
aws organizations attach-policy --policy-id p-e5f6a7b8 --target-id ou-ab12-cdef3456
aws organizations describe-effective-policy --policy-type TAG_POLICY --target-id 444455556666

# Share a subnet from the network account (run there) with the Workloads OU
aws ram enable-sharing-with-aws-organization          # once, from the management account
aws ram create-resource-share --name shared-app-subnets \
  --resource-arns arn:aws:ec2:ap-southeast-1:777788889999:subnet/subnet-0abc1234def567890 \
  --principals arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-ab12-cdef3456

Then, from the new account (assume OrganizationAccountAccessRole), try aws organizations leave-organization and read the AccessDenied message: it names the service control policy. Detach FullAWSAccess from a test OU after attaching an allow-list, and see which commands start failing.

#Summary

Key points

• An AWS account is the strongest boundary: blast radius, quotas, bills and security rules are all per account. Use many accounts and govern them with AWS Organizations.
• One management account (formerly “master”), many member accounts, each in exactly one organization; a root, OUs up to 5 levels deep; 10 accounts by default.
• Create accounts to get OrganizationAccountAccessRole automatically; invited accounts need it created by hand. Leaving needs standalone details; since November 2025 accounts can move straight between organizations.
• Consolidated billing: one bill, usage summed for volume tiers, RI and Savings Plans discounts shared (can be turned off per account). All features are needed for any policy.
• Design OUs around governance: business unit, environment, project; AWS recommends Security, Infrastructure, Workloads, Sandbox, Policy staging, Suspended.
• SCPs set the maximum for IAM users and roles in member accounts, including the root user; they grant nothing; they never affect the management account or service-linked roles, or outsiders.
• FullAWSAccess is attached everywhere by default (not “deny by default”). A Deny anywhere on the path wins; with allow-lists, an Allow is needed at every level.
• Classic SCPs: deny leaving, Region lock with NotAction, protect logging, block root, protect roles. 10 per entity, 10,240 characters; full IAM language since September 2025; no Principal element.
• RCPs (November 2024) limit what anyone can do to resources in supported services: the data perimeter. Declarative policies set EC2 configuration. Backup, AI opt-out, chat and other policies manage services.
• Tag policies fix key casing and allowed values and can block non-compliant tagging, but do not require a tag: use an SCP with aws:RequestTag / aws:TagKeys or Config required-tags.
• Delegated administrators run GuardDuty, Security Hub, Config and others from a member account. AWS Resource Access Manager shares subnets, Transit Gateways and Resolver rules instead of copying them.

Self-check: Organizations, OUs and SCPs31 questions