AWS Organizational Policy Controls — interactive simulator
Click a scenario in the diagram below and watch which gate blocks the request. AWS organizational policy is a layered system — Service Control Policies (SCPs), Resource Control Policies (RCPs), identity policies, resource policies, VPC endpoint policies — and each one closes a specific class of attack. The simulator makes the layering visible.
Try the four modes — Effective Permissions, Data Perimeter, SCP Demo, RCP Demo — to see how each policy type behaves.
Four modes, explained.
Below is what's happening behind each tab in the simulator above, plus the AWS policy evaluation logic that ultimately decides whether a request goes through.
Effective permissions = the intersection of every layer
When a principal calls an AWS API, the request runs through a deterministic chain of policy checks. The simulator's "Effective Permissions" view shows the conceptual layering. The actual rule, simplified:
Explicit DENY anywhere wins. ALLOW must come from at least one applicable source. Anything outside what's allowed is an implicit deny.
The full evaluation chain
- 01Default deny — every request starts denied unless something allows it.
- 02Service Control Policies (SCP) attached to the principal's account/OU. If any SCP explicitly denies, request is denied. SCPs only filter; they don't grant.
- 03Resource Control Policies (RCP) attached to the resource owner's account/OU. Explicit deny here also wins. RCPs filter what can be done to resources owned by scoped accounts.
- 04Resource-based policy — if the resource has one (S3 bucket, KMS key, SQS queue, Secrets Manager secret). Explicit deny → denied. Explicit allow → contributes to allow.
- 05Identity-based policy — IAM policies attached to the user, role, or group making the call. Same rule: explicit deny wins; explicit allow contributes.
- 06Permission boundary — if attached to the principal, must explicitly allow the action; otherwise denied (acts as a ceiling).
- 07Session policies — if you used
sts:AssumeRolewith a session policy, it's another ceiling for this session. - 08VPC endpoint policy — if the call goes through a VPC endpoint, the endpoint policy must allow it.
Cross-account calls add one more rule: both accounts have to allow it. The calling account's identity policy must allow the call, and the target account's resource policy (or SCP/RCP) must allow it from the external principal.
Why this matters: a single permissive IAM policy doesn't grant access on its own — it has to survive every other layer. That's why SCPs and RCPs are leverage: they live above IAM and can enforce invariants no individual team can override.
Data Perimeter — six concrete trust gaps to close
A data perimeter is AWS's name for a set of always-on guardrails that ensure only your trusted identities access your trusted resources from expected networks. The "Data Perimeter" tab in the simulator walks through the six concrete control objectives.
Every API call asks three trust questions — about the identity, the resource, and the network. Each cuts two ways, giving six cells:
| Perimeter | Control objective | Enforced by |
|---|---|---|
| Identity | Only trusted identities can access my resources | RCP |
| Identity | Only trusted identities allowed from my network | VPC endpoint |
| Resource | My identities access only trusted resources | SCP |
| Resource | Only trusted resources accessed from my network | VPC endpoint |
| Network | My identities access resources only from expected networks | SCP |
| Network | My resources only accessed from expected networks | RCP |
Key condition keys
- ▸
aws:PrincipalOrgID— caller's AWS Organization. Use to deny access from outside your org. - ▸
aws:ResourceOrgID— resource's AWS Organization. Use to deny your principals from touching external resources. - ▸
aws:SourceVpc/aws:SourceVpce— call originated from your VPC / VPC endpoint. - ▸
aws:ViaAWSService— call was made by an AWS service on your behalf (use to exempt those from network conditions). - ▸
aws:SourceIp— caller's source IP, useful for static workloads with known egress.
AWS publishes ready-to-deploy example policies in aws-samples/data-perimeter-policy-examples. Start there before writing your own.
Service Control Policy (SCP)
A Service Control Policy is attached at the AWS Organizations level — to the org root, an OU, or an individual account. It acts as a filter on what IAM principals in scoped accounts can do.
Core rules
- ▸SCPs don't grant permissions. They only filter what IAM allows. A principal can do X only if their IAM policy allows X and no SCP denies X.
- ▸Apply to every IAM principal in the scoped account — IAM users, roles, federated identities. Service-linked roles are exempt.
- ▸Don't apply to the management account by default — always run workloads in member accounts.
- ▸Inherited down the OU tree. An SCP at the root applies to every account in every OU below it.
Two strategies
Deny everything except an enumerated allow set. High security, very high maintenance — every new AWS service requires explicit allow.
Allow everything except specific deny rules. Most common in practice. Use targeted denies for known-risky actions: privilege escalation primitives, security-service tampering, public-resource creation.
Common patterns
- ▸Region pinning — deny all calls outside approved regions.
- ▸Protect security services — deny disabling CloudTrail, GuardDuty, Config, Access Analyzer.
- ▸Block privilege escalation — deny
iam:CreateAccessKey,iam:UpdateAssumeRolePolicy, etc. outside an admin role. - ▸Outbound resource trust — deny touching resources outside your organization (using
aws:ResourceOrgID).
Working examples: aws-samples/service-control-policy-examples.
Resource Control Policy (RCP)
RCPs are the resource-side counterpart to SCPs. They went GA in late 2024. Like SCPs, they're attached at the AWS Organizations level — but they apply to resources owned by accounts in scope, not to identities.
SCP answers: "What can my identities do?" · RCP answers: "What can be done to my resources?"
Why they exist
SCPs only filter calls made by identities in your org. They can't stop an external principal — say, an attacker with valid credentials in their own AWS account — from calling your S3 bucket if the bucket policy allows it. RCPs close that gap. They apply to every caller (yours, theirs, AWS services), and they sit above resource-based policies in the evaluation chain.
Core rules
- ▸Filter, not grant. Like SCPs, RCPs only deny; they never grant access.
- ▸Apply across calling accounts. Whether the caller is in your org or external, your RCP applies.
- ▸Inherited down the OU tree just like SCPs.
- ▸Service support is rolling out. At GA: S3, SQS, SNS, Secrets Manager, KMS, STS. More services follow.
When to use SCP vs RCP
"My identities must never do X" — region restrictions, privilege escalation primitives, exfiltration to non-org resources. Anything keyed off the caller.
"My resources must never be touched by Y" — block external accounts from reading S3, deny non-org callers to KMS, prevent public bucket access. Anything keyed off the resource.
Most mature data perimeters use both: SCPs for outbound trust ("my identities can only call my resources") and RCPs for inbound trust ("only my identities can call my resources"). Examples: aws-samples/data-perimeter-policy-examples.
See how these policies close real attacks.
The simulator above shows the mechanics. The companion field guide walks through a live AI-driven AWS breach end to end — and maps each step of the attack to the architectural gap it exploits and the policy primitive that closes it.
Read the field guide →Built by the team at InstaSecure. We build a guardrails platform for AWS that operationalizes SCPs, RCPs, and data perimeter controls across an entire organization. The simulator and the underlying techniques are AWS-native — everything here is implementable without InstaSecure. If you'd like help operationalizing it, reach out.