AWS Service Control Policy (SCP) Builder and Simulator - Offline Guardrail Evaluator

First Published:
Last Updated:

Design AWS Organizations Service Control Policies (SCPs), then simulate how they cap permissions across an OU hierarchy - entirely in your browser, with no AWS sign-in and no data sent anywhere.

All processing is performed entirely in your browser using client-side JavaScript. No data is transmitted to any server. Your policies and request details never leave your device.

SCPs are guardrails, not grants. A Service Control Policy sets the maximum available permissions for IAM users and roles in member accounts; it never grants access by itself. This tool models SCP evaluation (explicit deny precedence and inheritance across organizational units) following official AWS documentation as of 2026-06-23 and provides a best-effort approximation. Effective access also depends on IAM identity-based and resource-based policies, permission boundaries, RCPs, and session policies.
  • This tool is provided "AS IS" without any warranties of any kind.
  • This is an approximation of SCP evaluation, not an authoritative decision. Results can differ from real AWS evaluation.
  • SCPs do not affect the management account and do not restrict service-linked roles.
  • Confirm with the AWS Management Console or AWS APIs before relying on results.
  • By using this tool, you accept full responsibility for any outcomes.

This tool uses client-side JavaScript for all processing. No data is transmitted to servers, no files are uploaded online, all processing happens locally in your browser. Once loaded, this tool continues to work even without an internet connection. For more details, please refer to our Web Tools Disclaimer.

Sample Guardrails

Statements

Generated SCP

Example Scenarios

Organization Hierarchy

Order the levels from the organization root down to the target account. Each level can carry one or more SCPs. "Include FullAWSAccess" models the default managed SCP that AWS attaches to every entity; uncheck it to model an allow-list or a removed FullAWSAccess. A request is within the SCP guardrail only when an explicit Allow exists at every level and no level denies it.

Sample Request

Additional Context Keys

Add any other condition context keys referenced by your SCPs (for example aws:PrincipalOrgID). Region and Principal ARN above are added automatically. Use comma-separated values for multi-value keys.

Validate an SCP

Paste a single SCP JSON document. The validator checks SCP-specific syntax rules such as the Allow-only-"*"-Resource constraint, unsupported Principal elements, and common lockout risks. It reports Errors, Warnings, and Info.

About This Tool

Service Control Policies (SCPs) are an AWS Organizations policy type that set the maximum available permissions - a guardrail - for the IAM users and roles in member accounts. Unlike an IAM identity-based policy, an SCP never grants access on its own: a principal still needs an identity-based or resource-based policy that allows the action, and that action must also be left available by every SCP in the path from the organization root to the account. The effective permissions are the intersection of SCPs, resource control policies (RCPs), identity-based and resource-based policies, and permission boundaries.

This tool has three parts. The Builder assembles SCP statements (Effect, Action / NotAction, Resource / NotResource, and Condition) into a formatted SCP document. The Simulator evaluates a sample request against a stack of SCPs attached at each level of an OU hierarchy and shows whether the request stays within the guardrail. The Validator lints a pasted SCP for syntax issues and common pitfalls.

The SCP evaluation rules implemented here were verified against the official AWS Organizations User Guide on 2026-06-23:

Frequently Asked Questions

Do SCPs grant permissions?

No. SCPs set the maximum available permissions (a guardrail). They never grant access. A principal still needs an IAM identity-based or resource-based policy that allows the action, and the action must also be permitted by the SCPs at every level. A user with no IAM permissions has no access even when the SCPs allow everything.

How does explicit deny precedence work?

A matching Deny statement at any single level - the organization root, any OU in the path, or the account itself - blocks the action for that account and every account beneath it, regardless of any Allow statements elsewhere. Explicit Deny always wins.

Why must an Allow exist at every level?

SCP evaluation is deny-by-default. For an action to remain available, an explicit Allow must exist at each level from the root down to the account. That is why AWS attaches the FullAWSAccess managed SCP by default. If you remove it at a level without replacing it with another Allow, everything beneath that level is blocked.

How is an SCP different from an IAM policy?

An IAM identity-based policy grants permissions to a principal. An SCP filters the permissions a principal can ever have. SCPs also have syntax differences: in an Allow statement the Resource element may only be "*" (no specific ARNs), and Principal / NotPrincipal are not supported. Use the aws:PrincipalArn condition key instead of a Principal element.

What does an SCP not cover?

SCPs do not affect users or roles in the management account (even when it is a delegated administrator), and they do not restrict service-linked roles. A few other tasks are also outside SCP control, such as registering for the Enterprise Support plan as the root user and certain AWS-related services. SCPs apply only to member accounts.

Features

  • SCP Builder: Compose statements with Effect (Allow / Deny), Action / NotAction, Resource / NotResource, and Condition, then copy or download a formatted SCP document.
  • Allow constraint enforcement: The Builder locks the Resource element to "*" for Allow statements, matching the AWS rule that Allow statements cannot use specific ARNs.
  • Guardrail presets: Region restriction, deny root-user actions, deny leaving the organization, allowlist specific services, deny a service, and protect a critical IAM role - grounded in official SCP examples.
  • OU hierarchy Simulator: Stack SCPs at each level (root, OUs, account), toggle FullAWSAccess per level, and evaluate a sample request against the full inheritance chain.
  • Correct SCP precedence: Explicit Deny at any level wins; an explicit Allow is required at every level; otherwise the request is an implicit deny.
  • Per-level evaluation trace: See which statement allowed or denied the request at each level, with per-element reasons for Action, Resource, and every Condition operator.
  • Condition operators: String, Numeric, Bool, Date, IpAddress (IPv4 / CIDR), and Arn operators, with IfExists and ForAllValues: / ForAnyValue: modifiers.
  • Validator / linter: Flags unsupported elements, the Allow-Resource constraint, Action and NotAction conflicts, lockout risks, and oversized documents (the SCP maximum is 10,240 characters).
  • 100% client-side: No network calls, no account required, works offline after first load.

How to Use

  1. On the Builder tab, click a Sample Guardrails preset or add statements manually. Set the Effect, choose Action or NotAction, list the actions, and add Conditions as needed. The formatted SCP appears in the Generated SCP box - use Copy SCP or Download JSON.
  2. On the Simulator tab, load an Example Scenario or build your own hierarchy. Add levels from the root down to the account, attach SCPs (paste JSON or click "Use built SCP" to pull the Builder output), and set the FullAWSAccess checkbox per level.
  3. Fill in the Sample Request: the Action, the Resource ARN, the Region, and the Principal ARN. Add any other context keys your Conditions reference.
  4. Click Evaluate Request. The badge shows whether the request is Within Guardrail, Blocked by an explicit Deny, or Blocked by an implicit deny, followed by a per-level trace. Use Copy Result to copy the decision and trace.
  5. On the Validator tab, paste an SCP and click Validate to see Errors, Warnings, and Info for the document.

Related Tools

Related Articles

Important Notes

  • Guardrail, not a grant, and an approximation. Service Control Policies set the maximum available permissions (guardrails); they do not grant access. This tool models SCP evaluation (explicit deny precedence, inheritance across OUs) following official documentation as of 2026-06-23 and provides a best-effort approximation. Effective access also depends on IAM policies, permission boundaries, and session policies - confirm with AWS before relying on results.
  • SCP scope only. The Simulator evaluates SCP effects in isolation. It does not combine SCPs with identity-based policies, resource-based policies, permission boundaries, RCPs, or session policies to produce a final authorization decision. Use the AWS Console or APIs for the authoritative result.
  • Exclusions. SCPs do not affect the management account or service-linked roles, and a small set of tasks (for example registering for Enterprise Support as the root user) are not restricted by SCPs.
  • Approximate matching. Wildcard, ARN, and condition matching are approximations. IP conditions support IPv4 / CIDR only, and policy variables such as ${aws:PrincipalTag/team} are not expanded - provide resolved values via context keys.
  • Document size. The SCP maximum document size is 10,240 characters; when saved in the console, insignificant whitespace is not counted.

References:
Tech Blog with curated related content
Web Tools Collection

Written by Hidekazu Konishi