vSAN Licensing After Broadcom
Standalone vSAN is largely gone. The product now lives inside VCF at full capacity and inside VVF at a per-core capacity quota. The capacity quotas are where most customers run into compliance gaps. Here is how the licensing actually works.
vSAN is the VMware software-defined storage layer, aggregating local disks across hosts into a distributed storage pool. Before the Broadcom acquisition, vSAN was sold as a standalone product, priced per CPU, with editions covering different feature sets. After the acquisition, the standalone product has been progressively retired and vSAN is now licensed almost exclusively as a component inside the VCF or VVF bundles.
The change is not merely cosmetic. vSAN inside VCF behaves differently from vSAN inside VVF, and the capacity quotas attached to VVF inclusion are where most customers run into compliance gaps. This guide explains the current licensing position and the audit-risk profile.
Standalone vSAN: largely retired
Broadcom has progressively retired standalone vSAN SKUs through 2024 and 2025. Some legacy SKUs persist for renewal motions on existing standalone-vSAN customers, but new commercial purchases are funnelled into the bundle structure. The exception is some specific edge or branch deployment SKUs that retain a constrained standalone form, intended for sites where a full VVF or VCF deployment is over-provisioning.
For practical purposes, if you are a typical enterprise customer using vSAN, your renewal options are: VCF (which includes vSAN at full functionality), VVF (which includes vSAN at a per-core capacity quota), or migration to alternative storage. Standalone vSAN as a meaningful purchase path is gone.
vSAN inside VCF: full functionality
VCF includes vSAN at full functionality and at no separate capacity charge. Customers licensed under VCF can deploy vSAN across all of their licensed cores with the storage capacity provided by the hardware. There is no per-GB or per-TB cap on the vSAN deployment; the cap is the physical storage of the licensed hosts.
vSAN inside VCF supports the full feature set: stretched clusters, file services, deduplication and compression, encryption, snapshot integration, and the policy-based management that vSAN is known for. The edition of VCF affects some adjacent functionality but the vSAN core capabilities are present across all VCF editions.
For customers whose primary need is hyperconverged storage at scale, VCF is typically the right vehicle. The bundled vSAN is full-functionality and well-suited to the primary-storage tier. The total cost per core is higher than VVF, but the inclusion of full vSAN, NSX, and Aria justifies the premium for multi-product use.
vSAN inside VVF: capacity quota
VVF includes a constrained vSAN entitlement. In current SKUs, the entitlement is typically 100 GB of vSAN capacity per licensed core. A customer with 1,000 cores of VVF therefore has 100 TB of vSAN entitlement — sufficient for workload-adjacent storage but generally not for primary-storage tier replacement at scale.
The capacity quota matters in two ways. First, it caps how much vSAN can be deployed under VVF without violating the entitlement. Second, the quota is calculated against logical capacity, not raw capacity — meaning customers with replication factors above one are consuming entitlement faster than physical capacity would suggest.
How the capacity quota is calculated
The licensed capacity is calculated against the logical capacity stored in the vSAN datastore. A customer with 100 TB of logical data stored on vSAN is consuming 100 TB of entitlement, regardless of the raw capacity used to hold it. Replication factor (FTT=1 doubling raw consumption, FTT=2 tripling it) affects the raw capacity required but not the entitlement consumed.
This is favourable to customers running aggressive replication factors — the entitlement is calculated against the data, not the redundancy. It is unfavourable to customers running thin-provisioned environments at high utilisation, where logical consumption can grow faster than physical capacity would suggest.
What happens when the quota is exceeded
vSAN deployed beyond the VVF capacity entitlement is, technically, an out-of-compliance deployment. The product itself does not enforce the quota in the same way it would enforce, for example, an edition mismatch — the cap is contractual, not technical. The consequence of exceeding the cap surfaces in audit findings, not in product behaviour.
Customers exceeding the cap have three options: purchase additional capacity (typically priced as a per-TB add-on), reduce vSAN usage, or upgrade to VCF (which removes the capacity cap entirely). The economics of the choice depend on how far above the cap the deployment runs and how strategic vSAN is to the operating model.
The 100 GB-per-core quota inside VVF is the single most common source of vSAN compliance findings in audits. Customers move from standalone vSAN entitlements into VVF without re-sizing the vSAN deployment, and the deployment quickly exceeds the new cap. Reconstructing the vSAN consumption against the entitlement at renewal — not after the audit notice — is the practical defence.
The standalone vSAN renewal path
Customers still on legacy standalone vSAN SKUs are typically being directed into VVF or VCF at renewal. The decision frame is essentially the same as for vSphere customers: VVF for customers whose vSAN deployment fits comfortably inside the 100 GB-per-core quota, VCF for customers whose vSAN deployment requires the full-functionality inclusion.
The arithmetic favours VCF more strongly for vSAN-intensive customers than for vSphere-only customers. The per-core differential between VCF and VVF is justified by the bundled vSAN-at-full-capacity, vSphere, NSX, and full Aria; for customers using primarily vSAN and vSphere, the value of the bundle is concentrated in the vSAN inclusion.
The audit-risk profile
vSAN audit risk under Broadcom has three principal sources.
VVF capacity-quota overage
The most common finding. Customers running vSAN under VVF with capacity exceeding the per-core entitlement. Detection is straightforward — vSAN reports logical capacity consumption clearly, and the comparison to entitlement is arithmetic.
Edition mismatch on legacy standalone vSAN
The pre-acquisition vSAN editions (Standard, Advanced, Enterprise, Enterprise Plus) had different feature sets. Customers running features beyond their edition entitlement — stretched clusters under a Standard licence, for example — produce a finding.
Core-count mismatch on VCF or VVF
The basic core-count finding applies to vSAN as it does to vSphere — deploying VCF or VVF on more cores than entitled produces a finding. vSAN's host-level deployment makes this particularly easy to detect.
What vSAN customers should do
Three practical actions for any vSAN customer.
First, document current vSAN consumption. The logical capacity used, the host count and core count vSAN runs on, the features in use, and the edition entitlement under the current licence. This is the foundation for any renewal or audit response.
Second, map current consumption against the entitlement you would receive under VVF and under VCF. If VVF's per-core quota covers the consumption with margin, VVF is likely the right vehicle. If VVF is constraining, VCF is likely the right vehicle. The decision is data-driven if the data is honest.
Third, model the conversion cost. Standalone vSAN renewals into VVF or VCF are subject to the same negotiation variables as vSphere conversions — conversion ratio (where applicable), per-core discount, renewal-time uplift cap. The negotiation matters as much for vSAN-centric customers as it does for vSphere-centric customers.
vSAN under VCF in detail
vSAN inside VCF behaves differently from vSAN under the pre-acquisition catalogue in several practical ways. Understanding the operational consequences helps with deployment planning.
The full feature set is enabled. Stretched-cluster configurations, vSAN file services, deduplication and compression, encryption at rest, and the policy-based management framework are all available without additional licensing inside VCF Advanced and Enterprise. VCF Standard restricts some adjacency tooling but the core vSAN functionality is present.
The capacity is uncapped at the bundle level. Customers can deploy vSAN across the entire licensed core count without paying additional per-GB or per-TB charges. The cap is the physical storage of the licensed hosts. This is meaningfully more favourable than the VVF model and is part of why customers running substantive vSAN deployments move to VCF.
The licensing position covers the underlying vSAN runtime; specific functionality such as vSAN ESA (Express Storage Architecture, the newer storage engine) is included at the bundle level, with deployment driven by hardware compatibility and operational choice rather than licensing.
vSAN ESA and licensing implications
vSAN ESA is the newer storage engine introduced in vSAN 8 and progressively rolled into the bundle catalogue. ESA changes the architecture of how vSAN stores and replicates data, with material operational and performance differences from the original Original Storage Architecture (OSA). The licensing implications are limited — both ESA and OSA are covered under the same vSAN entitlement — but the operational choice between them affects how the capacity quotas under VVF are consumed.
ESA's storage efficiency typically reduces logical capacity consumption relative to OSA at the same effective workload. For VVF customers running close to the per-core capacity quota, migrating from OSA to ESA can recover meaningful entitlement headroom. The migration is not trivial — it requires hardware that meets the ESA compatibility requirements and a planned data migration — but is worth evaluating for capacity-constrained VVF customers.
Capacity-quota management under VVF
For VVF customers operating close to the per-core vSAN capacity entitlement, three practical strategies can extend the runway.
Workload migration to alternative storage
Workloads with relaxed performance requirements can be migrated to external storage (NAS, traditional SAN, object storage with appropriate gateways). This reduces vSAN capacity consumption and brings the deployment back inside the entitlement. The trade-off is operational complexity — multiple storage tiers, more complex backup and recovery, additional infrastructure to manage — against the licensing cost of either expanding the entitlement or moving to VCF.
Aggressive data lifecycle management
Many vSAN deployments hold stale data — old VMs, abandoned snapshots, large archive volumes — that consumes entitlement without operational value. A disciplined data-lifecycle review can recover meaningful capacity at little operational cost. The review is most effective when run before renewal, with the recovered capacity proving the entitlement is correctly sized.
Compression and deduplication tuning
For deployments not fully utilising vSAN's compression and deduplication, enabling and tuning these features can reduce logical capacity consumption. This works only where the data profile is amenable to compression and deduplication; pre-compressed or encrypted workloads do not benefit.
Alternative storage platforms post-Broadcom
For customers re-evaluating vSAN under the new commercial model, the alternative storage landscape is worth surveying. Three categories of alternatives are most commonly evaluated.
Traditional SAN and NAS arrays from Pure Storage, NetApp, Dell, and HPE remain operationally robust and commercially competitive. For customers whose vSAN economics no longer work under VVF or VCF, returning to traditional shared storage is a viable path — though it reverses the hyper-converged architecture choice and has operational consequences.
Competing hyper-converged platforms — Nutanix being the most prominent — offer vSAN-equivalent functionality with different commercial structures. Migration is non-trivial but is increasingly common among VMware customers re-evaluating their entire VMware position.
Software-defined storage built on commodity hardware — Ceph, MinIO, native ESXi storage with third-party software-defined storage layers — is the most cost-efficient alternative for customers with capable Linux operations teams and tolerance for less commercially supported tooling.
Related reading
For broader context, see the VMware licensing complete guide, VCF licensing explained, vSphere licensing changes, and NSX licensing changes. For the audit-defence dimensions, see our VMware audit defence guide.