A Multi-Account AWS Layout for SOC 2: Dev, Staging, Prod

Use AWS Organizations to hold the accounts, then start with this minimal set:

• Management account: owns the organization, billing and policies. No workloads, very few people with access.
• Security or log archive account: receives organization-wide audit logs and holds security tooling, so someone who compromises a workload account can't erase the trail.
• Production: customer-facing workloads and data. Tightest access.
• Staging: a production-like environment for release testing, with synthetic or scrubbed data.
• Development: experiments and day-to-day engineering, with looser permissions.
• Shared services (optional): container registry, CI runners or network hubs used by all environments.

Use organizational units to apply rules to sets of accounts, for example one for workloads and one for security. Keep the structure small until you have a reason to expand.

Centralize identity. Connect your company identity provider to AWS IAM Identity Center so people sign in once and are assigned roles per account, with no long-lived IAM users. Build role sets by job: developers get broad access in development, read access in staging and none or break-glass in production. Production changes should flow through your deployment pipeline, which assumes a role, rather than through individuals.

Require multi-factor authentication for everyone, keep a documented emergency access process for the management account, and review who holds which role on a schedule. Auditors typically ask for evidence of access reviews, so record each review, including the date, the reviewer and the changes made.

Service control policies (SCPs) set the maximum permissions any account can have, whatever its local admins do. Start with a small set:

1. Deny disabling or altering the organization's audit logging and security services.
2. Restrict use of regions you don't operate in.
3. Deny leaving the organization and creating access keys for the root user.
4. Prevent public exposure defaults, such as turning off account-level Block Public Access.
5. Test each policy in a sandbox organizational unit before attaching it to production.

Then turn on organization-wide logging: a trail that records API activity from every account into the log archive account, configuration recording, and threat detection. The AWS security baseline checklist for a new account lists the basics each account should have.

Auditors test that your controls exist and, for a Type 2 report, that they operated over the period. A multi-account layout gives you clear answers for several common requests:

• Environment separation: production data lives only in the production account, and development can't reach it.
• Change management: production deploys come from a pipeline role, with pull request approval in your code host as the record.
• Logical access: an identity provider assignment list per account shows who can do what.
• Logging and monitoring: an organization trail and alerting configuration prove events are captured and retained.
• Configuration baselines: policy definitions show what's enforced.

A compliance platform such as Vanta can connect to every account and collect much of this evidence continuously. Confirm in a demo how it handles multiple accounts and which checks it runs.

Don't try to move everything at once. Create the organization and the log archive account first, turn on centralized logging, and connect identity. Then create a new production account and move workloads gradually, starting with stateless services, then data stores with a rehearsed migration. Networking and DNS often cause the most surprises, so map connections between services before moving any of them.

Infrastructure as code makes each new account repeatable. Expect the work to take longer than the diagram suggests. Related moves are covered in migrating Next.js from Vercel to AWS, the Heroku to ECS checklist, and the cloud choice in AWS vs GCP vs Azure for startups.