---
id: COST02
pillar: cost-optimization
title: COST 2. How do you attribute cost to the team or product that causes it?
description: An aggregate invoice changes nobody's behaviour. Attribution is structural rather than analytical, and on STACKIT the structure has one-way doors in it.
status: draft
services: []
sidebar:
order: 11
label: Cost attribution
source_url: "https://framework.stackit.cloud/architecture/pillars/cost-optimization/cost-02-cost-attribution/"
source_file: "docs/architecture/pillars/cost-optimization/cost-02-cost-attribution.mdx"
---
Everything else in this pillar depends on this question. An invoice saying the platform cost a
certain amount last month is a report. One saying which product, which environment and which team
caused each part of it is an engineering input, and it reaches the people who can act on it.
The reason it gets deferred is that it is organizational work rather than technical work, and the
reason deferring it hurts is that the structure it needs is expensive to change later. On STACKIT
parts of it cannot currently be changed at all.
## Best practices
- [`COST 2.1`](/architecture/pillars/cost-optimization/cost-02-cost-attribution/#cost-21-make-the-resource-hierarchy-reflect-who-pays) Make the resource hierarchy reflect who pays
- [`COST 2.2`](/architecture/pillars/cost-optimization/cost-02-cost-attribution/#cost-22-decide-the-structure-early-because-parts-of-it-are-one-way) Decide the structure early, because parts of it are one-way
- [`COST 2.3`](/architecture/pillars/cost-optimization/cost-02-cost-attribution/#cost-23-attribute-shared-costs-explicitly-rather-than-leaving-them-unassigned) Attribute shared costs explicitly rather than leaving them unassigned
- [`COST 2.4`](/architecture/pillars/cost-optimization/cost-02-cost-attribution/#cost-24-make-attribution-complete-including-what-nobody-claims) Make attribution complete, including what nobody claims
---
## COST 2.1 Make the resource hierarchy reflect who pays
**Risk if not established:** Medium
Attribution is a property of how resources are organized rather than something derived afterwards.
If the hierarchy does not distinguish two products, no analysis can separate their costs.
Three axes usually need to be separable: **product or service**, **environment**, and **team**. In
most organizations two of those coincide, which simplifies the structure. Where all three are
independent, the hierarchy has to carry the one that matters most for decisions, and that is
usually the one that owns a budget.
This is the same structure [`SEC 2.2`](/architecture/pillars/security/sec-02-segmentation/#sec-22-structure-the-resource-hierarchy-so-it-can-carry-the-boundaries-you-need) needs for containment and [`OPS 1.3`](/architecture/pillars/operational-excellence/ops-01-shared-ownership/#ops-13-define-ownership-so-that-every-component-has-a-name-against-it) needs for ownership. One
decision serves three pillars, which is the strongest argument for spending time on it rather than
naming the first project after whatever was being built that week.
**On STACKIT.** The Cost
Dashboard breaks costs down
**per project**. That single fact determines the design: the project is the attribution unit, so
anything you want to see separately has to be in its own project.
The Resource Manager
provides the hierarchy, with two documented limits that shape it. There are up to 2,500 projects
per organization, so a
project per product per environment stays well inside the limit.
And **each customer account has exactly one organization**, so the organization is not an axis you
can separate along.
Folders group projects, and folder functionality depends on a feature flag, so confirm it is
enabled for your account before designing a structure that assumes them.
Resource labels are not a cost dimension you can design on today. The project is the unit of
attribution, which makes the structure above this paragraph the whole answer rather than half of
it. Revisit it if that changes: a project split you regret is easier to justify than an
attribution you never had.
**Tradeoffs.** **Operational Excellence.** More projects means more to manage, more grants, and
cross-project access that has to be arranged rather than being implicit. That friction is also the
containment [`SEC 2`](/architecture/pillars/security/sec-02-segmentation/) wants, so it is paid once for two purposes.
**Verify.** Can you say what each product cost last month, across all its environments, without
manual work? If not, what would have to change in the hierarchy?
---
## COST 2.2 Decide the structure early, because parts of it are one-way
**Risk if not established:** High
Hierarchies that grow organically are corrected by moving resources, which is disruptive in
proportion to how long you waited. Some corrections are not available at all.
Sort the decisions before making them, in the same way [`PERF 3.2`](/architecture/pillars/performance-efficiency/perf-03-service-selection-and-sizing/#perf-32-establish-which-sizing-decisions-are-reversible-before-you-make-them) sorts sizing. Some are a
setting. Some require recreating a resource. Some cannot currently be undone, and those deserve
the design time.
The general rule that follows: where a boundary might be needed later, creating it now is cheap
and creating it later is not. A project that turns out to be unnecessary can be merged
conceptually by reporting on it alongside another; two products sharing a project cannot be
separated retrospectively at all, because the cost data was never distinguished.
**On STACKIT.** Three constraints belong in the design conversation rather than being discovered.
**Projects cannot be moved between organizations.** With one organization per customer account
this rarely binds, and it does bind during a reorganization or a divestment.
**Each project links to exactly one billing
account, and projects
cannot currently be reassigned to a different one.** Combined with one billing account per
customer account today, that means cost separation by department cannot currently happen at the
billing level. It happens through the project structure and the per-project view in the dashboard.
**The roadmap changes both.** The same page states that multiple billing accounts and project
reassignment are planned. A structure designed today should therefore be one that benefits when
those arrive rather than one that depends on them.
**Tradeoffs.** **Cost Optimization**, against itself: more projects means less resource sharing
and some duplicated fixed costs. That is the price of being able to see where the money goes.
**Verify.** For each product in your estate, is its cost separable from every other product's
today? For the ones where it is not, what would separating them now require?
---
## COST 2.3 Attribute shared costs explicitly rather than leaving them unassigned
**Risk if not established:** Medium
Every estate has costs that serve everyone: the network, the shared cluster, the observability
stack, the container registry, the identity infrastructure. Left unattributed they become a pool
nobody owns, and an unowned pool only grows.
Choose a method and state it, because any method is better than none and the arguments about which
is fairest never conclude. Split evenly across consumers, split by a usage proxy, or leave it
centrally owned with a named owner and a budget.
The important property is not fairness but that somebody is accountable for the total. A shared
cost with an owner gets reviewed; one distributed across everyone gets reviewed by nobody.
Watch for shared components that grew from a convenience into a substantial line item. A cluster
that was created for one team and now hosts six is a shared cost whether or not anyone decided it
was.
**On STACKIT.** Shared infrastructure in its own project makes the total visible in the
Cost Dashboard, which is
the prerequisite for anybody owning it. How it is then split across consumers is your accounting
rather than a platform capability.
Where a shared component is a cluster hosting several teams' workloads, the platform sees one
project and one cost. Splitting that requires a usage proxy from inside the cluster, which is your
instrumentation under [`OPS 7`](/architecture/pillars/operational-excellence/ops-07-observability/) rather than cost data.
**Tradeoffs.** **Operational Excellence.** A split method is a thing to maintain and to argue
about at budget time. A central owner is simpler and concentrates the incentive in one place,
which works when that owner can actually influence consumption.
**Verify.** List your shared costs. For each, who owns the budget, and how is it split across the
teams that use it?
---
## COST 2.4 Make attribution complete, including what nobody claims
**Risk if not established:** Medium
Partial attribution understates every product it does cover and hides the part that matters. The
unattributed remainder is where the abandoned environments, the forgotten proof of concept and the
resources of people who have left accumulate.
Reconcile against the total. If the attributed costs do not add up to the invoice, the difference
is a finding rather than a rounding error, and it usually resolves into resources nobody claims.
Those resources are the same list [`SEC 1.4`](/architecture/pillars/security/sec-01-security-baseline/#sec-14-cover-the-whole-estate-including-the-parts-nobody-claims) and [`SUS 6`](/architecture/pillars/sustainability/sus-06-shut-down-idle/) produce. Assigning an owner or deleting
them serves cost, security and sustainability at once, which makes it unusually easy to justify.
Set the expectation that everything has an owner. A resource whose owner cannot be identified is a
resource that will not be patched, monitored or reviewed, and its cost is only the most visible of
its problems.
**On STACKIT.** The Resource Manager
hierarchy is the enumeration, and every resource resides within a project, which means there is nothing outside the hierarchy to miss. The reconciliation is
therefore between projects you have assigned to an owner and projects that exist.
The Cost API
retrieves cost data per project and per customer account, which is what makes the reconciliation a
scheduled report rather than a manual comparison, and a good candidate for [`OPS 10.2`](/architecture/pillars/operational-excellence/ops-10-toil-elimination/#ops-102-automate-what-recurs-starting-with-the-riskiest-rather-than-the-most-frequent).
**Tradeoffs.** Little beyond the effort. The uncomfortable part is organizational: some projects
will have no willing owner, and resolving that is a conversation rather than a technical task.
**Verify.** Add up the costs you can attribute to an owner. What proportion of the invoice does
that cover, and what is in the remainder?
---
## Related
- [`SEC 2.2`](/architecture/pillars/security/sec-02-segmentation/#sec-22-structure-the-resource-hierarchy-so-it-can-carry-the-boundaries-you-need) Segmentation and [`OPS 1.3`](/architecture/pillars/operational-excellence/ops-01-shared-ownership/#ops-13-define-ownership-so-that-every-component-has-a-name-against-it) Ownership, which need the same hierarchy
- [`COST 1.4`](/architecture/pillars/cost-optimization/cost-01-cost-model/#cost-14-model-per-environment-rather-than-once-for-the-workload) Per-environment modelling, which depends on this separation
- [`COST 8`](/architecture/pillars/cost-optimization/cost-08-cost-visibility/) Cost visibility, which delivers the attributed figures to their owners
- [`SEC 1.4`](/architecture/pillars/security/sec-01-security-baseline/#sec-14-cover-the-whole-estate-including-the-parts-nobody-claims) and [`SUS 6`](/architecture/pillars/sustainability/sus-06-shut-down-idle/), which find the same unclaimed resources
- [`PERF 3.2`](/architecture/pillars/performance-efficiency/perf-03-service-selection-and-sizing/#perf-32-establish-which-sizing-decisions-are-reversible-before-you-make-them) Reversibility, the same sorting applied to sizing