Blast radius vs cost: how far to split accounts and subscriptions
More accounts means smaller blast radius and cleaner attribution. It also means more baselines, more egress paths, more cross-account traffic, and more discount fragmentation. The right number is the one where isolation value exceeds the separation tax. Here is how to calculate it.
Quick answer
Every additional account adds a baseline of roughly 60 to 250 dollars a month, plus a separate egress path if not centralized, plus cross-account data transfer for anything that used to be local, plus operational overhead. Against that, separation limits blast radius, gives hard quota isolation, and makes attribution exact. Split at boundaries that carry real risk (production versus non-production, regulated versus not, per major business unit) and use tags or namespaces for everything finer.
The multi account conversation tends to run on principle. Isolation is good, so more isolation is better, so every team gets an account, and then every service does. The principle is sound and the arithmetic is ignored, which is how an organization ends up with 300 accounts and a baseline bill that rivals its production workloads.
Account boundaries have a price. Knowing what it is lets you put the boundaries where they actually buy something.
What a boundary costs
| Separation tax | Typical impact |
|---|---|
| Account baseline | About 60 to 250 dollars a month each |
| Dedicated egress path | About 33 to 99 dollars plus per GB |
| Cross-account data transfer | Per GB where traffic was previously free |
| Peering or transit attachments | About 36 dollars per attachment per month |
| Duplicated shared components | Registries, caches, gateways per account |
| Operational overhead | Access, pipelines, audits multiplied |
Transit gateway attachments are the quiet one. At roughly 36 dollars per attachment per month, connecting 60 accounts to a hub is about 2,160 dollars a month in attachment fees alone, before the per GB processing charge on traffic that crosses it.
Traffic that used to be free stops being free
The largest surprise from aggressive separation is data transfer. Two services in one VPC talk over private addresses at no charge within an availability zone. Split them into separate accounts and VPCs and the same conversation crosses a peering connection or a transit gateway, adding per GB processing in both directions.
For a chatty pair moving 20 TB a month, that is a meaningful monthly line that did not exist before the split. Keep tightly coupled services on the same side of a boundary, and if you must separate them, measure the traffic first. The mechanics are covered ininter-AZ data transfer cost.
Where separation genuinely pays
Some boundaries are worth every dollar. Production versus non-production is the clearest: it prevents a misconfigured experiment from touching customer data, and it makes service quota exhaustion in dev irrelevant to production. Regulated workloads versus general ones is similar, because scoping an audit to one account is far cheaper than proving isolation inside a shared one.
Major business units or acquisitions justify separation too, especially where divestiture is plausible, since moving an account is much easier than untangling shared infrastructure. Security tooling and log archive belong in their own accounts precisely so a compromise elsewhere cannot delete the evidence.
Where tags and namespaces do the same job cheaper
Below those boundaries, finer separation usually buys attribution that tags already provide. Two services owned by the same team, in the same environment, with the same compliance posture, rarely need separate accounts. Put them in one account with clear tagging and, if the risk is runtime interference, separate Kubernetes namespaces with resource quotas.
Attribution is the most common reason cited for splitting, and it is the weakest one, becauseconsistent tagging answers it at no infrastructure cost. If tagging is failing, fix the tagging rather than buying accounts to compensate.
Discount fragmentation is real but manageable
Reserved capacity and commitment discounts generally share across an organization when billing is consolidated, so separation does not usually break them. Where it does bite is in per account resources that cannot be pooled, for example a database instance too small to justify a commitment in each of 12 accounts when one larger shared instance would have earned a bigger discount.
Check the consolidation rules for each discount type before assuming either outcome, and keep workloads that benefit from pooled commitments together.
Make the boundary decision with numbers
When a proposal to split arrives, write down three values: the added baseline, the expected cross-boundary traffic in GB per month, and the incremental attachment or peering cost. Compare that total against the risk being mitigated and say whether it is worth it.
Because landing zones and network topology are defined in Terraform, the infrastructure side can be estimated before the split. c3x prices the plan statically with no cloud credentials, so the account baseline, the new NAT or endpoints, and the transit attachment appear as a monthly figure in the pull request that proposes the architecture. Organizations that run this calculation tend to settle on a boundary per environment per business unit, with tags doing the finer work. That shape keeps blast radius small where it matters and keeps the separation tax off the parts of the estate where it buys nothing.
FAQ
What does splitting into more cloud accounts cost?
Each account adds a baseline of roughly 60 to 250 dollars a month, plus a dedicated egress path if egress is not centralized, plus per GB cross-account data transfer for traffic that used to be free, plus about 36 dollars per transit gateway attachment per month, plus duplicated shared components and multiplied operational overhead for access, pipelines, and audits.
Why does account separation increase data transfer cost?
Two services in the same VPC and availability zone talk over private addresses at no charge. Split them across accounts and VPCs and the same traffic crosses a peering connection or transit gateway, incurring per GB processing. For a chatty pair moving 20 TB a month that is a significant new monthly line that did not exist before the split.
Which account boundaries are actually worth the cost?
Production versus non-production, because it stops misconfigured experiments from reaching customer data and isolates service quota exhaustion. Regulated versus general workloads, because scoping an audit to one account beats proving isolation inside a shared one. Major business units where divestiture is plausible. And security tooling and log archive, so a compromise elsewhere cannot destroy the evidence.
Should I create an account per team or per service for cost attribution?
Usually not. Attribution is the most commonly cited reason to split and the weakest one, because consistent tagging answers it at no infrastructure cost. Two services owned by the same team, in the same environment, with the same compliance posture belong in one account with good tags, plus Kubernetes namespaces and resource quotas if runtime interference is the concern.
How do I evaluate a proposed account split?
Write down the added baseline, the expected cross-boundary traffic in GB per month, and the incremental attachment or peering cost, then weigh the total against the risk being mitigated. Because landing zones and network topology are Terraform, C3X can price the new baseline, egress path, and attachments from the plan with no cloud credentials, putting a monthly figure in the pull request that proposes the architecture.
What to do next
Know the price of a boundary before you draw it. C3X estimates Terraform cost statically, no cloud access required. See the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.