TL;DR · Key Takeaways
- VCF Operations Cost Management turns invisible infrastructure spend into a per-workload number you can show.
- Start with showback, which shows a team its cost, and earn your way to chargeback, which bills it.
- Cost is built from measured resource consumption plus a rate card, so the honest version shows the method, not just a figure.
- A per-VM cost you can defend beats a precise one nobody trusts, so publish the assumptions next to the number.
For years the cost of a VM was a shrug. Someone bought hosts, someone bought storage, the finance team saw a big capital number once a year, and nobody could say what any single workload actually cost to run. Then licensing changed, budgets tightened, and leadership started asking the question that used to be unanswerable: who is spending this, and on what. VCF Operations Cost Management exists to answer it, and this part is the operations engineer’s guide to giving a straight answer instead of a guess.
What a VM actually costs
The first honest thing to say about cost is that a VM does not have a price tag. Its cost is built from several layers that most people never see: the compute it consumes on a host, the storage it sits on, the network, the licensing attributed to its cores and vSAN capacity, and a share of the power and facilities behind all of it. VCF Operations models this with cost drivers, the mechanism that attributes expense to the things that generate it. Skip the layers and you get a number that feels precise and is wrong; include them and you get a number a finance team will trust.
This is why two identically sized VMs can cost very differently. One sits on premium all-flash storage in a cluster with spare capacity reserved for HA; the other sits on cheaper capacity in a densely packed cluster. Same vCPU and RAM, different cost, because the stack underneath them differs. If your cost story cannot explain that, it is not ready to show anyone.
The layered view also settles the oldest argument in cost allocation: fixed versus variable. Some of a VM’s cost is fixed the moment it exists, a slice of licensing and reserved capacity it holds whether it runs or sleeps, and some is variable with what it actually consumes. Public cloud trained everyone to think cost is purely variable, pay for what you use, but an on-premises platform is mostly fixed cost you have already committed. That is why an idle VM on your own hardware is not free the way an idle cloud function is; the hosts, the licenses and the HA headroom are already bought. Cost drivers let you show both parts honestly, which is the difference between a number a team argues with and a number a team acts on.
Showback vs chargeback
VCF Operations supports both showback and chargeback, and the difference is more cultural than technical. Showback distributes cost based on actual usage and shows each team what it consumed, without moving any money. Chargeback goes further: it bills tenants or application teams against pricing policies, the rate cards you define. Showback is a mirror. Chargeback is an invoice. They use much of the same machinery, but they land in the organization very differently.
| Aspect | Showback | Chargeback |
|---|---|---|
| Purpose | Visibility and behavior change | Actual billing to teams/tenants |
| Money moves | No | Yes |
| Needs a rate card | Optional | Yes, agreed with finance |
| Political cost | Low | High |
Here is my opinion, and it is a strong one: start with showback and do not rush to chargeback. Showback changes behavior without a fight, because when a team sees that its idle test estate costs as much as a small production app, it cleans up on its own. Chargeback, launched too early, becomes a war over whose numbers are right and stalls for months. Earn trust in the numbers with showback first; only then wire up rate cards and bill.
Rate cards, cost analysis and realized savings
When you are ready for pricing, rate cards are where you set base rates per unit of consumption: compute for CPU and memory, storage, network, guest OS, tags, one-time fixed costs, and rate adjustment factors. Crucially, rate cards align with the current VCF licensing model, so you can attribute expense against cores and storage capacity in TiB rather than a made-up unit. That alignment is what makes the numbers defensible when finance checks them against the actual license spend.
Cost analysis is where the value shows up for operations. You can compare cost to run against price to chargeback, find the high-cost areas, and see where money is going that returns nothing. VCF Operations also tracks potential savings from its recommendations and, importantly, realized savings once you act, so you can prove the reclamation and rightsizing work from the next part actually moved the number. A savings figure nobody can verify is marketing; a realized-savings figure tied to specific actions is a budget conversation you win.
Cost visibility runs on tags
None of this works without allocation, and allocation runs on tags. If workloads are not tagged by team, application or environment, cost lands in an undifferentiated pile and every showback report says shared. The unglamorous prerequisite for cost visibility is a tagging discipline: every VM carries an owner and a purpose. This is the same tagging that drives placement and custom groups elsewhere in the platform, which is why getting it right pays off in three places at once. If your cost project is stalling, the cause is almost always tags, not the cost engine.
Cost to run versus price to charge
Two numbers sit at the heart of cost analysis and they are easy to confuse. Cost to run is what a workload actually costs you: the real infrastructure spend attributed through cost drivers. Price to charge is what you bill for it through a rate card, which may include margin, rounding, or a deliberate incentive. VCF Operations lets you compare them side by side, and the gap between them is a management decision, not an accident. A provider builds in margin; an internal platform team might price at cost to stay neutral, or price slightly above to fund a refresh.
Watching both together is what stops two failure modes. If price sits far below cost, the platform quietly loses money on every workload and nobody notices until the budget blows. If price sits far above cost with no reason, teams route around you to public cloud and you have priced yourself out of your own datacenter. The comparison view is where you catch either drift early, while it is still a slider adjustment and not a crisis.
Report on a cadence, not on demand
Cost visibility only changes behavior if it arrives regularly and lands with the people who can act. A cost report that someone has to remember to open is a report nobody reads. Use the reporting and views machinery from Part 4 to schedule a monthly per-team cost summary, built from a scoped view so each team sees its own estate and not the whole fleet. The goal is a short, boring, recurring email that makes waste visible on a schedule. When the same team sees its idle number three months running, the third month is when it finally acts, and a scheduled report is what gets you to that third month without nagging anyone.
Worked example: the idle test estate nobody costed
A test-and-dev group runs 60 VMs that average 8 percent CPU. Under demand thinking they feel free. Cost Management tells a different story: each VM still commits a share of host compute, sits on storage, and carries licensed cores whether it runs hard or not. Suppose the fully loaded cost lands near a modest figure per VM per month; 60 near-idle VMs then cost about the same as a dozen busy production workloads, purely to keep the lights on for machines nobody is using. Showback puts that single number in front of the team, tagged to them, and within a month they power off or reclaim two-thirds of it. Nobody billed anyone. The number did the work. That is the realized saving you then report, tied to the specific VMs retired.
FAQ
Should we start with showback or chargeback?
Showback, almost always. It changes behavior without moving money or starting a political fight, and it lets you prove the numbers are right before anyone is billed. Move to chargeback only once the figures are trusted and a rate card is agreed.
Why do two identical VMs show different costs?
Because cost is a stack, not a size. Storage tier, cluster density, HA reservation and licensing all differ underneath. Cost drivers attribute those layers, which is exactly why the numbers are useful.
What do rate cards let me price on?
Base rates per unit for compute (CPU and memory), storage, network, guest OS, tags, one-time fixed costs and rate adjustments, aligned to the current VCF licensing model so you can attribute by cores and vSAN TiB.
Our cost reports all say shared. Why?
Tagging. If workloads are not tagged by owner and purpose, cost cannot be attributed and lands in a shared pile. Fix tagging before you blame the cost engine.
How is this different from the FinOps series?
This part is the tooling: how VCF Operations makes cost visible and billable. The VMware FinOps series covers the wider practice, licensing strategy and TCO modeling. They cross-link; use both.
Where this leads
Cost visibility is tags plus a full-stack cost model plus the discipline to show before you bill. My verdict: tag everything, run showback until the numbers are trusted, and report realized savings against named actions. The cost view tells you where money is wasted; the next part turns that into recovered capacity through rightsizing and reclamation.
Treat cost as a monitoring signal, not an annual event. The same platform that pages you when a host is sick can show you, every month, which team is quietly spending on machines it forgot about. That reframing is the whole point: cost stops being a finance report that lands too late to change anything and becomes an operational metric you watch alongside capacity and performance. An operations team that owns the cost number as well as the uptime number is one that leadership stops second-guessing, because it can answer the two questions that always come together, is it healthy and is it worth it.
By the numbers: the idle estate showback makes visible
An illustrative test and dev estate, costed honestly.
| Showback line | Example figure |
|---|---|
| Test and dev VMs | 60 |
| Average CPU used | 8 percent |
| Cost charged while idle | 100 percent of allocation |
| Equivalent busy workloads | about a dozen production VMs |
| Reclaim move | power off or rightsize the idle 60 |
« Previous: Part 7 | VCF 9 Operations Complete Guide | Next: Part 9 »
References
- Cost and Capacity Management, VCF 9.0 (Broadcom TechDocs)
- Operations in VMware Cloud Foundation 9.0: Cost Management (VCF Blog)
- Realized Cost Savings Dashboard, VCF 9.0 (Broadcom TechDocs)
About The Author
DrJha