Sandbox Accounts & Safe Experimentation

New hires learn AWS SDK calls by making them, not by reading about them. That means they need somewhere real to make mistakes in.

A sandbox account is that place: a low-risk AWS environment where a wrong parameter or an overly broad policy costs nothing but a few minutes of cleanup, instead of a production incident.

Recipe

Give every new hire (or small team of new hires) a dedicated AWS Organizations member account, with a tight budget alarm and no trust relationship back into production.

This is not a new pattern to invent. It reuses the multi-account structure most organizations already run, described in Multi-Account Architecture for AWS SDK Applications. A sandbox is simply one more member account in that same Organization, provisioned the same way as any dev or staging account, just scoped tighter and expected to be noisier.

# --- Python (boto3) ---
import boto3
 
sts = boto3.client("sts")
assumed = sts.assume_role(
    RoleArn="arn:aws:iam::444455556666:role/SandboxDeveloperRole",
    RoleSessionName="new-hire-sandbox",
)
creds = assumed["Credentials"]
sandbox_s3 = boto3.client(
    "s3",
    aws_access_key_id=creds["AccessKeyId"],
    aws_secret_access_key=creds["SecretAccessKey"],
    aws_session_token=creds["SessionToken"],
)
sandbox_s3.list_buckets()  # safe, read-only, scoped to the sandbox account

// --- TypeScript (AWS SDK v3) ---
import { STSClient, AssumeRoleCommand } from "@aws-sdk/client-sts";
import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";
 
const sts = new STSClient({});
const assumed = await sts.send(
  new AssumeRoleCommand({
    RoleArn: "arn:aws:iam::444455556666:role/SandboxDeveloperRole",
    RoleSessionName: "new-hire-sandbox",
  })
);
 
const sandboxS3 = new S3Client({
  credentials: {
    accessKeyId: assumed.Credentials!.AccessKeyId!,
    secretAccessKey: assumed.Credentials!.SecretAccessKey!,
    sessionToken: assumed.Credentials!.SessionToken,
  },
});
await sandboxS3.send(new ListBucketsCommand({})); // safe, scoped to sandbox

In practice, most teams skip the manual assume_role call above and instead configure an SSO-backed profile that resolves to the sandbox account directly, as covered in aws-cli-setup. The AssumeRole mechanics shown here are what happen underneath that profile.

Working Example

A minimal but complete sandbox setup has three pieces:

1. A dedicated member account, created through AWS Organizations, isolated from every production or shared-staging account by default.
2. A scoped IAM role or permission set, granted through IAM Identity Center, that lets the new hire create and delete common resources (S3 buckets, DynamoDB tables, small Lambda functions) but nothing account-wide like billing or org management.
3. A budget alarm, set low (a few dollars is usually enough for learning-scale experiments), that emails the new hire and their manager if spend crosses the threshold.

For a single new hire, this is one account with one role. For a cohort of hires joining together, some teams share one sandbox account with a per-person resource-naming prefix (alex-, jordan-) instead of provisioning an account per person, trading account isolation for lower setup overhead. Either shape works as long as the isolation from production is real.

Deep Dive

The sandbox account earns its value from three properties working together: short-lived resources, budget visibility, and no path back to production.

Short-lived resources matter because a sandbox that accumulates forgotten S3 buckets and unused DynamoDB tables slowly becomes indistinguishable from a real environment, at which point people stop treating it as disposable. Some teams enforce this with tagging and a scheduled cleanup job; others rely on the new hire's own habit of deleting what they create.

Budget visibility matters because cost is the most common blast radius for a beginner's mistake: a loop that creates resources without an exit condition, or a misunderstood pricing model. A tight budget alarm turns "I ran up a surprise bill" into "I got an email within an hour and stopped."

No path back to production matters most. The account should have no cross-account role that trusts it, and its own role should not be trusted by anything that touches real data. This is exactly the blast-radius argument in the multi-account architecture page: account boundaries are the strongest containment AWS offers, stronger than an IAM policy inside a single shared account.

Gotchas

• A sandbox with a trust relationship back to production is not a sandbox. If the sandbox role can assume anything in a production account, the isolation is fake. Audit trust policies, not just the sandbox account's own permissions.
• No budget alarm means no early warning. A forgotten loop or an oversized dataset can run up real cost before anyone notices without one.
• Shared sandboxes without naming conventions get confusing fast. If a cohort shares one account, agree on a resource-naming prefix before anyone starts creating things.
• "Sandbox" does not mean "no review." New hires can still create insecure configurations (a public S3 bucket, an over-broad policy) in a sandbox. It is low-risk, not risk-free, so light review of what gets created is still worth it.

Alternatives

• A shared dev account instead of a dedicated sandbox. Faster to set up, but a new hire's mistake can now affect other engineers' in-progress work, and blast-radius isolation is lost.
• LocalStack or a local AWS emulator. Useful for offline practice with zero cost risk, but it does not exercise real IAM, real signing, or real service quirks, so it is a supplement to a sandbox account, not a replacement for one.
• Time-boxed temporary accounts (AWS Control Tower Account Factory, provisioned and later closed). Good fit for short bootcamps or trainings; more process overhead for an ongoing team that onboards continuously.

FAQs

Related

• Onboarding an AWS SDK Specialist - why sandbox access comes before anything else.
• Team & Onboarding Basics - the first-week checklist that requests this account.
• A 30/60/90 Ramp-Up Path for AWS SDK Engineers - how sandbox work leads into real integration work.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).