VCF subscription tiers, without the marketing.

Broadcom's portfolio simplification has dramatically reduced the number of VMware SKUs a customer needs to think about. The simplification is real and is mostly an improvement for procurement. But the smaller SKU count comes with sharper tier boundaries: capabilities that used to be available as standalone add-ons are now packaged into specific subscription tiers, and moving between tiers is an explicit commercial event rather than a quiet add-on.

This piece walks through the current tier structure, what is in each tier, where the boundaries sit, and how to make the tier decision deliberately rather than by default.

The current tier structure

Broadcom's current VCF-family packaging is built around a small number of subscription tiers. The exact names and feature lists shift with versions, but the structural pattern has settled. From narrowest to broadest, the customer-facing tiers we see most commonly are:

vSphere Standard / Foundation tier

The narrowest entry point covers vSphere as a hypervisor with a defined entitlement for vCenter. This is the natural landing tier for customers who want VMware as a hypervisor but do not need vSAN, NSX, or the Aria stack. It is meaningfully cheaper per core than the wider VCF tiers and is the right answer for organisations whose VMware footprint is "ESXi plus vCenter".

VCF Standard / mid-tier

The middle tier bundles vSphere, vSAN, and a defined portion of NSX into a single per-core subscription. It is positioned for customers operating workload-domain-style architectures without full self-service IaaS. The vSAN entitlement is typically capped at a defined per-core capacity, and the NSX inclusion is networking-focused rather than including advanced security.

VCF Advanced / wider tier

The wider tier extends the bundle to include NSX advanced networking, additional Aria components, and HCX with defined enterprise capabilities. It is positioned for customers running formal private cloud environments with some self-service IaaS capability.

VCF Private Cloud Edition

The top tier — explored in detail in our dedicated piece — bundles the full feature set including NSX advanced security, Aria Operations Enterprise, HCX Enterprise, and Tanzu Kubernetes Grid runtime. It is positioned for customers operating true on-premises private clouds at scale.

Beyond these, Broadcom also offers narrower SKUs for specific use cases (vSAN-only for storage refresh, NSX-only for network teams) but these are increasingly rare in transactions and are not the default offer for net-new customers.

Where the tier boundaries actually matter

From a defence perspective, three tier boundaries do the most commercial work.

The vSphere-to-VCF Standard boundary

This is the largest jump in per-core cost. The right-hand side adds vSAN entitlement and basic NSX networking, but it roughly doubles the per-core price compared to vSphere-only tiers. Customers should cross this boundary only if vSAN is actually deployed in production at scale. Adding vSAN for a small subset of clusters is rarely worth the tier jump; running vSAN across the estate often is.

The mid-to-Advanced boundary

This boundary brings in NSX advanced networking, broader Aria entitlement, and HCX Enterprise capabilities. The question to ask is whether NSX advanced load balancing and federation are actually deployed (or near-term planned), and whether HCX bulk migration capabilities are part of the operating model. Customers crossing this boundary "just in case" typically over-pay.

The Advanced-to-Private Cloud Edition boundary

This boundary brings in NSX advanced security (distributed firewalling at scale, NSX Intelligence) and Aria Operations Enterprise. For regulated industries with explicit micro-segmentation requirements, this boundary is worth crossing. For organisations using third-party security tooling at the firewall and EDR layers, the NSX advanced security is typically duplicative.

The tier decision in practice

The decision starts with a candid inventory of what is actually deployed in production today and what is on the near-term roadmap.

For each of the major components — vSAN, NSX, Aria Operations, Aria Automation, HCX, Tanzu — the question is binary at first: is this deployed in production? If yes, the tier choice has to include it. If no, the next question is whether it is on a near-term roadmap with funded, named ownership. Only items that pass that second filter should drive the tier choice. Items that are aspirational but unfunded should not push the tier up.

The output of that process is a target tier. The next step is benchmarking that tier against deployment size — small, mid-market, or enterprise — and against the term length being considered. Customers who anchor on the tier first and the discount second consistently get better commercial outcomes than the reverse.

How Broadcom positions tier choice

It is worth understanding how Broadcom's account teams typically position tier choice, because the framing predictably nudges customers toward higher tiers.

The first framing is "future flexibility": buy the higher tier because you may need the features later. This framing is genuine in some cases but is more often a discount-optimisation argument; the customer pays for the flexibility now rather than buying the upgrade later. The math only works if the upgrade actually happens within the term.

The second framing is "bundled discount": the higher tier offers a deeper discount on a per-core basis. This is true on the contracted scope but, as discussed earlier, only valuable if the broader scope is actually used. Effective price per core that you use can be the same or worse on the higher tier.

The third framing is "strategic partnership": signing into the broader tier signals commitment and earns favourable treatment. There is a kernel of truth here — Broadcom does treat strategic customers differently in renewal and audit — but the favourable treatment can also be earned through deal size and term length without paying for tier features the customer does not use.

Tier mobility: moving between tiers mid-term

One of the most under-discussed contractual questions is tier mobility: what happens if the customer wants to move between tiers during the subscription term?

The default order form is silent on downward mobility. Customers who realise mid-term that they bought a higher tier than needed do not have a contractual right to step down without renegotiation, and renegotiation typically lands at the original commitment level. The remedy is to draft step-down rights into the order form up front — typically at the boundary of each contract year.

Upward mobility is easier; Broadcom is always willing to sell a tier upgrade. The question on upward moves is whether the upgrade is priced at the same effective rate as the original deal or at then-current list. The default is the latter; the better-drafted alternative is to lock the upgrade rate at signing.

The audit posture differs by tier

An often-overlooked aspect of tier choice is that the audit posture differs by tier. The narrower the tier, the narrower the audit surface — fewer components to interrogate, fewer features to verify, fewer entitlement boundaries to defend.

Customers on Private Cloud Edition face the broadest audit surface because the bundle includes NSX advanced security features that auditors scrutinise carefully, Aria Operations scopes that may extend beyond the licensed environment, and HCX Enterprise capabilities that customers commonly enable for projects and forget to disable.

Customers on narrower tiers face less audit surface but the same intensity on the components they have. The trade-off is straightforward: pay for the broader scope and accept the broader audit surface, or pay for the narrower scope and accept that adding capability mid-term is an explicit commercial event.

Closing

The VCF tier decision is the highest-leverage choice a customer makes in any Broadcom deal. The default account-team recommendation tends to be a higher tier than the customer needs; the disciplined customer-side answer is built from production deployment data and near-term funded roadmap, not from features that "would be nice to have" or "might be useful later". Done well, the tier choice produces a deal that is appropriate to the customer's operating model, defensible at audit, and predictable across the multi-year subscription life. Done poorly, it produces a deal that pays full price for full scope and creates audit surface the customer would rather not own.