Skip to content

PATTERN Cited by 1 source

Sandbox organization for SCP testing

Intent

Run a second AWS Organization dedicated to preflight-testing of SCPs, OU restructurings, and other organization-wide governance changes before applying them to the primary production organization. The sandbox organization is a non-regulatory reason to run multiple organizations — its purpose is to contain the blast radius of a mis-authored SCP so that a typo, an overly-broad deny, or an unintended interaction with a managed service cannot lock out a production workload.

The source quote

The 2026-05-11 AWS Architecture Blog post names this pattern as one of the scenarios where running multiple organizations makes sense:

"Another example might be a global software company that uses a separate organization as a sandbox to develop and test guardrails and SCPs prior to applying them to their primary organization." (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

This is distinct from the other reasons to run multiple organizations (regulated-industry segmentation, M&A, subsidiary autonomy) — it is a governance-safety reason: the sandbox organization's existence is the test harness, not a business- unit boundary.

The problem it solves

SCPs are powerful in ways that make authoring them risky:

  • An SCP applied at the root denies everything below. A typo in a deny statement can take down the whole organization.
  • SCPs interact with managed-service IAM roles. A deny of iam:* at the root inadvertently breaks every AWS service that uses a service-linked role.
  • SCPs can't grant — only ceiling. Once applied, the only way to recover from an over-broad deny is to detach the SCP, which requires the management account to still be reachable.
  • Change-control processes can't easily roll back SCPs in minutes. Unlike code or CloudFormation changes, SCPs don't have a built-in canary-then-rollback mechanism.

Testing a new SCP directly against a production organization's non-prod OU is safer than applying it at the root but still risks:

  • Interaction with SCPs already attached higher in the tree.
  • Interaction with production-like workloads (managed services, cross-account IAM, RAM shares) that exist in the same org.
  • Operator error (attaching to the wrong OU).

The sandbox-organization shape isolates the blast radius to a completely separate trust surface.

What the sandbox organization contains

  • Management account — minimal-privilege admin of the sandbox organization, independent of production.
  • Mirror of the production OU structure — Security, Workloads, Prod, Nonprod, etc. — so SCP inheritance can be tested at each level.
  • Representative member accounts per OU — populated with a curated set of services + workloads that exercise the managed- service-role surface (Lambda, CloudFront, Config, GuardDuty, etc.). Scaled-down to keep billing negligible.
  • Baseline SCPs already in production attached at each level so new SCPs are tested against the current cumulative ceiling, not a blank slate.
  • Automated test harness — workloads that exercise the API surfaces the new SCP touches; pre-SCP-attach and post-SCP-attach test runs diff what broke.

What changes are staged through the sandbox

  • New SCPs before production attachment.
  • SCP amendments that widen or narrow existing policies.
  • OU restructurings (moving accounts between OUs changes their effective ceiling — test the move in the sandbox first).
  • New AWS service enablement — especially services with organization-wide implications (AWS Config, Security Hub, AWS Control Tower integrations).
  • Backup Policies, Tag Policies, AI Services Opt-out Policies — all organization-level policy types benefit from sandbox preflight.

Rollout sequence

  1. Author the change (SCP, OU move, service enablement) in the sandbox organization's Terraform / CloudFormation / organizations API.
  2. Apply it to the sandbox organization.
  3. Run the test harness — confirm representative workloads still work, IAM still evaluates correctly, managed services still run.
  4. Observe for a soak period (days, not minutes — some failure modes only surface under scheduled automation).
  5. Promote the change to the production organization via the same automation.
  6. Monitor production for regression.

This sequence mirrors visibility-before- enforcement and progressive configuration rollout at the SCP altitude, with the sandbox organization playing the role of the pre-production stage.

When the pattern applies

  • Organization size large enough that the cost of a production SCP outage is materially higher than the billing cost of running a sandbox organization.
  • Change cadence high enough that SCP changes happen often (weekly / monthly), justifying permanent sandbox infrastructure.
  • Automation-driven policy changes where a pipeline applies SCPs; the sandbox becomes the pipeline's pre-production environment.

When not to bother:

  • Small fleets with rare SCP changes — the overhead of running a second organization outweighs the risk mitigation. A non-prod OU inside the same organization may be sufficient.
  • Organizations already in many-organization mode for regulatory reasons — one of the existing organizations can double as the sandbox (with appropriate caveats about shared-tenant test data).

Composition with

patterns/start-single-organization-default

The sandbox pattern is one of the explicitly-named valid reasons to deviate from the single-organization default. It does not contradict the default posture — it is a non-regulatory second organization whose only job is to make the primary organization safer.

Rhetorically, the pattern's existence is itself an acknowledgment that even AWS's recommended default doesn't work for every change surface: policies that affect the whole organization can't be safely tested inside the organization they target, so a separate organization is the cleanest workaround.

Caveats

  • The sandbox is not a perfect mirror. The test harness catches the breakages the test harness is built to catch; production-specific interactions (custom managed services, edge- case IAM trust relationships, scheduled automation, partner integrations) may still surface in production.
  • Sandbox organization has its own billing. Billing overhead is typically small (the sandbox's representative workloads consume little) but non-zero; the pattern trades this against the cost of a production SCP outage.
  • Two organizations to keep in sync. Baseline policies / account-baseline configurations / service enablements all have to be replicated into the sandbox organization and kept current with production — operational overhead.
  • Some changes aren't testable this way. Changes that depend on production data (specific workload-role trust relationships, cross-account IAM trusts with external partners) don't have representative analogs in the sandbox.
  • Not a substitute for structured SCP authoring discipline. The pattern reduces the consequences of mistakes but doesn't eliminate the need for peer review, linting, and structured deployment.

Seen in

  • sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations — canonical naming of the sandbox-organization-for-SCP-testing pattern as one of the scenarios that justifies running multiple organizations, orthogonal to the regulated-industry / M&A / subsidiary-autonomy use cases that otherwise drive the multi- organization shape. First wiki canonicalisation of this pattern.
Last updated · 542 distilled / 1,571 read