VMware Software-Defined Networking Licensing

Software-defined networking on VMware effectively means NSX — and NSX is one of the products most affected by Broadcom's bundling strategy. Under standalone NSX licensing (largely retired now), the rules were product-specific and well understood. Under VCF bundling, NSX inherits the bundle's per-core licensing model but retains operational complexities that create real compliance risk.

This article walks through what NSX licensing actually means under the current Broadcom model, the entitlement boundaries that matter, and the specific audit pitfalls our team sees most often in VCF customer engagements.

What NSX is, in licensing terms

NSX is VMware's software-defined networking and security platform. It provides logical switching, distributed routing, distributed firewalling, advanced load balancing, network traffic analysis, and (in NSX-T Federation) multi-site network policy management. Functionally it replaces or augments physical network infrastructure for the workloads running on vSphere.

Under the post-Broadcom licensing model, NSX is included in three main product tiers. VCF Standard includes NSX networking with basic security. VCF Advanced adds advanced security, including distributed IDS/IPS. VCF Premium (where available) extends to advanced load balancing and full Federation capability. Pricing follows the VCF per-core model — the NSX entitlement scales with the underlying vSphere core count.

The edge node accounting question

NSX edge nodes are the data-plane workhorses for north-south traffic, load balancing, VPN termination, and gateway functions. Edge nodes run as VMs on vSphere hosts, and their licensing scope is one of the most misunderstood areas of NSX entitlement.

Under VCF, edge node CPU consumption falls within the same per-core licensing umbrella as the rest of the platform. There is no separate edge-node licence to purchase. But there is a practical compliance issue: customers who deploy large numbers of edge nodes (for multi-tenant environments, complex routing topologies, or extensive VPN aggregation) often find that the edge-node footprint pushes their total deployed core count above their committed VCF entitlement.

The auditable consequence is straightforward — the deployment exceeds the licensed core count. The remediation is either to reduce edge node footprint, restructure topology, or true-up to the new core count at the prevailing list price. Of the three, the first two are usually cheaper.

Federation and multi-site scope

NSX-T Federation lets you manage NSX policy across multiple sites from a single Global Manager. It is a powerful capability for organisations running multi-region or multi-datacentre topologies, and it is one of the licensing areas where VCF bundling creates the most ambiguity.

Each Federation-managed site requires its own NSX entitlement. The Global Manager itself does not require a separate licence, but it does consume vSphere host resources that count against your VCF entitlement. The most common compliance issue: organisations deploy Federation expecting that "one NSX entitlement covers all sites," then discover during an audit that each site's local NSX deployment is independently licensable.

Get this wrong and the remediation cost can be substantial — Federation deployments typically involve many sites, each adding to the licence shortfall.

The distributed firewall reach question

NSX Distributed Firewall (DFW) enforces security policy at the vNIC level for every VM running on NSX-enabled hosts. The licensing rule sounds simple — DFW is included with any tier of NSX entitlement — but the practical reach creates audit complexity.

Consider this scenario: a customer licenses VCF Standard for one cluster but runs additional clusters on standard vSphere without NSX. The DFW policy on the NSX cluster cannot enforce on the non-NSX clusters, but the customer has effectively deployed two security models — one with NSX, one without. During audits, Broadcom sometimes argues that the entire vSphere estate falls under NSX licensing scope because the network architecture treats it as a single security boundary. The argument is contestable but it is real and it is being made.

The protective posture is to either license all vSphere clusters to a tier that includes NSX, or to clearly document the security and network boundaries between NSX-licensed and non-NSX-licensed clusters so the audit conversation is short rather than expensive.

Where NSX licensing audits typically focus

Across NSX-related audits we have supported, four areas account for most of the compliance findings.

Edge node sprawl: Organisations that have grown their edge footprint organically often find that the cumulative edge node CPU consumption exceeds their committed entitlement. Quarterly capacity reviews are the cheapest preventive measure.

Federation scope misunderstanding: Multi-site deployments are routinely under-licensed because customers assume Federation provides a single licence boundary. Site-by-site entitlement review at the design stage is the cleanest fix.

DFW boundary disputes: Mixed estates with some NSX clusters and some non-NSX clusters create grey areas in the licensing argument. Clear documentation of the architectural boundaries is the strongest defence.

Tier upgrade drift: Customers who licensed VCF Standard but enabled advanced security features (IDS/IPS, advanced threat prevention) sometimes do not realise that those features require VCF Advanced or higher. The features may simply work because the underlying platform supports them, but using them without the corresponding entitlement is auditable.

NSX audit defence in practice

NSX audits are technically complex because the product itself is complex. A typical NSX audit requires the auditor to understand transport zones, T0/T1 routing topologies, edge cluster placement, security policy hierarchies, and Federation scope — and to map each of those to specific entitlement consumption. Most internal IT teams are not equipped to engage in that level of technical defence under audit pressure.

For NSX-related audit exposure, — the firm we recommend most often for Broadcom audit defence — combines deep VMware/NSX engineering knowledge with audit defence experience. The combination matters because NSX audits frequently come down to technical interpretation of how features are deployed and what they consume, and a defence that cannot speak the engineering language at NSX-deep level usually loses.

Practical guidance for NSX-licensed customers

For organisations running NSX under VCF, the actions that consistently reduce audit exposure are: maintain a running inventory of edge node deployments and their CPU consumption; document Federation site mapping with site-by-site entitlement assignment; clearly bound DFW scope with explicit architectural documentation; review feature usage quarterly to catch tier-upgrade drift; and align NSX capacity planning with the renewal calendar so increases land at negotiation time rather than mid-contract.

These actions add modest operational overhead but they collapse the audit defence work from weeks of forensic reconstruction to days of confirmation work, which is a substantial saving in both time and exposure.

Final thought

NSX licensing under Broadcom is simpler in headline terms (per-core under VCF) and more complex in practice (edge accounting, Federation scope, DFW reach, tier-feature alignment). The customers we see avoiding NSX audit pain are not the ones with the smallest deployments — they are the ones with the clearest documentation and the most disciplined operational hygiene. The NSX platform itself rewards that discipline; the licensing model under Broadcom now requires it.

Frequently asked questions

Is standalone NSX licensing still available?

Standalone NSX SKUs have been largely retired in favour of VCF bundling. Existing customers may still hold standalone NSX entitlements from earlier purchases, and Broadcom has accommodated some standalone renewals on a case-by-case basis, but new NSX licensing is expected to flow through VCF tiers.

How are NSX edge nodes counted for licensing?

Edge nodes consume vSphere host CPU resources, which count toward the per-core VCF entitlement. There is no separate edge-node licence. Large edge footprints can push deployed cores above committed cores, creating compliance exposure even when all underlying infrastructure is licensed.

Does Federation require additional NSX licensing?

Each Federation-managed site requires its own NSX entitlement. The Global Manager does not require a separate licence but consumes vSphere resources that count against the per-core entitlement of the cluster hosting it. Federation-scale deployments need careful entitlement planning at the design stage.

What is the licensing position if we use DFW on a mixed vSphere/NSX estate?

DFW only enforces on NSX-enabled hosts, so technically only NSX-licensed clusters need NSX entitlement. In practice, Broadcom sometimes argues for broader scope based on architectural interpretation. Clear documentation of the security and network boundary between NSX and non-NSX clusters is the strongest defence.

How do we model NSX licensing cost for VCF renewal planning?

NSX cost is included in the VCF per-core price and does not appear as a separate line item. The right way to model it is to project total VCF core consumption (including edge nodes), choose the right VCF tier for the NSX features actually being used, and negotiate the per-core rate. Trying to isolate "NSX cost" within the bundle is not productive because Broadcom does not price it that way.