Core based licensing, CALs, and Azure Hybrid Benefit: the on premises estate that still funds a large part of the bill. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session twenty two of forty. Last session was the Azure consumption commitment, which is where the cloud spend gets promised. Today is the estate that still runs underneath a lot of it, which is Windows Server and SQL Server. And I want to start with a claim that sounds like an exaggeration and is not: the same physical host, running the same workloads, can cost wildly different amounts depending only on how it is licensed. Not on what it does, not on how hard it works, purely on edition, density, and whether Software Assurance is attached to it. That is unusual. Most of this course has been about matching a purchase to a requirement, and this session is about the fact that the requirement can be met at several very different prices. Which means the work here is arithmetic rather than negotiation, and it is arithmetic that most estates have never actually done.
Five takeaways. One, the per core model: Windows Server and SQL Server license per physical core, with a sixteen core minimum per host and a four vCPU minimum per virtual machine. Two, editions decide virtualisation: Standard licenses two virtual machines per licence, Datacenter licenses unlimited, and that single choice moves the cost of a dense host enormously. Three, Software Assurance gates everything: Hybrid Benefit, licence mobility, and unlimited SQL virtualisation all require it, which is why session nine's SA audit is a prerequisite for this session. Four, Hybrid Benefit is the big number: it can cut Azure compute cost by forty to eighty percent, and SQL Server cores carry the largest single saving, often fifty to seventy percent of the workload cost. Five, and it is routinely wasted: eligible Windows and SQL licences sat unused in most estates reviewed, leaving twenty to fifty percent of available savings on the table.
The per core model, three facts that decide the arithmetic. Per physical core rather than per server: both products license the physical cores in the host, so a bigger host costs more even if the workload on it is identical, which quietly makes hardware refresh a licensing decision as much as an infrastructure one. Minimums apply regardless of use: every host carries a sixteen core minimum and every virtual machine carries a four vCPU minimum, so a small host is licensed as though it were a sixteen core host and a two vCPU virtual machine is licensed as though it had four. And the edition changes the model rather than just the price: Windows Server Standard licenses two virtual machines per licence while Datacenter licenses unlimited on that host, so the correct edition depends entirely on virtual machine density. The consequence is that edition, density, and Software Assurance decide the cost, and none of those are technical decisions, though all three are usually made by technical people.
Minimums and editions, what you are actually counting. Sixteen core host minimum: every host is licensed to at least sixteen cores, which means small hosts are overpriced per workload and consolidation therefore pays twice, once in hardware and once in licensing. Four vCPU virtual machine minimum: every virtual machine to at least four vCPU, so fleets of small virtual machines cost more than their size suggests, and that is a real finding on estates that have deliberately built small. Windows Standard: two virtual machines per licence, fine at low density, expensive once you are stacking licences on a dense host. Windows Datacenter: unlimited virtual machines on the licensed host, which is the right answer above a certain density, and the job is to find your crossover. And SQL Enterprise with SA: unlimited virtualisation, the largest single lever on a virtualised SQL estate. There is a crossover on every host, it is a straightforward calculation, and most estates have never run it.
First check. You run a host with twelve physical cores hosting three small virtual machines of two vCPU each. What are you licensing? A, twelve cores and six vCPU, as configured. B, a sixteen core minimum on the host, and each virtual machine counted at the four vCPU minimum, so the configured numbers understate the licensed position in both directions. C, twelve cores only, virtual machines do not count separately. D, one server licence, since it is a single host. Pause it. Both minimums are in play at the same time here, so apply each of them in turn rather than picking one.
The answer is B. And A is worth dwelling on, because A is what your infrastructure inventory will tell you, and it is exactly why licence positions built from a configuration management database come out wrong. The host licenses at sixteen cores even though only twelve exist, and each two vCPU virtual machine counts at the four vCPU floor. Both minimums apply and they apply independently of what the hardware is actually doing. C misses that virtualisation rules interact with the core count through the edition, which is the next slide. D is the pre twenty sixteen intuition, per server licensing, and it has not been the model for a long time yet it persists in conversation more than any other outdated idea in this part of the stack. The habit to build: never quote a licence position from a configuration report without applying the minimums first, because the gap between those two numbers is precisely where compliance findings live.
Virtualisation is the whole game, five rules that move the cost line. Density decides the edition: Standard covers two virtual machines per licence, Datacenter covers unlimited on that host, so run the crossover per host rather than adopting one edition as a policy. SQL Enterprise plus SA unlocks unlimited virtualisation, which on a densely virtualised SQL estate is the single largest lever available, and it exists only while Software Assurance is current. Licence mobility reaches other clouds: SQL Server can move to authorised clouds including AWS, GCP, and Alibaba where the licence carries SA, and that is a genuine competitive lever inside an Azure negotiation. Moving workloads moves the licence: a virtual machine migrating between hosts can change what has to be licensed, and cluster level movement rules are the most common source of accidental non compliance here. And Software Assurance gates most of it, which is the nuance session nine promised.
Guest analyst The server licensing finding I bring up most often was not a compliance problem, it was the opposite, and I think that is why it stuck with me. A manufacturing group, large virtualised estate, and they had brought us in because they were worried about SQL exposure ahead of a possible audit. So we built the entitlement position, which took about three weeks because the records were scattered across four different purchasing histories, and that is normal rather than unusual. And what we found was that they were substantially over licensed, not under. They had been buying SQL Standard licences per virtual machine for years, host by host, as the estate grew, and nobody had ever stepped back and asked whether the density had crossed the point where Enterprise with Software Assurance and unlimited virtualisation would be cheaper. On their two densest clusters it was cheaper by a wide margin. Then the second half, which was the part that changed the number. They had a migration to Azure already underway for part of that estate, and they had not enabled Hybrid Benefit on any of it, because the migration team did not know the entitlements existed and the licensing team did not know the migration had started. Those two facts had been true for about seven months. When we put the entitlement position beside the Azure resource list, the unclaimed benefit on SQL cores alone was worth more annually than the entire compliance risk they had originally called us about. And they had been paying for it the whole time, twice over in effect: once for the licences they owned and again for the licence cost embedded in the Azure rate.
Over licensed on premises and paying full Azure rates on the same workloads. One entitlement position found both. Second check.
Check two. Finance proposes dropping Software Assurance on a heavily virtualised SQL estate to save the annual percentage. What do you say? A, agree, the estate is stable and rarely upgraded. B, it removes unlimited virtualisation, Hybrid Benefit, and licence mobility at once, so the saving has to be tested against three lost levers rather than against upgrade rights alone. C, disagree, SA should never be dropped. D, agree, but only for Windows Server and not SQL. Pause it. Session nine said SA is decided by workload rather than by policy, and this is that principle meeting a virtualised estate.
The answer is B. A is the reasoning from the CFO question in session nine, and on a desktop estate it is frequently right. On a virtualised SQL estate it is usually wrong, because upgrade rights are the least valuable thing SA is doing there. Unlimited virtualisation on SQL Enterprise, Hybrid Benefit for anything heading to Azure, and licence mobility to other clouds all disappear together, and that last one also removes a competitive lever you would want in an Azure negotiation, which is a cost that never appears in the savings calculation. C is the reflex this course argues against in the other direction and it is no better for being cautious. D is genuinely interesting, because it is the right shape: the decision belongs per workload and per product rather than as an estate wide policy, and Windows and SQL do have different profiles. It is only wrong as stated because it arrives at that conclusion without doing the arithmetic first.
Azure Hybrid Benefit, three things to be exact about, and the first is that it is an entitlement reuse rather than a discount code, which is a distinction that matters at audit. What it does: it applies Windows Server and SQL Server licences you already own, with Software Assurance, to Azure compute, so Azure keeps charging for infrastructure and removes the embedded software licence cost, and that is where the forty to eighty percent reduction comes from. What qualifies: Windows Server Datacenter or Standard with SA, SQL Server Enterprise or Standard core licences with SA, and certain qualifying subscriptions, with each licence covering specific core or virtual machine entitlements rather than unlimited use. And what the toggle means: switching the benefit on is an attestation that you hold a covered licence with active SA. That is a compliance statement, not a checkbox, and an auditor can ask you to prove it later, which they do. Dual use on premises and in Azure is permitted only within set limits.
Where the money actually is, and this is what the reviews found. Eligible licences sat unused in most estates reviewed, leaving twenty to fifty percent of available savings on the table. SQL cores are the big one, consistently, often carrying fifty to seventy percent of the workload cost. Benefit applied without SA was a recurring finding, and that is exposure rather than saving, an audit issue quietly accumulating. Wrong edition for density was common, with Standard stacked where Datacenter would have been cheaper on that host. And minimums ignored in the count was very common, producing a licence position that does not survive first contact with anybody checking it. Read the first two rows together, because that is the headline: Hybrid Benefit was either underused or misapplied in most estates reviewed, and the largest concentration of value sits in SQL Server cores. An afternoon there returns more than a quarter of negotiation does on most of this course's other topics.
Last check. Your team enabled Hybrid Benefit across a set of Azure SQL virtual machines. What must exist for that to be safe? A, nothing, the toggle is available in the portal so the right must exist. B, owned qualifying licences with active Software Assurance, tracked entitlement by entitlement, because the toggle is an attestation you may be asked to prove. C, an Azure subscription in good standing. D, approval from the Azure administrator. Pause it, and as you think, ask yourself what you would actually show an auditor who asked why that particular toggle was switched on.
The answer is B. A is the assumption that produced one of the recurring findings in these reviews, which is benefit applied to virtual machines without matching Software Assurance. The portal will let you switch it on. Nothing checks your entitlement at the moment you do it, and that absence of friction is exactly what makes it dangerous, because the saving appears immediately and the exposure appears years later during an audit, by which time the person who clicked it has usually moved on. C and D both describe permission to operate the platform rather than a right to the software, and conflating those two is the underlying error in all three wrong answers. What you actually need is a tracked entitlement position: which licences, how many cores, whose SA is current, mapped to which resources have the benefit enabled. And estates that hold that mapping claim more benefit rather than less, because they can finally see what is still unused.
The server estate method, three steps, and the first one is usually missing. One, build the entitlement position: what you own, at what core counts, with SA current or not, per product. Not what is deployed, what is owned. Most estates can produce a deployment inventory in a day and an entitlement position in a month, and it is the second one that decides everything in this session. Two, map benefit to entitlement: every Azure resource with Hybrid Benefit enabled matched to a specific owned licence with active SA, where unmatched resources are exposure and unmatched licences are unclaimed savings, and both fall out of the same exercise. Three, run the edition crossover per host: virtual machine density against stacked Standard cost and Datacenter cost, a short calculation that on a large estate routinely moves more money than the discount conversation. And do all three before an Azure migration wave rather than after it.
Session twenty two, three sentences. One: Windows Server and SQL Server license per physical core with a sixteen core host minimum and a four vCPU virtual machine minimum, so a position taken from a configuration report is wrong before anybody argues about it. Two: edition decides virtualisation rights, Standard covering two virtual machines per licence and Datacenter unlimited, so the correct edition is a per host calculation from density rather than an estate wide policy. Three: Azure Hybrid Benefit can cut Azure compute cost by forty to eighty percent with SQL cores carrying the largest share, and it was underused or misapplied in most estates reviewed, which makes the entitlement position the highest return artefact in this part of the stack. Next session moves from infrastructure to applications, and to a product family where the licensing model itself is the trap.
Homework, about an hour, and this week you check the toggles. One, list the benefit claims: every Azure resource with Hybrid Benefit enabled, one list from the portal, which takes minutes. Two, match them to entitlement: for each one, which owned licence covers it and is its Software Assurance current, and anything you cannot match is a question rather than a saving. Three, find the unused: eligible Windows and SQL licences with SA that are not being applied anywhere, because most estates have some and some estates have a great deal. Four, apply the minimums: take one host and recount it properly at the sixteen core and four vCPU floors, then compare against what your inventory told you. Five, run one crossover on your densest host, stacked Standard licences against a single Datacenter licence, because that one calculation usually generalises across the estate.
Five reads before next session, all free on redress compliance dot com. First, the Azure Hybrid Benefit guide, covering what qualifies, the rules, the pitfalls, and the savings model. Second, licensing Windows Server and SQL Server, a practical guide carrying the per core maths, the editions, the virtualisation rules, and licence mobility. Third, Azure Hybrid Benefit optimisation, on finding the benefit that is eligible and unclaimed, which is the homework in article form. Fourth, Windows and SQL licensing in hybrid environments, for the governance around a split on premises and cloud estate. And fifth, avoiding common compliance pitfalls in SQL Server licensing, on where the findings actually come from, which turns out to be mostly counting. Next session is Dynamics 365: the metric families, the base and attach structure, and the sprawl that shows up at renewal. See you there.