Should staging and production use separate AWS accounts?

Use separate cloud accounts for staging and production if any staging human, CI job, or runtime credential could otherwise modify production. That account boundary is usually worth it even for a small team because it gives you a default-deny separation for access, billing, and quotas, and it reduces the blast radius of mistakes. Keep them together only when the workload is very small, production is low risk, and you can prove tight production access controls without relying on convention.

What decision should a small team make?

For most teams running customer-facing production systems on AWS, use one account for staging and one for production. AWS documents an account as an identity, access, and billing isolation boundary, with no cross-account access by default unless you explicitly allow it in policy. AWS also recommends separate accounts for non-production and production when you need distinct controls by environment in its AWS account reference and Organizing Your AWS Environment whitepaper.

The tradeoff is operating overhead: extra IAM roles, account bootstrap, logging, budgets, and a slightly more deliberate deployment path. For a tiny internal tool with little sensitive data and one or two operators, a single account with strong role separation can be acceptable for a while. But that is a temporary simplification, not a durable boundary.

Why is an account boundary stronger than a cluster or namespace?

Namespaces and tags help organize resources. They do not create the same default isolation as separate accounts. If staging and production share an account, a broad IAM permission, a mistaken infrastructure script, or an overpowered CI role can still delete or modify both environments.

An account boundary helps in five practical ways:

• Credential reach: staging credentials do not reach production unless you explicitly grant cross-account access.
• Accidental deletion: a bad Terraform apply or cleanup script is easier to contain.
• Billing ownership: account-level cost allocation and budgets are straightforward.
• Quotas and API rate limits: AWS explicitly calls out distributing service quotas and API request rate limits across accounts.
• Environment policy: production can have stricter guardrails without slowing staging.

If your real requirement is just Kubernetes workload separation inside one product environment, namespaces are fine. If your requirement is preventing staging access paths from touching production, choose separate accounts.

What is the minimum workable design?

A good small-team pattern is simple:

1. Create separate staging and production accounts under one AWS Organization.
2. Put CI in a third shared services account, then let it assume a narrowly scoped deployment role into staging or production.
3. Keep production write access limited to a small on-call or release group.
4. Send logs, CloudTrail, and central billing views to shared organizational tooling if you have it.
5. Store build artifacts in a shared artifact account or registry, but grant production pull or deploy permissions explicitly rather than reusing staging credentials.

The enforced ordering boundary matters here: build once, publish the artifact, then separately authorize deployment into staging and production with different roles. Do not treat “it passed staging” as an automatic right to mutate production.

How can you decide in 10 minutes?

Use separate accounts if you answer yes to any of these:

• Could a staging CI token or developer role currently change production?
• Would deleting the wrong VPC, database, or bucket be a serious incident?
• Do you want separate budgets or cleaner cost ownership?
• Have you hit, or do you expect to hit, service quotas or API limits?
• Does production need stricter IAM, network, or data-access controls than staging?

If all answers are no, one account can be acceptable short term, but set a trigger to split later, such as first external customer data, first on-call rotation, or first shared CI system.

Where should shared artifacts live?

Use a shared artifact location only if access is explicit and environment-specific. For example, one registry can hold images for both environments, while deployment roles in each account control what can actually run there.

How should emergency access work?

Keep emergency production access separate from normal staging access. Use a distinct break-glass role in the production account, protect it with stronger approval and logging, and do not let staging administrators inherit it by convenience.

Next step: map every human and machine credential that can touch staging today; if any of them can also mutate production, split the accounts before your next release.

Reviewed: 2026-09-05