What do you actually pay twice when production moves into an account of its own, and what stays single?
answer
- configuration doubles, the artifact does not
- setup, access, and every later change
- access is authored again, not copied
- some services charge per account
- shape must match, size need not
basics
~20 sPaid twice: the network and baseline setup, the logging and monitoring wiring, every access grant, some per-account fixed charges, and every later change to all of it. Still single: the built artifact, the repository, the pipeline definition and the team.
solid answer
~50 sEverything that *configures* the account exists twice: the private address plan and subnets, baseline settings, where logs and monitoring data go, and the identity setup. Access is the duplicate people underestimate, because it is not a copy — every person and every pipeline needs a grant in both accounts, and the grants should deliberately differ, broad in non-production and narrow in production. Some services carry a fixed charge per account, so the second account has a floor. The recurring cost is not the first build but every later change, made twice and able to drift apart. What stays single is the thing you are shipping: one artifact built once and promoted into both, one repository, one pipeline definition, one team. That asymmetry — configuration doubles, the artifact does not — is what makes the split affordable at two or three environments and painful at ten.
go deeper
Know that a second account means the surrounding setup exists twice — network, baseline, access — even if very little is running in it.
Distinguish the one-off build from the recurring cost: every later change to the baseline is made twice, and the two copies drift apart if it is not.
Be specific that access is authored again rather than copied, because non-production should be broad and production narrow, and say what drift costs a year in.
Decide where to stop. Name the reason each additional account exists, and be able to defend refusing one when the duplication outweighs the isolation it buys.
## What gets built twice The honest cost of environment separation is not compute; it is the estate around the compute. - **The network layout.** A private address range, its subnets, its routes and its boundary rules exist once per account. The second copy also has to avoid overlapping the first if the two ever need to talk. - **The baseline.** Whatever every account is supposed to start with — where audit records go, which regions are in use, default encryption settings, the monitoring wiring — is set up again. - **Access.** Every person and every automated caller that needs to act in both accounts needs a grant in each. - **Per-account fixed charges.** Some services are priced with a component per account rather than purely per unit of usage, so a second account has a floor under it before anything runs. - **Operational surface.** Two sets of dashboards, two contexts to switch between, two places to look during an incident, and two chances to answer "which account am I in?" wrongly. - **Every later change.** This is the part that is recurring rather than one-off: a change to the baseline is now two changes, and the two copies drift if only one is applied. ## Access is the duplicate that surprises people It is tempting to describe the second account's permissions as "the same grants again", and that is the wrong instinct. The two environments should not have the same access model at all: - In non-production, breadth is cheap and speed matters, so more people hold more permission and self-service is the point. - In production, the grant should be the narrowest thing that still lets the work happen, and standing broad access is the thing you are trying to eliminate. So the work is not copying a set of grants; it is authoring a second, deliberately different one, and keeping both under review as teams change. Budget for that, not for a copy. ## What stays single | stays single | why | |---|---| | The deployable artifact | it is built once and promoted into each account; rebuilding per environment would defeat the purpose of testing it | | The source repository | the code is not per environment; only the configuration it is given is | | The pipeline definition | one definition parameterised per target, rather than one pipeline per account | | The team and its on-call | the split is about blast radius, not about org structure | | Genuinely shared services | an artifact registry or a name zone can sit outside both, on purpose | That asymmetry is the useful mental model. **Configuration doubles; the thing being shipped does not.** If you find yourself duplicating the artifact as well, the split has been done at the wrong layer. ## What the second account does not have to be A frequent objection is that separation means running production twice, at production's size. It does not: 1. The non-production account does not need production's capacity, redundancy posture or reserved capacity commitments. 2. It does not need production's data — a reduced or synthetic dataset is usually better, and avoids exporting real records into a weaker environment. 3. It does not need production's operational apparatus: the same alerting stringency and the same review gates are rarely justified there. What it *does* need to share is **shape**. If the non-production account's layout diverges far from production's, tests stop predicting anything and you have paid the cost of the split without buying the confidence. ## How many environments earn an account Because the cost is per account and recurring, the number of accounts is a real design decision, not a free knob: - **Production alone** is the split almost everyone defends: the credential blast radius argument does all the work by itself. - **A second non-production account** shared by staging and development is usually enough, because a mistake between those two is cheap. - **Further accounts** — per team, per developer sandbox, per regulated workload — are justified by a specific reason: quota contention between teams, an experiment that must be disposable, or data that must not sit beside anything else. - **An account per environment per team** is where the duplication overtakes the benefit unless issuing and configuring an account is close to automatic. The interview answer worth giving names both sides: what the split buys (a boundary the platform enforces) and what it costs (configuration and access, twice, forever), and then says where you would stop.
- Does every environment need an account of its own?No. The split that pays for itself is production against everything else; staging and development can usually share one non-production account because a mistake between them is cheap. Further accounts need a specific reason — quota contention between teams, a disposable experiment, or data that must not sit beside anything else. Each extra account repeats the setup and access cost and adds a place for the baseline to drift.
- Which duplicated item causes the most trouble a year later?The baseline, because it is the one that drifts silently. Setup is applied once per account and then changed piecemeal, so two accounts that started identical diverge on logging destinations, boundary rules and default settings until a test in non-production stops predicting production's behaviour. Access drifts too, but access reviews surface it; nobody reviews a subnet's route table on a schedule.
saying these in an interview costs you the question
- Says a second account is free because you only pay for what you run.
- Expects to copy production's access grants into the new account unchanged.
- Claims the artifact must now be built separately for each account.
- Assumes the non-production account must match production's size and data.
- Counts only the first build and not every later change, made twice.