Back to Blog

Azure stops including the VMware licence: the core count nobody does

Azure stops including the VMware licence: the core count nobody does

Yesterday the trade press picked up that Microsoft is closing one of the last doors to using VMware without signing Broadcom's big bundle. We covered the date in that headline on 3 August. What has appeared since is considerably more useful than the news itself: a portable licensing reference page, dated 14 August and updated on the 17th, with four rows of dates and several arithmetic examples that Microsoft works through very politely. That is the part worth reading before September.

Four dates, and the one that hits you is none of them

Azure VMware Solution is VMware running on dedicated metal inside Azure: vCenter, vSphere, vSAN and NSX, with Microsoft as the operator. For years it came with the licence folded into the bill, and that made it where a fair number of companies landed when they did not want to sit down and negotiate with Broadcom. The table of dates marks the end of that arrangement in four steps: on 15 October 2025 the number of vDefend firewall cores still covered was fixed; on 1 November 2025 new deployments started requiring portable VCF; by 31 October 2026 license-included pay-as-you-go deployments have to have moved across to stay compliant; and by 30 August 2027 active reservations have to be exchanged for BYOL reservations or those workloads have to come off Azure VMware Solution.

Look at the second row, because it was in none of yesterday's headlines and it comes before everything else. Microsoft writes on that same page that "as of November 1, 2025, Microsoft no longer includes a VCF license or subscription with new Azure VMware Solution node purchases." When we wrote about this at the start of August, the date going around was the 2026 cut-off. It turns out that for new deployments the old model closed last autumn: if you stood up a cluster in March, you stood it up in the new world already.

And underneath the table there is a callout box with a sentence that takes three seconds to read and changes everybody's calendar: "If a reservation expires before August 30, 2027, its license-included benefits end when the reservation expires." August 2027 is not your date. Your date is when your reservation expires, which may fall in February, May or November next year. Almost nobody has it written down anywhere a human being will look.

The core count, done with Microsoft's own table

What you buy now is cores, and the documentation publishes how many each node type has, so nothing needs estimating here. AV36 and AV36P, 36 cores per host. AV48, 48. AV52, 52. AV64, 64. Multiply by your BYOL hosts and that is the number you need bought from Broadcom and registered on your private cloud's "Portable VCF (BYOL)" page. Microsoft illustrates it with three AV64 nodes: 3 × 64 = 192 cores. And with a mixed private cloud of three license-included AV36P plus four BYOL, where 252 cores are deployed but only 144 get registered, because the first three are already covered.

So far it is a multiplication. A cluster of ten AV36P hosts, an entirely everyday size, is 360 cores of VMware Cloud Foundation. The interesting part is in the next section of the same page.

The other 360, and who they actually land on

The vDefend firewall is a separate add-on and its counting rule does not look like the previous one. For NSX Distributed Firewall you count all host cores in the private cloud. All of them: including hosts that carry an included licence and that do not count towards the VCF registration. Microsoft's example is ten AV36P hosts and it comes out at 360 add-on cores.

Add the two sums and that same ten-server cluster needs 720 core subscriptions: 360 for the platform and 360 for the firewall. What triggers the second one is not a purchase or a signature but a console action: distributed firewall "is considered enabled when you configure a nondefault Distributed Firewall policy or Distributed Firewall IPFIX profile." Somebody in systems writes a rule to segment two networks and the entitlement you need has doubled. The gateway firewall is counted separately — number of edges times their vCPUs, times four; Microsoft documents that Generation 2 ships three large NSX edges by default, and four when cluster 1 has four or more nodes, so at the large size from its own example, eight vCPUs, that is 96 cores in the ordinary case and 128 in a cluster like the ten-host one above.

With one condition that has to be said out loud, because it changes who that figure lands on: those 720 are for a brand-new private cloud entirely on BYOL. If your ten hosts are covered by license-included reservations that are still live, or are pay-as-you-go nodes deployed before 15 October 2025, you have nothing to register today. And if you enabled vDefend before 16 October 2025 with an active license-included reservation, you keep those firewall cores until the reservation expires or 30 August 2027, whichever comes first. The 720 are not today's invoice: they are the floor on the day the reprieve runs out.

It is only fair to add that this applies only if you switch those features on, and from what we see there are deployments that never touch the distributed firewall because segmentation happens at another layer. But switching it on takes a policy; it never goes through procurement, and that asymmetry between how cheap it is to turn on and how expensive it is to leave on is where the unpleasant gaps show up in a review.

Why you will not find a price per core here

It would be very easy to close the previous section by multiplying 720 by a dollar figure and walking off with a tidy headline. We are not going to. The per-core prices for VMware Cloud Foundation circulating online come from licensing consultancies, not from a public Broadcom tariff we can open and verify word for word, and putting them in here would turn a solid calculation into a decorated estimate. The cores are a firm number, because they come from the cloud provider's own table. Multiply by the figure on your own quote, which you do have.

And while we are at it, we will say it straight: we are not VMware resellers and we are not Proxmox resellers, and we take no commission on any licence from either. The fact that this post is signed by a company that also does Proxmox migrations does not make it an advert.

What happens if the numbers do not add up

The documentation is explicit. In its FAQ, on deploying more cores than Broadcom has licensed you: "The private cloud becomes noncompliant and is at risk of suspension." And in the firewall section it is blunter still: "Microsoft may suspend a noncompliant private cloud until the issue is resolved." What stops there is the service. An administrative mismatch between what you bought in one portal and what you registered in another leaves the environment at risk of being stopped.

There is one more question in that FAQ worth keeping in mind, because it is the scenario that slips through most easily: what happens if the VCF subscription expires before the Azure reservation ends. The answer is that the subscription expiry does not affect the reservation, but it leaves the BYOL hosts noncompliant. Two contracts with two different calendars and two different vendors, and the one that runs short governs the other. Renewing the Broadcom one before its date and updating the registration needs an owner and a date in somebody's calendar.

There is another line on the same page that we find just as revealing and that almost nobody will quote: Microsoft "reports BYOL registrations and associated customer data to Broadcom monthly to meet partner compliance requirements." There is a periodic flow of information between your cloud provider and the software vendor, about your environment, which you are not a party to. It is in the public documentation and it follows logically from the model. But it is the same pattern we wrote about a few days ago, when we set out that authority over your infrastructure tends to be spread across companies you have signed nothing with.

The trial that invoices itself after sixty days

A small detail with teeth, in case anyone is thinking of trying the new model before deciding. Three-node trials run for 60 days and require a Broadcom trial key up front, so not even looking gets you out of the conversation with the vendor. Before the period ends you have to provide a purchased Broadcom subscription covering the deployed cores; if that does not happen, the documentation says, trial hosts automatically become billed hosts unless you delete the deployment before the trial ends.

When we would not move

Now the part that does not sell. If you have a live reservation running well into 2027, NSX in production with rules somebody wrote sensibly, and a team that knows how to operate vSphere, switching hypervisor this autumn is almost certainly a worse deal than sitting down to renegotiate. Migrating a virtualisation platform is months of inventory, networking, backups, maintenance windows, and people learning new tools while holding the service up.

There is even an argument in favour of the new model that almost nobody is making: an entitlement you buy is yours. The documentation says you can apply the portable subscription per private cloud, and split the cores of one key across several as long as the total registered does not exceed what you purchased. When the licence was welded to the Azure bill there was nothing to take anywhere; now there is, and that is leverage at a negotiating table. Admitting it costs us nothing: we have migrated companies from VMware to Proxmox and we have also recommended staying on VMware when it made sense.

What we would push back on quite hard is doing both at once: negotiating the renewal and migrating the platform in the same quarter, with the same people, without having written down beforehand how you come back if it goes wrong. We have covered that in detail: the rollback plan for a migration gets written before the migration plan.

What we would do in September

  • Pull the expiry date of every reservation. Each one, with its day and its month. It is in the portal, it takes two minutes, and it is the only one that governs your calendar, because if it expires sooner the license-included benefit ends that day.
  • Count the cores with the table and set them next to what you bought. Node type times number of hosts, host by host, and compare with the entitlement you have registered. If the left-hand number is bigger than the right-hand one, you are already out of compliance even though nobody has told you.
  • Find out whether the firewall is "enabled" by Microsoft's definition. With the console open: go into NSX and look for nondefault distributed firewall policies and IPFIX profiles, and the same for gateway ones. It is a short session in the console and it avoids a gap of hundreds of cores.
  • Check the registration if you come from the old model. Anyone who registered BYOL by email before November 2025 had to re-register each private cloud through the portal by 31 March 2026. If that task died in somebody's inbox, it is a silent problem today.
  • Decide the destination before December. Buy VCF and stay, move the workloads elsewhere, or split the estate: all three are reasonable and all three need months. Reach the date without having chosen and the calendar chooses for you.

What has changed here, more than the price, is who answers for what. Licence compliance came inside the service you contracted and it was the provider's problem; now it is yours, it is measured in cores registered in a portal, and it is checked every month. It is the same kind of move we saw when the monthly-billing uplift started arriving by calendar rather than by negotiation. Nobody raises your price in one go; the floor moves and it falls to you to redo the sums.

Sources (verified on 21 August 2026): the four dates (15 Oct 2025, 1 Nov 2025, 31 Oct 2026 and 30 Aug 2027), the callout about reservations expiring earlier, the cores per host type (AV36/AV36P 36, AV48 48, AV52 52, AV64 64), the 192 and 252/144 core examples, the vDefend firewall counting rule and its example of 360 cores for ten AV36P hosts, the gateway firewall formula and the Generation 2 edge counts, the definition of "enabled" for the distributed firewall, the coverage retained by reservations and by nodes predating 15 and 16 October 2025, the 60-day trial conditions, the suspension of a noncompliant private cloud, the effect of a VCF subscription expiring before the reservation, the monthly report to Broadcom and the 31 March 2026 deadline for legacy registrations, all from the portable VCF licensing reference for Azure VMware Solution on Microsoft Learn, article dated 14 August 2026 and last updated on the 17th. The 20 August press coverage and the framing that Azure was one of the last ways to use VMware outside the bundle, from The Register. The 720-core total for ten AV36P hosts and the 96 and 128 gateway firewall figures are our own calculations, worked out by applying the counting rules on that same page. Quotes are given in their original English so they can be verified word for word. We do not include per-core prices because the ones in circulation do not come from a public Broadcom tariff.

Do you know how many cores you have deployed and how many you have registered?

Counting the estate, setting the sum next to the invoice and deciding where your machines run for the next five years is infrastructure and cloud work. And doing it without the recommendation depending on who pays the commission is what we mean by consultancy: we sell neither VMware nor Proxmox licences, so the answer may perfectly well be "stay where you are and renegotiate."

Talk to everyWAN

Tags:

Share:

Subscribe to our newsletter

To receive IT stories, everyWAN news and exclusive subscriber offers, sign up to our mailing list

Minorisa de Sistemas Informaticos y Gestión S.L. © 2026
everyWAN
everyWAN