Finance will keep funding the platform only if teams are charged for what they use, and you choose the unit of charge. Which unit do you propose?

The principle

A price is a signal, and the signal lands on whatever you meter. Before comparing units, decide which behaviour you want more of and which you want less of. A platform wants more frequent small deploys, more questions asked early, and less wasted infrastructure. The unit of charge should tax only the last one.

Why pass-through

Charging each team for the cloud resources its own workloads consume has three properties the alternatives lack. The cost is real - it is money the company actually pays outward, not an internal transfer. It is controllable - the team can act on it by rightsizing, deleting idle environments or changing retention. And it is behaviour-neutral on delivery - nothing about shipping more often costs more.

Two practical rules go with it. Fund the platform team's own labour centrally, never from charge revenue, or the platform starts optimising for billable consumption and quietly loses interest in helping teams shrink their footprint. And start with showback for a quarter or two: the same numbers reported and not billed, which changes behaviour at a fraction of the argument. Expect a measurable share of spend to be unattributable at first - if less than roughly 90% of spend resolves to an owning team, publish the unallocated figure as a number to fix rather than spreading it across everyone.

Why the other options fail

• A fee per deployment. It taxes the single behaviour most strongly associated with healthy delivery. Teams respond rationally by batching changes, which makes each release larger, riskier and slower to diagnose. The stated intention - "think before shipping" - is the giveaway: it is a tax on a behaviour the platform exists to make cheap.
• A fee per support request. It prices asking for help. Requests do not disappear, they turn into workarounds, private tooling and 90 minutes of someone guessing, and the platform loses the queue data that tells it what to build. A queue you can see is an asset; suppressing it does not remove the work.
• A per-seat annual charge. Predictable and easy to invoice, and it carries no marginal signal at all: no action a team takes changes its bill, so nothing about behaviour changes. It is a budget transfer dressed as a price, and it also penalises teams with many engineers and small footprints.

What it costs

Pass-through needs attribution, which needs tagging that is enforced at creation rather than reconciled later, and it produces monthly conversations about shared costs that resist allocation - the mesh, the registry, the log pipeline. Allocate those by a stated rule or leave them central and say so. Attribution work is weeks of platform effort before anyone is billed.

When this is the wrong answer

In a single-product company with one P&L, chargeback mostly moves money between pockets and the attribution effort buys little. Report costs by team and skip the billing. It is also the wrong answer where consumption is not controllable by the team - a mandated security agent on every node is not their choice, and charging for it produces resentment rather than savings.