The Tanzu Software in Your VCF You Are Not Using

A significant share of VCF customers are entitled to Tanzu software they have never activated — and some are separately paying for, or running unsupported, the exact thing their subscription already covers.

This is not a licensing loophole. It is a straightforward consequence of a large bundle, agreements signed at different times, and entitlement records that nobody reads until a renewal. It is also one of the few places where a renewal conversation can genuinely find value rather than just negotiate a number.

Beyond the infrastructure stack — vSphere, vSAN, NSX and the management layer — a VCF subscription can carry access to Tanzu products depending on edition and entitlement:

• vSphere Kubernetes Service for container workloads. Note this ships in VVF as well.
• Tanzu RabbitMQ — the commercial build of RabbitMQ, with capabilities and support beyond the open-source distribution.
• Tanzu Spring — commercial Spring support, including access to maintenance for versions past open-source end of life.
• Tanzu GemFire and Tanzu Greenplum — the in-memory data grid and the analytics database.

Entitlements vary by edition and by when your agreement was signed. That caveat is not throat-clearing — it is the reason this goes unnoticed. There is no single answer that applies to every VCF customer, so the only reliable source is your own entitlement record.

Three situations we run into repeatedly.

Running open-source where you are entitled to commercial. A team runs open-source RabbitMQ, hits a production problem, and has no vendor to call — while the organisation's VCF entitlement covers the commercial build with support. The engineering team and the licensing record have simply never been in the same conversation.

Paying twice. Separately procured messaging, data platform or Spring support sitting alongside an entitlement that already covers it. Not common, but expensive when it happens, and it survives for years because nobody reconciles the two.

Undervaluing the renewal. When VCF renewal cost is judged only against the hypervisor, it looks expensive. If it is also covering your messaging platform and your Spring support, the comparison is different — and that is a legitimate argument to make internally, not a sales line.

The reverse is equally true and worth saying plainly: if you are renewing VCF and consuming none of the bundled Tanzu software, that is a real argument for looking hard at VVF. Paying roughly 2.7x per core for capability you do not deploy is the most common way VCF becomes poor value.

1. Pull your entitlement record from the Broadcom portal and list what your active subscriptions actually include — by edition, not by assumption.
2. List what you are running in messaging, data and application platform. RabbitMQ, Spring, any in-memory grid or analytics database.
3. Reconcile the two. Anything on both lists that you are separately paying for, or running unsupported, is the finding.
4. Confirm scope before deploying anything new. Entitlement scope, supported versions and whether support is included vary by edition — deploy against a confirmed entitlement rather than an assumption.

Mixed estates with agreements signed at different times are where this is murkiest, and where the findings usually are.

AceMQ is a Broadcom partner and we run RabbitMQ, Spring, GemFire and Greenplum in production for customers — so we tend to notice bundled entitlements that infrastructure-only partners do not think to look for. If you want your VCF entitlement reconciled against what you are actually running, talk to us. If the answer is that you are consuming none of it, that is worth knowing too — it is an argument for a cheaper tier, and we will say so.