TL;DR · Key Takeaways
- The full VCF bundle includes NSX networking (segments, gateways, routing, NAT, DHCP, load balancing, stateless gateway firewall). VVF (vSphere Foundation) does not include NSX.
- Security is a separate purchase: vDefend Firewall (Distributed Firewall and stateful gateway firewall) and vDefend Firewall with Advanced Threat Prevention (IDS/IPS, malware, NDR).
- vDefend is licensed by physical core, at your full VCF core count, with the same 16-core-per-CPU minimum. You cannot license only the hosts that run micro-segmentation.
- Standalone NSX (outside VCF) exists, but Broadcom prices it higher per core to push the bundle. In VCF 9 the practical answer for most shops is VCF plus vDefend.
- Get the security line into the budget at design time. The surprise is never the networking, it is the firewall you assumed was included.
The most awkward moment in a lot of NSX projects is not technical. It is the call where the customer realizes the quote they signed covers NSX networking and the micro-segmentation they actually bought NSX for is a separate line they have not budgeted. I have sat in that meeting. The networking was never the expensive part; the firewall was, and in VCF 9 it is a deliberately separate entitlement. Part 1 flagged this in passing. Here is the whole picture: what the bundle gives you, what the security add-ons cost in cores, a worked example, and when standalone NSX is worth a second look.
How NSX is consumed in VCF 9
Under the Broadcom model, VMware Cloud Foundation is sold as one subscription, licensed per physical core, and a single solution key unlocks the stack. NSX networking is part of that stack, alongside vSphere, vCenter, the VCF Operations and Automation components, HCX, and VKS. So if you are licensed for VCF, you already have NSX networking; there is no separate NSX networking SKU to buy on top. That is the good news, and it is why NSX is no longer something you bolt on with its own key. It arrives with the platform.
The contrast that matters: vSphere Foundation (VVF) does not include NSX. VVF gives you the hypervisor, vCenter, and a smaller set of management components, but the integrated NSX, vSAN, and broader VCF layers are not in it. If you are on VVF and you want NSX, you are buying NSX separately as an add-on. That single fact decides a lot of architecture conversations before they start, so confirm which foundation the customer is actually licensed for before you design anything that assumes NSX is present.
Networking is included. Security is the add-on.
This is the line everyone trips over, so let me be exact. The base VCF entitlement gives you the full NSX networking feature set and the stateless gateway firewall. It does not give you the parts most people mean when they say “we are deploying NSX for security”: the Distributed Firewall, the stateful gateway firewall, and the threat-prevention features. Those live under the vDefend family, sold as a separate add-on, and in licenseless evaluation mode they are not even switchable on; you request a trial to test them.
vDefend comes in two tiers. vDefend Firewall is the Layer 2 to Layer 7 stateful firewall: the Distributed Firewall for east-west micro-segmentation plus the stateful gateway firewall at the perimeter. vDefend Firewall with Advanced Threat Prevention adds the detection layer on top: distributed IDS/IPS, malware prevention, and network detection and response. You move up to ATP when you need to inspect for threats inside the data center, not just allow or deny flows. The table below is the version I sketch on the whiteboard in every licensing conversation.
| Entitlement | What it unlocks | Buy it when |
|---|---|---|
| VCF base (included) | All NSX networking: segments, Tier-0/Tier-1, routing, BGP, NAT, DHCP, load balancing, stateless gateway firewall. | You have VCF. It is already yours. |
| vDefend Firewall (add-on) | Distributed Firewall (east-west micro-segmentation) and stateful gateway firewall, L2 to L7. | You need micro-segmentation or stateful perimeter rules. |
| vDefend Firewall with ATP (add-on) | Everything in vDefend Firewall plus distributed IDS/IPS, malware prevention, and network detection and response. | You need threat inspection and lateral-movement detection, not just allow/deny. |
Which entitlement do you actually need?
Most of the back-and-forth in a scoping call collapses into a short decision tree. Walk it top to bottom and you land on the right SKU in under a minute.
Core counting, the part that surprises finance
vDefend is licensed per physical core, and it follows the same rules as VCF itself. You license a minimum of 16 cores per CPU socket, even if the physical processor has fewer, and the count is based on populated sockets across the hosts in scope. The detail that catches people: vDefend has to be licensed to the same core count as your VCF entitlement for those hosts. You cannot carve out “just the four hosts running the regulated app” and license vDefend only there. If micro-segmentation is in scope for a cluster, the cluster’s cores are in scope for vDefend.
Worked example
A cluster of 6 hosts, each dual-socket, 20 physical cores per socket. You want micro-segmentation on it.
Cores per host = 2 sockets × max(20, 16) = 40. Cluster total = 6 × 40 = 240 cores.
vDefend Firewall must be licensed for all 240 cores, not the two hosts you imagined scoping it to. Plan for the cluster, not the workload.
One more edge that bites DPU deployments: when you offload to a DPU and use container security, the vDefend count is calculated by multiplying the DPU core count by four. That is easy to miss when someone sizes a SmartNIC build on hardware specs alone. For the underlying VCF core-counting mechanics and the costly mistakes around them, I walk through it in VCF 9 Licensing Explained: Core Counting and 5 Costly Mistakes. The NSX-specific point is simply that the firewall rides on top of that same core math, at full count.
VCF versus standalone NSX
NSX can still be licensed standalone, outside the VCF bundle, for shops that want NSX networking or security without committing to full VCF. It is a real option and occasionally the right one, for example an estate that is firmly on VVF or plain vSphere and only needs NSX for a specific segmentation requirement. But go in clear-eyed: Broadcom has priced standalone NSX higher per core than the equivalent NSX consumption inside VCF, on purpose, to make the bundle the economically obvious choice. The more of the stack you would buy anyway (vSAN, Operations, Automation, VKS), the worse standalone looks by comparison.
My rule of thumb: if you are already on VCF, do not even model standalone NSX, just add vDefend. If you are on VVF and weighing NSX, price both the standalone NSX add-on and a move to full VCF, because the gap is often smaller than people assume once vSAN and the management suite are in the picture. Standalone NSX as a long-term strategy on a Broadcom-era estate is swimming against the commercial current.
The Bottom Line
For the overwhelming majority of VCF 9 customers the answer is the same: you already own NSX networking, and the only real decision is which vDefend tier you need and at what core count. Decide that at design time, size it to the full VCF core count for the clusters in scope, and put it in the budget before the project starts, not after the first audit. Standalone NSX is a niche, not a default. If a vendor quote shows NSX security as free, that quote is wrong, and finding out in month three is the expensive way to learn it. Next up is Part 4: design and planning, transport zones, MTU, IP pools, and EDP. Are you sizing vDefend for one cluster or the whole estate?
Counting cores and avoiding the licensing traps
Licensing is where good NSX designs meet bad surprises at renewal. Two things drive almost every unpleasant conversation: which security features you assumed were included, and how you are consuming NSX in the first place.
The vDefend line is where budgets get surprised
NSX networking and NSX advanced security are not the same entitlement, and the boundary between them is the single most expensive thing to get wrong. Switching, routing, gateways and the basic distributed firewall are core NSX. The advanced lateral-security stack you actually design a zero trust program around, the distributed Layer 7 firewall, distributed IDS/IPS and malware prevention, is vDefend, and it is licensed separately or at a higher tier. The failure pattern is consistent: a team scopes a micro-segmentation project, designs around Layer 7 rules and intrusion detection, and only at procurement discovers those capabilities sit behind a vDefend entitlement they did not budget. Confirm which security features your architecture depends on, and confirm the exact edition or add-on that entitles them, before the design is signed off, not after.
VCF-bundled versus standalone changes the math
The same NSX capabilities can reach your budget through different doors. Consumed inside VMware Cloud Foundation, NSX is licensed as part of the VCF per-core subscription; consumed standalone, it is its own entitlement with its own editions. Neither is universally cheaper, but mixing assumptions across the two is how a renewal lands higher than the plan. Decide the consumption model first, because it determines how every later feature maps to cost, and then map your required features to entitlements strictly within that model. An architecture priced as if it were standalone but delivered inside VCF, or the reverse, is a forecast that will not survive contact with the quote.
Worked example
Subscription is counted on physical cores, not VMs or sockets, so count the estate honestly. Eight hosts at two sockets and twenty-four cores per socket is 384 physical cores, and that is the base your VCF subscription is sized to. If your zero trust design depends on Layer 7 firewalling and IDS/IPS, the vDefend entitlement is priced on that same core base, so enabling lateral security across the estate roughly doubles the per-core line you are reasoning about for those hosts. Knowing that before the design review is the difference between a funded project and a redesign.
Renewals are where your assumptions get audited
Licensing is not a one-time event at purchase; it is re-examined at every renewal and every true-up, and that is where optimistic assumptions get caught. The subscription is sized on physical cores, so the estate that grew through the year, the extra hosts added to a workload domain, the cluster expanded to absorb a new project, all of that increases the core base you are paying for. Teams that do not track deployed cores against entitled cores discover the gap at renewal, when it is least convenient and least negotiable.
The same applies to feature scope. A micro-segmentation project that started as basic firewalling and grew into Layer 7 rules and intrusion detection has quietly moved into vDefend territory, and that scope creep shows up as a line item nobody forecast. The discipline that keeps renewals boring is simple: track what you have deployed against what you are entitled to, review it before the estate grows rather than after, and treat every new security capability someone wants to enable as a question about entitlement as much as about engineering. The architecture and the licence have to grow together, or the licence catches up with you all at once.
References
- Counting Cores for vDefend Firewall and vDefend Firewall with ATP (Broadcom Knowledge)
- vDefend ATP 9.0 License Types (Broadcom TechDocs)
- What’s New in NSX for VCF 9.0 (Broadcom TechDocs)
About The Author
