Shared costs
Shared costs are cloud costs that serve more than one department, product or customer and so have no single direct owner: Kubernetes and platform clusters, networking and egress, security and observability tooling, support plans, enterprise agreements and commitment discounts. They are allocated by a measured usage driver where one exists and by an agreed fixed split where none does.
Shared costs are where chargeback programs are won or lost. They are typically a fifth to a third of the bill, they are the costs recipients least control, and they are where a percentage chosen in a meeting becomes a line on someone’s statement. A workable treatment names each shared category and its default method before the first statement goes out.
A driver is fair when the tenants can influence it and can see it. Requested CPU and memory by namespace for a cluster, with idle capacity carried by the platform budget; bytes scanned or slot time for a shared data platform; bytes by owner for networking where the provider reports them; ingested volume for observability tooling; each consumer’s direct spend for support plans, because that is how the provider prices them.
Where no driver exists, a fixed split agreed in advance and reviewed twice a year is better than a precise-looking driver nobody can verify. Central FinOps, architecture and shared tooling are usually not allocated at all: they are reported as a budget of their own and reviewed on their own merits.
Commitment discounts are a special case. The discounted rate goes to the consumers whose usage the commitment covered, and unused commitment stays central as the cost of the decision to commit, reported to procurement, never spread across consumers who did not make the decision.
Go deeper
Related terms