TL;DR · Key Takeaways
- There is no separate VCF Automation license. It is included in the single VCF per-core subscription, alongside vSphere, vSAN, NSX, VCF Operations, VKS, and Private AI Services.
- If you have VCF, you already have VCF Automation. Enabling it does not add to your core count.
- The expensive mistake is assuming VVF covers it. VMware vSphere Foundation does not include VCF Automation; that is a VCF-only entitlement.
- Licensing is per core, subscription-only, with a 16-core-per-CPU minimum, managed through VCF Operations and the vcf.broadcom.com portal.
- Some advanced services (advanced container capability, advanced security, load balancing, data services) are sold separately, so budget for those on top.
The good news about VCF Automation licensing is that there is no VCF Automation license. The catch is the same sentence: because there is no separate license, you cannot buy it on its own, and you cannot get it without buying the thing it comes inside. If you are still budgeting for a standalone Aria Automation or vRA line item, stop. That SKU does not exist anymore. What replaced it is simpler and, for some teams, a trap.
The model in one sentence
VCF Automation is included in the single VCF per-core subscription. One subscription covers vSphere, vSAN, NSX, HCX, VCF Operations, VCF Automation, vSphere Kubernetes Service, and VCF Private AI Services. There is no add-on for the self-service layer. If you hold a VCF entitlement, the Automation product is already paid for and waiting to be enabled, which is exactly what Part 4 walked through.
This is a real break from the vRA era, when Automation was a separate product you licensed on its own, often by the OSI or through a dedicated portal. The bundling simplifies procurement, but it also changes the question. You no longer ask how much VCF Automation costs. You ask whether your VCF subscription is the right bundle and sized for enough cores, because those are the only two levers left.
The VVF trap
Here is the costly misread. VMware vSphere Foundation, VVF, is the smaller bundle, aimed at vSphere-centric environments, and it does not include VCF Automation. Teams that hold VVF and assume they can stand up self-service provisioning discover, usually mid-project, that the entitlement is not there. No amount of configuration conjures a license you did not buy. If self-service and multi-tenancy are the goal, you need VCF, not VVF, and that is a procurement decision, not a technical one.
| Component | VCF | VVF (vSphere Foundation) |
|---|---|---|
| vSphere + vSAN entitlement | Yes | Yes |
| VCF Operations | Yes (full) | For vSphere, reduced scope |
| NSX | Yes | No |
| VCF Automation | Yes | No |
The first thing I check on any VCF Automation engagement is which bundle the customer actually holds. It takes one question and it saves a design built on an entitlement that is not there. If the answer is VVF and the requirement is self-service, the conversation moves to procurement before it moves to architecture.
How it is actually licensed
VCF 9 is subscription-only; perpetual licensing is gone. You license per core, with a 16-core-per-CPU minimum, and you receive 1 TiB of vSAN entitlement per core, pooled across hosts. Licensing is managed centrally through VCF Operations, and VCF 9 introduced a license portal at vcf.broadcom.com that replaces the old 25-character key model. None of those mechanics are specific to Automation, and that is the point.
The nuance that matters for this series: VCF Automation does not add cores. It is covered by the same per-core entitlement that licenses the rest of the stack, so turning it on does not increase your licensed core count by a single core. You pay for cores once, and the management and self-service layers ride along. That is a genuinely different cost shape from the vRA days, when scaling Automation could mean buying more Automation.
Worked example
Take a two-socket host with 24 cores per socket: 48 cores, comfortably past the 16-core-per-CPU minimum, so you license 48 cores. That single per-core purchase entitles vSphere, vSAN (48 TiB pooled), NSX, VCF Operations, and VCF Automation across that host. Scale to a four-host cluster and you license 192 cores, and Automation is still included across all of them at zero additional core cost. The lever on your bill is host cores, not whether you switched on self-service.
What still costs extra
Included does not mean everything is included. Several advanced services sit outside the base subscription and are sold separately. VCF Automation itself is in the bundle, but some capabilities you might wire into your catalog or platform are not, and a budget that assumes total coverage will be short.
| In the base VCF subscription | Sold separately (advanced services) |
|---|---|
| VCF Automation (self-service, catalog, templates) | Advanced Container Capability |
| VCF Operations | Advanced Security |
| NSX, vSAN, vSphere, VKS | Load Balancing, Data Services |
From a vRA license to a VCF entitlement
If you ran vRA or Aria Automation, your licensing instincts are wired for a separate product with its own meter and its own renewal. VCF rewires that. There is one entitlement, counted in cores, and Automation is a feature of it. The practical effects are worth spelling out, because they change how you renew, true-up, and report, not just what you buy.
What changes at renewal
In the vRA world, Automation could come up for renewal on its own schedule, sized to its own usage, and you negotiated it as a line item. Under VCF there is no separate Automation renewal. You renew the VCF subscription, sized to cores, and Automation rides along. That removes a negotiation, which is welcome, but it also means you cannot scale Automation independently of the platform. If Automation demand grows while your core count holds steady, you do not buy more Automation, because you were already entitled to all of it. If the platform grows, your cores and your bill grow, and Automation scales with that for no extra core cost. The lever is the platform, never the feature.
Where you see consumption
Licensing and consumption are visible centrally through VCF Operations and the vcf.broadcom.com portal, not in a separate Automation licensing screen. That centralization is a real improvement for reporting, because there is one place to see entitlement against usage across the whole fleet. The flip side is that a finance process expecting a per-Automation usage report will not find one in the old shape. Point your reporting at the VCF entitlement view and retire the vRA-era spreadsheet, rather than trying to reconstruct a meter that no longer exists.
The mixed-estate gotcha
The messy case is common: an estate that is part VVF and part VCF. The VVF hosts cannot run VCF Automation, the VCF hosts can, and it is easy to design a self-service catalog that quietly assumes coverage the VVF side does not have. If you straddle both bundles, draw the line explicitly. Automation tenants and their provisioned workloads live on VCF-licensed capacity, and the VVF capacity stays out of scope for self-service placement. Blur that line and you eventually get a deployment that lands on hosts your entitlement does not cover, which is a compliance problem wearing the costume of a placement bug. The fix is a placement boundary you set on purpose, which is exactly the kind of cloud-zone discipline later Parts in this series build on.
The Bottom Line
If you are on VCF, VCF Automation is already paid for, so turn it on and stop pricing a SKU that no longer exists. If you are on VVF, you do not have it, and no configuration changes that; the fix is a procurement conversation about moving to VCF. My recommendation is to settle three things before you design: confirm your bundle is VCF and not VVF, confirm your core count covers the hosts you intend to run, and list the advanced services your catalog will actually depend on so they are in the budget from day one rather than discovered after launch. Get those three right and licensing stops being a surprise and becomes a footnote, which is exactly where it belongs.
Next we get into the build: setting up the provider organization and its infrastructure. For how VCF 9 licensing works across the wider stack, see VCF 9 Licensing Explained. Are you on VCF or VVF today, and did that match what you assumed? Tell me in the comments.
Previous: Part 4, deploying via Fleet Management. Next: Part 6, the provider organization setup (coming soon). Up: VCF Automation Guide (pillar).
References
- VCF 9 Licensing Overview (Broadcom TechDocs)
- Licensing in VMware Cloud Foundation 9.0 (VCF Blog)
- VCF 9.1 Licensing: Programmatic, Centralized, and Built to Scale (VCF Blog)
About The Author
