Cost modelling and chargeback

At some point in the life of every self-hosted virtualisation platform, somebody senior arrives with a spreadsheet from a cloud vendor and asks why the company is doing this itself.

The answer is usually that the platform is substantially cheaper. The problem is that the person defending it typically cannot say by how much, cannot show their working, and produces a number under pressure that is either obviously incomplete — no staff time, no power — or defensively inflated. Either way they lose the argument, and they lose it on presentation rather than on facts.

A cost model is the fix. It is not an accounting exercise and it does not need to be perfect. It needs to be complete, explicit about its assumptions, and reproducible by someone else.

Every component, including the forgotten ones

A worked example, end to end

A three-node hyperconverged production cluster. Every figure is stated so it can be replaced with yours.

The hardware

Annual cost

Sellable capacity is not installed capacity

Here is where most models go wrong, and it is arithmetic rather than judgement.

You bought three nodes so the platform survives losing one. That means you can only commit two nodes’ worth of resources. You bought 184 TB of raw NVMe, and Ceph at size=3 stores three copies, so a third of it is usable — less the headroom you must keep below the full ratio.

The N+1 deduction is the one people resist, because the third node’s resources are physically present and idle. They are not spare capacity; they are the insurance policy. Committing them means that a node failure is an outage rather than a degradation, which converts your availability target into fiction. If it helps, present it as a separate line called “redundancy reserve” so that the cost of resilience is visible rather than hidden inside a lower efficiency figure — that framing tends to end the argument rather than prolong it.

Choosing the allocation unit

Now split €58,503 across the sellable capacity. The question is what to charge for, and the default answer is usually wrong.

Allocating 60% of cost to RAM, 25% to storage and 15% to vCPU:

A typical application VM at 8 vCPU, 32 GB RAM and 200 GB disk therefore costs:

(8 × 17.14) + (32 × 19.05) + (200 × 0.27) = €801 per year, or about €67 per month.

That is a number you can put on a slide, defend line by line, and recompute next year with different inputs.

The cloud comparison, done honestly

You will be asked. Do it properly, because a comparison that overstates your case is worse than none.

Three things to be scrupulous about:

• Include egress on the cloud side. For anything that serves data to the internet or replicates between regions, this is often the line that decides the comparison, and it is absent from most vendor quotes.
• Do not claim cloud eliminates operations. It reduces some categories (hardware, firmware, capacity procurement) and adds others (cost management, IAM, service-specific expertise). Claiming zero is the fastest way to lose credibility with anyone who has run a cloud estate.
• Compare against committed pricing, not list. Anybody serious about moving will negotiate a commitment. Comparing your five-year amortised hardware against their on-demand hourly rate is not an argument, it is a rhetorical trick, and it will be spotted.

set -euo pipefail

# Committed vCPU and memory across every guest in the cluster. The cluster
# resource endpoint reports both without needing to visit each node.
pvesh get /cluster/resources --type vm --output-format json \
| grep -oE '"(maxcpu|maxmem)":[0-9]+' \
| awk -F: '{sum[$1]+=$2} END {for (k in sum) print k, sum[k]}'

# Installed memory per node, for the overcommit ratio.
pvesh get /cluster/resources --type node --output-format yaml \
| grep -E 'node:|maxmem:|maxcpu:'

# Storage allocation against capacity, per storage.
pvesm status

# Ceph raw against usable. MAX AVAIL already accounts for replication and
# for the fullest OSD, which is the figure the model should use.
ceph df detail 2>/dev/null || echo 'not a Ceph cluster'

Validating the model

A cost model that has never been checked against reality is a spreadsheet. Two checks, both cheap:

Reconcile against actual spend. Sum the model’s recurring lines for last year and compare with what finance actually paid for power, colocation, subscriptions and support. If the model is more than about 15% away, an assumption is wrong and it is usually power draw — measured draw at the PDU is almost always different from nameplate, and often much lower.

Sanity-check the utilisation assumption. The rates above assume the sellable capacity is actually sold. At 50% allocation the effective cost per delivered gigabyte doubles. State the assumed utilisation on the same slide as the rate, because it is the single input most likely to be challenged and the one most likely to be optimistic.

Common mistakes

• Omitting staff time, which is usually the largest line.
• Charging against installed capacity rather than sellable capacity, which understates cost by 30–50%.
• Pricing per vCPU on a cluster whose binding constraint is memory.
• Comparing amortised hardware against cloud list price.
• Forgetting egress on the cloud side.
• Ignoring the redundancy reserve, then discovering that the availability target was never funded.
• Never reconciling the model against actual spend.
• Charging back before the platform is big enough to absorb the arbitration overhead.

Key takeaways

• A cost model must be complete, explicit and reproducible; it does not need to be precise.
• Sellable capacity is installed capacity minus redundancy minus reserve, and the difference is large.
• Price the resource that actually runs out. On most Proxmox clusters that is memory.
• Every paid Proxmox tier grants enterprise repository access; tiers differ on support, not on package quality.
• Do the cloud comparison honestly — egress in, zero-operations claims out, committed pricing rather than list.
• Showback changes behaviour at a fraction of the cost of chargeback.

Knowledge check