All Tools View Categories About Contact Privacy

Service Control Policy (SCP) Generator

Deny-only guardrail templates for AWS Organizations — SCPs set a maximum permission boundary, they never grant anything on their own.

SCPs never grant permissions. Even "Allow *:* on *" in an SCP grants nothing by itself \u2014 it only sets the ceiling of what IAM policies inside the account are allowed to grant. The only genuinely useful pattern is an explicit Deny, which is all this tool builds.
0
statements added
0
chars (no whitespace)
5,120
SCP limit
-
structurally valid

  

About Service Control Policy (SCP) Generator

Service Control Policies use the exact same JSON shape as an ordinary IAM identity policy — Version, Statement, Effect, Action, Resource, Condition — which is precisely what makes them easy to misunderstand. Service Control Policy Generator reuses the same statement-building and validation engine as this site's other IAM policy tools, because the document shape genuinely is identical, but the UI and the copy around it are built to correct the misunderstanding that shared shape invites: an SCP does not grant anything, ever, on its own.

An SCP attached to an AWS Organizations account or organizational unit sets the maximum permissions available inside that account or OU. It is a ceiling, not a floor. A statement reading {"Effect":"Allow","Action":"*","Resource":"*"} inside an SCP grants precisely nothing by itself — every principal in the account still needs its own IAM identity-based or resource-based policy actually allowing whatever it wants to do, and the SCP only decides whether that IAM policy's grant is permitted to take effect at all. This is the single fact most likely to be misunderstood by anyone new to SCPs, and it is the reason this tool does not offer a generic Allow-statement builder the way the ordinary policy tools do.

What SCPs are genuinely, reliably useful for is the opposite: explicit Deny statements that set a hard ceiling no IAM policy anywhere in the account — no matter how permissive, no matter who wrote it — can override. Deny always wins in AWS's policy evaluation logic, and an SCP Deny cannot be overridden by an Allow anywhere else, including in another SCP. That is why this tool leads with three curated, genuinely common Deny templates rather than an open-ended builder. Deny actions outside an approved region list uses a Deny on Action:"*", Resource:"*" with a StringNotEquals condition on aws:RequestedRegion — a standard data-residency and cost-control guardrail that blocks every API call outside your chosen region list, regardless of what any account's own IAM policies say. Deny leaving the organization blocks organizations:LeaveOrganization outright, preventing an account from being detached from central governance. Deny disabling logging blocks cloudtrail:StopLogging, cloudtrail:DeleteTrail, and config:DeleteConfigurationRecorder, closing off the most direct ways an account could silently turn off its own audit trail before doing something it does not want logged.

Templates can be combined — add more than one, and they accumulate into a single Statement array in one document, since a real SCP commonly bundles several unrelated guardrails together.

The size check gets its own dedicated, correctly-labeled treatment rather than reusing the shared policy-size helper used elsewhere on this site. That shared helper reports against IAM's own quotas — 6,144 characters for a managed policy, 10,240 for a role's inline policies, 2,048 for a user's, 5,120 for a group's — none of which is the actual SCP quota, even though one of them happens to share the same number by coincidence. AWS Organizations SCPs have their own, separate 5,120-character limit, and this tool checks against that real limit specifically, under its own label, rather than reusing an IAM-policy-quota name that would misdescribe what is actually being measured. As with AWS's own measurement convention, the check strips whitespace before comparing against the limit — a pretty-printed document is not actually larger for quota purposes than its minified form, and both counts are shown so the difference is visible.

Structural validation is the same check used across this tool category: Version present and recognized, Statement non-empty, and each statement carrying a valid Effect, Action, and Resource. It does not additionally check organization-wide constraints AWS enforces outside a single document, such as the maximum number of SCPs attachable to one account or OU. Everything — template assembly, size checking, and validation — runs locally in your browser; nothing about your organization structure or account IDs is required or collected.

Features

  • Three curated, realistic Deny-only SCP templates — approved regions, prevent leaving the org, prevent disabling logging.
  • Explicit "SCPs grant nothing" messaging built into the UI, not just the FAQ.
  • Templates combine into one multi-statement document.
  • Dedicated 5,120-character SCP limit check, correctly separate from IAM's managedPolicy/roleInline/userInline/groupInline quotas.
  • Whitespace-excluded size counting, matching how AWS actually measures policy size.
  • Reuses the same statement/document/validation engine as the site's other IAM policy tools, since the JSON shape is genuinely identical.
  • Structural validation — Version, Statement, Effect/Action/Resource.
  • Customizable approved-region list for the region-restriction template.
  • Copy as JSON and Download .json.
  • One-click clear.
  • 100% client-side.

How to Use

  1. Pick one or more SCP templates from the list.
  2. For the region template, edit the approved region list if the default does not match your organization.
  3. Click Add for each template you want in this SCP.
  4. Review the combined Statement array.
  5. Check the 5,120-character limit indicator.
  6. Copy or download the JSON.
  7. Attach it to an account or OU in AWS Organizations.

Examples

Example 1 — region restriction alone. Add the "Deny outside approved regions" template with regions us-east-1, us-west-2 — denies every action outside those two regions, account/OU-wide.

Example 2 — governance guardrail bundle. Add "Deny leaving the organization" and "Deny disabling CloudTrail/Config" together — two Deny statements in one document, both independent of any account's own IAM policies.

Example 3 — all three combined. Add all three templates — a single SCP with three Deny statements, well under the 5,120-character limit.

Example 4 — why Allow does nothing. Manually inspecting a hypothetical {"Effect":"Allow","Action":"*","Resource":"*"} SCP statement: the tool's own copy explains this grants nothing without a corresponding IAM policy inside the account — it is why no Allow template is offered.

Example 5 — over the limit. A very long custom approved-region list combined with all three templates could in principle push the document past 5,120 characters (excluding whitespace) — the size indicator flags this with the exact overage.

Benefits

  • Leads with the one thing people get wrong about SCPs — they never grant, only restrict.
  • Three genuinely common, production-realistic Deny guardrails, not a generic open-ended builder.
  • Correct, SCP-specific 5,120-character limit, not a mislabeled IAM-policy quota.
  • Combinable templates for realistic multi-guardrail SCPs.
  • Structural validation before you attach it in AWS Organizations.
  • Private — nothing about your organization is collected.

Frequently Asked Questions

Does an SCP grant any permissions by itself?
No — never. This is the single most important thing to understand about Service Control Policies, and this tool is built to reflect it rather than obscure it: an SCP only sets the MAXIMUM permissions available to an AWS Organizations account or organizational unit. Even a statement with <code>"Effect":"Allow","Action":"*","Resource":"*"</code> grants nothing on its own — every principal in that account still needs its own IAM identity-based or resource-based policy actually granting the permission. SCPs filter what IAM policies in the account are allowed to grant; they are never themselves the source of a grant.
So what is an SCP actually useful for?
Almost entirely for explicit Deny statements — setting a hard ceiling that no IAM policy in the account, no matter how permissive, can override. That is why this tool leads with three Deny-only templates rather than offering an "Allow" builder: a realistic, useful SCP is overwhelmingly a guardrail, not a grant.
What do the three sample templates do?
(1) Deny actions outside an approved region list — denies every action account-wide unless <code>aws:RequestedRegion</code> matches your allowed list, a common data-residency/cost-control guardrail. (2) Deny leaving the organization — blocks <code>organizations:LeaveOrganization</code>, preventing an account from being pulled out of central governance. (3) Deny disabling logging/config — blocks <code>cloudtrail:StopLogging</code>, <code>cloudtrail:DeleteTrail</code>, and <code>config:DeleteConfigurationRecorder</code>, preventing an account from silently turning off its own audit trail.
Why is the character limit shown here 5120, not the same limits as the other IAM policy tools?
Because SCPs have their own AWS Organizations quota, entirely separate from IAM's managed-policy (6,144), role-inline (10,240), user-inline (2,048) or group-inline (5,120-coincidentally-same-number) character quotas. Reusing any of those labels for an SCP would be actively misleading, so this tool runs its own dedicated check against the real 5,120-character SCP limit instead of reusing the shared <code>checkPolicySize</code> helper's IAM-policy labels.
Does the size check count the pretty-printed whitespace?
No — it strips whitespace before comparing to the 5,120-character limit, matching how AWS itself measures policy size against its quotas. A nicely-indented document is not actually "larger" for quota purposes than its minified equivalent; both counts are shown so you can see the difference.
Can I combine more than one of the three templates in one SCP?
Yes — click Add for each template you want, and they accumulate into one Statement array in the same document, checked together against the 5,120-character limit.
Does this tool apply the SCP to my organization or any account?
No — it only builds and validates the JSON document locally in your browser. Applying it requires attaching it to an account or OU in AWS Organizations yourself, via the console, CLI, or IaC.
What does "structurally valid" mean here versus a real SCP-specific validation?
It runs the same structural check used across this tool category — Version present, Statement non-empty, each statement has Effect/Action/Resource. It does not additionally check SCP-specific AWS constraints, such as the maximum number of SCPs attachable per account/OU or organization-wide SCP size quotas beyond the per-policy 5,120 character limit.
Can an SCP Deny statement be overridden by an Allow somewhere else?
No — this is the other key SCP property worth stating plainly: an explicit Deny in an SCP cannot be overridden by any Allow anywhere else, not in the account's IAM policies and not in another SCP. Deny always wins in the evaluation logic, which is exactly why Deny-only SCPs are the durable, reliable guardrail pattern.
Is anything I enter sent anywhere?
No — template assembly, size checking, and structural validation all run locally in your browser.