COST 2. How do you attribute cost to the team or product that causes it?
Last updated on
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
Section titled “Best practices”COST 2.1Make the resource hierarchy reflect who paysCOST 2.2Decide the structure early, because parts of it are one-wayCOST 2.3Attribute shared costs explicitly rather than leaving them unassignedCOST 2.4Make attribution complete, including what nobody claims
COST 2.1 Make the resource hierarchy reflect who pays
Section titled “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 needs for containment and OPS 1.3 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 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
Section titled “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 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
Section titled “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 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
Section titled “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 and SUS 6 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.
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
Section titled “Related”SEC 2.2Segmentation andOPS 1.3Ownership, which need the same hierarchyCOST 1.4Per-environment modelling, which depends on this separationCOST 8Cost visibility, which delivers the attributed figures to their ownersSEC 1.4andSUS 6, which find the same unclaimed resourcesPERF 3.2Reversibility, the same sorting applied to sizing