- Cost, pricing and billing in VCF 9 live in VCF Operations, not in VCF Automation and not in the old VMware Cloud Director. Automation surfaces the bill; Operations calculates it.
- Two pricing card types: rate-based (you set the rates) and cost-based (Operations derives price from cost drivers). VMware Cloud on AWS objects only support rate-based.
- Showback tells a team what it consumed; chargeback turns that into a bill tied to an organization or a region quota.
- The pricing hierarchy has a trap: a VM under the VCF Automation hierarchy is priced by Automation, and it drops out of its vCenter or cluster policy entirely.
- Price recalculates on a 24-hour cycle. A new card or a fresh deployment is never billed instantly.
Who this is for: Provider and platform admins who own tenant billing, plus the IT-finance or FinOps people who have to defend a showback number to a business unit.
Prerequisites: A deployed VCF Fleet with VCF Operations and VCF Automation integrated, at least one organization (VM Apps or All Apps), and the context from Part 5 (licensing), Part 8 (projects) and Part 24 (multi-tenancy design).
The first pricing card most admins build is in the wrong product. They open VCF Automation (the service formerly called VMware Aria Automation, and before that vRealize Automation), go looking for a cost tab, and find nothing useful. The pricing engine is in VCF Operations. Automation is where a tenant sees a bill; Operations is where that bill is built. Get that split wrong and you waste a day hunting for a screen that does not exist.
This is also the part of VCF 9 that quietly absorbed an entire product. In older releases, service providers ran pricing, billing and dashboards through VMware Cloud Director. In VCF 9 those jobs move into the VCF Operations plus VCF Automation pair. If you are coming from a vRA 8.x or VCD background, the muscle memory is wrong, and the new model is worth learning carefully before you promise a tenant a monthly invoice.
Where cost actually lives in VCF 9
VCF Operations is the central hub. It pulls data through Management Packs, one per source: a VCF Automation management pack, a vCenter management pack, an NSX management pack. Each has a one-to-one relationship with its component. Operations meters the consumption, applies your pricing policy, and produces cost, showback and chargeback figures. VCF Automation then exposes the resulting bills to the right tenant roles. The integration is one-to-one: one VCF Automation instance binds to exactly one VCF Operations instance, and Operations collects from Automation by default once the Fleet is up.
The practical consequence: if you want a tenant to see a bill, you do not configure anything in Assembler or Service Broker. You configure pricing and generate bills in VCF Operations, and the tenant reads them in the VCF Automation Organization portal. Two products, one workflow.
Pricing cards: rate-based vs cost-based
A pricing card is how you put a number on a resource. VCF Operations gives you two kinds, and the choice is not cosmetic. It decides whether your price tracks reality or tracks a published rate.
Cost-based: derive price from what it costs you
A cost-based card builds the price up from cost drivers: server hardware, storage, licenses, applications, maintenance, labor, network, facilities, and any extra costs you add. Operations works out the cost to run a VM, then you layer price on top through upcharges, profit and service charges. Cost is your expenditure; price is what you charge. This is the right model when finance wants the bill anchored to real spend and you can keep the cost drivers current. One caveat that bites people: cost-based policy is ignored for VMware Cloud on AWS objects, and the calculated price comes back as zero.
Rate-based: publish a rate and charge it
A rate-based card ignores your internal cost and charges a rate you define per element: so much per vCPU, per GB of memory, per GB of storage, plus any base charge. This is the model providers reach for, because a tenant wants a predictable price list, not a window into your hardware amortization. Rate-based is also the only model that works for VMware Cloud on AWS resources.
| Dimension | Rate-based card | Cost-based card |
|---|---|---|
| Price source | Rates you define per element | Cost drivers plus upcharge/profit |
| Best for | Provider price lists, predictable tenant bills | Internal IT anchored to real spend |
| VMware Cloud on AWS | Supported | Not applied (price reports zero) |
| Maintenance burden | Update the rate list | Keep every cost driver current |
| Assignment | vCenter or Cluster | vCenter or Cluster |
In practice: I tell providers to start rate-based. Cost-based is honest but it is only as good as the cost drivers behind it, and those go stale the moment someone refreshes hardware or renegotiates a license. A rate card you can defend on a slide beats a cost card nobody trusts.
The pricing hierarchy and the trap inside it
Cards are assigned to vCenters or Clusters. Price is calculated per VM, aggregated, and rolled up to the vCenter. When two policies apply, a default at the vCenter and another at a cluster, the cluster policy wins for everything under that cluster, and the cluster cost then rolls up to the vCenter. So far, ordinary precedence.
Here is the part people miss. When a virtual machine sits under the VCF Automation hierarchy and the vCenter hierarchy, the VCF Automation hierarchy takes precedence. The VM is removed from the vCenter resources and counted under VCF Automation resources instead. If your vCenter pricing card and your Automation pricing differ, the Automation side is what the tenant pays, and the VM vanishes from the vCenter cost rollup. Reconcile those two numbers before a tenant does it for you.
Showback vs chargeback
These two words get used interchangeably and they should not be. Showback is visibility: it lets you view, analyze and compare cost per user, per VM, per project, per organization, with no money changing hands. Chargeback is the bill: it allocates the cost of cloud resources to the tenants or business units that consumed them, by actual usage, and produces an invoice. Showback is how you build trust in the numbers. Chargeback is what you do once people trust them.
VCF 9.1 extends both to VMware Kubernetes Service. You get showback, chargeback and real-time pricing estimates for VKS nodes, not just classic VM pricing, which closes a real gap for tenants running the All Apps organization model. See Part 26 on the All Apps organization for where those VKS nodes come from.
A rate card, worked end to end
Below is a readable representation of the fields you set when you build a rate-based card in VCF Operations. It is not an API payload; it is the shape of the decisions, so you can see what assignment and roll-up mean before you click through the wizard.
# Rate-based pricing card (representation of the fields set in
# VCF Operations > Configure > Cost Settings > Pricing Cards)
name: gold-vsphere-rate
type: rate-based
assigned-to:
- vcenter: vcenter-prod-01
- cluster: cl-gold-01 # cluster policy wins over vCenter policy
charge-period: month
rate-factors:
cpu: { unit: vCPU, rate: 9.00 }
memory: { unit: GB, rate: 4.00 }
storage:
- { tier: gold, unit: GB, rate: 0.12 }
- { tier: silver, unit: GB, rate: 0.06 }
base-charge: { unit: VM, rate: 15.00 } # management upcharge
# Price recalculates on the 24-hour VCF Operations cost cycle.Tenant payments-prod runs 20 VMs, each averaging 4 vCPU, 16 GB RAM and 120 GB of gold storage, on the gold-vsphere-rate card above.
Per VM per month: 4 × 9 = 36 (CPU) + 16 × 4 = 64 (memory) + 120 × 0.12 = 14.40 (storage) + 15 (base) = 129.40. Across 20 VMs that is 2,588 per month for the project.
Showback hands that 2,588 to the team as a number to question. Chargeback turns it into a bill tied to the organization or its region quota. If five of those VMs later move under the VCF Automation hierarchy, they leave the vCenter rollup and are priced by Automation instead, so the vCenter-side total drops even though nothing was deleted. That is the reconciliation line item nobody plans for.
Generating a tenant bill
Once pricing is assigned, the billing workflow is short and lives across both products. The provider acts in VCF Operations; the tenant reads in the VCF Automation portal.
In VCF Operations, go to Capacity > Cost > Bills. Generate a one-time bill or schedule a recurring one, and tie it to either the Organization or a Region Quota. The tenant then logs into the VCF Automation Organization portal with Organization Admin or Organization Auditor rights and opens Administer > Bills. One thing to set expectations on early: ordinary Organization Users do not have access to billing at all. Only the admin and auditor roles see bills, so decide who in the tenant owns that visibility before they ask why they cannot find it.
What breaks, and what to validate first
The failures here are rarely dramatic. They are quiet wrong numbers, which is worse, because a tenant finds them after you have invoiced.
The 24-hour lag. Price recalculates every 24 hours, and a new card is priced in the next cycle. If you build a card and screenshot a zero an hour later, that is expected, not a bug. Validate pricing the day after, not the minute after.
VMware Cloud on AWS plus cost-based equals zero. Assign a cost-based card to VMC objects and the price reports zero silently. For anything touching VMC, use rate-based. Check this before you promise a hybrid tenant a bill.
The hierarchy swallow. VMs under VCF Automation drop out of vCenter cost rollups. If your vCenter dashboard total suddenly looks light, the workloads probably did not leave; they moved under Automation pricing. Reconcile the two views as a standing check.
One-to-one binding. One VCF Automation instance pairs with one VCF Operations instance. If you run multiple Automation instances expecting a single billing pane, that assumption is wrong. Plan the topology around it. The brownfield case is the migration off VMware Cloud Director, where pricing, billing and dashboards that lived in VCD now live in this pair. Budget time to rebuild rate cards rather than expecting an import.
For the operations-side context behind all of this, the VCF 9 Operations capacity and cost runbook covers the Operations plane itself, and Part 24 on multi-tenancy design sets up the organization and region-quota boundaries that bills attach to.
What I’d Do
Start rate-based, not cost-based. Build one defensible rate card per service tier, assign at the cluster level so precedence is explicit, and run a full month in showback before you ever issue a chargeback bill. Showback first is not caution for its own sake; it is how you find the hierarchy-swallow and the 24-hour lag while they are embarrassing instead of expensive. Cost-based has a place once your cost drivers are trustworthy and finance demands spend-anchored numbers, but that is a second move, not a first one. The one thing I would not do is promise a tenant an invoice date before you have watched two clean recalculation cycles. If you are standing up billing this quarter, build the rate card today and check the number tomorrow.
References
- VCF 9 Pricing Overview (Broadcom TechDocs)
- Chargeback and Billing, VCF Automation Detailed Design (Broadcom TechDocs)
- Scale, Simplify and Secure Your Private Cloud Operations with VCF 9.1 (VCF Blog)
About The Author
