How to Hand Out Shared AWS Sandbox Accounts Fairly

Engineers need somewhere to try things in AWS that isn't production and isn't the shared dev account everyone's afraid to touch. A sandbox account is the usual answer. The hard part is how many to have, who gets one, how long they keep it, and what happens to everything they left running.

Get it wrong in one direction and you have forty sandbox accounts nobody has cleaned since last year. Get it wrong in the other and three people are fighting over one account and stepping on each other's CloudFormation stacks.

This post covers the three common models, the tooling for each (checked against AWS and project documentation in October 2026), and how to keep the shared parts fair.

The three models

1. One account per engineer

Every engineer gets a personal sandbox account under an AWS Organizations OU with guardrails.

• Pros: no contention, clear cost attribution, people can leave experiments running.
• Cons: account count grows with headcount, idle accounts accumulate resources and cost, and offboarding needs cleanup.

2. A leased pool

A fixed pool of accounts. Engineers lease one for a set time or budget, and the account is cleaned and returned to the pool afterwards.

• Pros: bounded account count, automatic cleanup, fair rotation.
• Cons: more moving parts, and experiments have to fit in a lease.

3. A shared team account

One sandbox account per team that everyone uses.

• Pros: simple, cheap to run.
• Cons: collisions on resource names and quotas, unclear ownership of what's running, and cleanup turns into an argument.

Most organisations end up at model 2 for general experimentation, with model 3 surviving for specific team needs.

Guardrails every model needs

Whichever model you pick, put these in place first.

A dedicated OU with service control policies. SCPs set the maximum permissions available to accounts in an OU. For sandboxes, common restrictions are allowed regions, blocked expensive instance families, and denying changes to the guardrail roles themselves.

Budgets with actions. AWS Budgets can alert at thresholds, and Budgets Actions can respond automatically. AWS announced Budgets Actions in 2020 with three action types: applying an IAM policy, applying an SCP, or targeting specific EC2 or RDS instances to stop. Actions can run automatically or wait for approval. Budgets work from billing data, which isn't real-time, so treat them as a backstop rather than a hard cap.

Account aliases that make purpose obvious. sandbox-07 is better than an account ID nobody recognises, and it matters for cleanup tooling below.

Cleanup: aws-nuke

Reusable sandbox accounts need to be emptied between users. The common open-source tool is aws-nuke, now maintained in the ekristen/aws-nuke fork (the original rebuy-de repository points users there).

Per the project documentation:

• It requires a config file, so it can't run against a random account by accident.
• The config's blocklist must contain at least one account ID the tool will refuse to touch. Put your production and management accounts there.
• It aborts if the account has no alias, and by default refuses accounts whose alias contains "prod".
• By default it only lists what it would delete. You add --no-dry-run to actually remove resources.

A minimal config for one sandbox:

blocklist:
  - "111111111111"   # management account
  - "222222222222"   # production
regions:
  - global
  - us-east-1
  - eu-west-1
accounts:
  "333333333333":     # sandbox-07
    filters:
      IAMRole:
        - "OrganizationAccountAccessRole"

aws-nuke run --config sandbox-07.yaml               # dry run: list only
aws-nuke run --config sandbox-07.yaml --no-dry-run  # delete

Filter out the roles your organisation uses to access the account, or you'll lock yourself out. Only regions listed in the config are processed, so include every region you allow in the SCP.

The full-featured option: Innovation Sandbox on AWS

AWS publishes an open-source solution, Innovation Sandbox on AWS, that implements the leased-pool model end to end. From its documentation:

• Leases: a lease is a temporary allocation of an account to a user for a specified budget or duration. Users can request leases, or managers can assign them directly. A lease can be shared with additional users or groups.
• Lease templates: define approval requirements, budget and duration thresholds with actions, and visibility. Public templates are available for self-service requests; private ones for direct assignment.
• Account pool: administrators add existing accounts to the pool. The solution doesn't create AWS accounts for you.
• Cleanup: when a lease ends, an Account Cleaner uses aws-nuke to recycle the account. Accounts that fail cleanup or drift are quarantined into a restricted OU.
• Access: users and groups come from IAM Identity Center.
• Cost: the solution's own infrastructure has a cost; sandbox usage is billed separately, and AWS states customers are responsible for lease configuration and monitoring spend.

When it fits: you have more than a handful of sandbox accounts, IAM Identity Center is in place, and someone on the platform team can own a deployed solution.

When it's too much: five accounts and fifteen engineers. Deploying and operating a hub account, web UI and cleanup pipeline is a lot for that scale.

The lightweight option: a small pool coordinated in chat

For a small team with a handful of sandbox accounts, a common middle ground is:

1. A pool of, say, four accounts (sandbox-01 to sandbox-04), each in the sandbox OU with SCPs and a budget.
2. A visible lease: who has which account and until when.
3. A scheduled aws-nuke run that cleans any account nobody currently holds.

The visible lease is where a lock bot fits. Lockit is a bot for Slack, Discord and Microsoft Teams that tracks who holds a shared resource and until when. Each account becomes a resource:

@Lockit new

Name it sandbox-03, put the account ID, allowed regions and the console sign-in link in the description, and pick #aws-sandboxes as the updates channel. Then:

@Lockit lock sandbox-03
@Lockit release sandbox-03
@Lockit list

If all four are taken, the person asking sees who holds each and until when, and can click Alert when released to be pinged when one frees up. Ask for takeover sends the holder Release and Approve and Reject Request buttons.

Lock length follows the duration given when locking, else the resource's default, else the workspace default, else 48 hours. For sandbox accounts, a default of one or two working days is a reasonable start.

Cleaning only unheld accounts

On a paid plan, a nightly job can ask Lockit which accounts are free and nuke only those. GET /resources/{name} returns the resource's status, holder and lock end:

#!/usr/bin/env bash
set -euo pipefail
API=https://api.lockitbot.com/api/locky

for acct in sandbox-01 sandbox-02 sandbox-03 sandbox-04; do
  status=$(curl -sS -H "X-API-KEY: $LOCKIT_API_KEY" "$API/resources/$acct" | jq -r '.status')
  if [ "$status" != "locked" ]; then
    echo "Cleaning $acct"
    aws-nuke run --config "configs/$acct.yaml" --no-dry-run --no-prompt
  else
    echo "Skipping $acct (held)"
  fi
done

Test without --no-dry-run first. In aws-nuke v3, --no-prompt (alias --force) skips the interactive confirmation, which a scheduled job needs; older v2 packages behave differently, so check aws-nuke run --help on the version you install. The Lockit API currently works with Slack workspaces only; full reference in the API docs.

Being clear about the limits

Lockit doesn't create AWS accounts, grant or revoke IAM access, enforce budgets or delete resources. It's a visible, expiring record of who holds which account, plus the alerts and takeover flow around it. Access control stays in IAM Identity Center, guardrails stay in SCPs, spend control stays in Budgets, and cleanup stays in aws-nuke. If you need access granted and revoked automatically with each lease, that's what Innovation Sandbox on AWS is built for.

Making it fair

Whatever the tooling:

• Time-box leases. Two working days is a sensible default. Anyone needing longer says so when they lock.
• Clean on return, every time. A sandbox that's only "mostly" cleaned teaches people not to trust the next one.
• Make cost visible per lease. Tagging resources with the holder's name helps, and Innovation Sandbox applies cost allocation tags automatically.
• Have an exception path. Long-running experiments go into a personal account or get promoted to a proper dev account, not parked in the shared pool.

Similar patterns apply to other single-tenant shared things, such as shared test databases and software licences.

Lockit's free plan covers two resources with unlimited locks and members; Starter is $17/month for up to 100 resources with API and MCP access. See pricing.

FAQ

How many sandbox accounts do we need?

Start with roughly one for every three or four engineers who actively experiment, and watch how often people wait. If all accounts are frequently held, add more before tightening lease lengths.

Is aws-nuke safe to run on a schedule?

It's designed with safeguards: a required config, a mandatory blocklist, an alias check and dry run by default. Run it against sandbox accounts only, keep production and management accounts on the blocklist, and dry-run any config change first.

Does Innovation Sandbox on AWS create accounts for us?

No. Its documentation says administrators create the accounts and add them to the pool; the solution then leases, monitors and cleans them.

Can Lockit revoke someone's access when their lock ends?

No. Lockit tracks who holds the account and until when. Granting and revoking access is handled in IAM Identity Center or a tool built for it.