I made a blog post recently called Hard Work Isn’t Enough. Add Value or Get Stuck. If you haven’t read that yet, I suggest you go check that out first.
Minimizing CPU core counts is a perfect example of how to add value, and is arguably one of the easiest ways to do so.
I run this exercise in my environments about every six months, typically right before true-up time and again at mid-year, just to make sure we haven’t drifted too far.
How expensive is SQL Server licensing?
Very expensive.
If you’re running Enterprise Edition, you’re going to pay around $7,561.50 per core. Core licenses are sold in 2-core packs, and there’s a 4-core minimum per server. If you need more cores, you must add them in 2-core increments, as you cannot split a license pack across multiple servers.
Note: Pricing varies depending on licensing program (EA, CSP, Select Plus).
That puts the minimum cost of an Enterprise SQL Server VM at:
$7,561.50 × 4 cores = $30,246 (and that’s before Software Assurance)
Want to run that VM in an HA or DR configuration? SA is required if you want to run your HA/DR replicas as free passive nodes – up to one passive HA replicas, one passive DR replica, and one passive Azure replica.
Note: If a replica performs readable queries or takes backups, it no longer counts as passive and must be fully licensed. This is one reason I don’t recommend running backups on your secondary replicas — but I digress. If you want to know the other reason, read: SQL Server Backups on Secondary Replicas: Best Practice or Bad Idea?
How much is Software Assurance?
Software Assurance typically runs around 25% of the licensing cost per year.
So if you paid $30,246 to license a 4-core SQL Server, expect to pay:
$7,561.50 per year for SA.
Yes — annually.
So, how can I reduce this cost?
The 4-core example was just to illustrate the math. In the real world, it’s not uncommon to find SQL Servers running with 16, 32, 64, or more cores. You can see now how expensive these could get.
But how do you decide if you actually need all of those cores?
Look at CPU trends over the past 33+ days.
You want at least 33 days because many workloads have monthly processing cycles, and shorter windows may give you a false sense of stability.
You’re looking for peak CPU usage, not averages.
Averages are misleading — because when that monthly job kicks off and you don’t have enough cores, things can come crashing to a halt fast.
What I typically find the first time I run this analysis:
• Most SQL Servers peak at **40–50% CPU**
• I once saw a SQL VM with **64 cores** using only 30% at peak
But don’t go straight to the floor.
If you have 8 cores and peak at 45%:
• Don’t drop directly to 4
• Drop to 6
• Monitor performance
• Adjust again if needed
Keep in mind that reducing vCPUs on any VM always requires a reboot, so schedule the change during a maintenance window.
This approach avoids risk while saving real money.
Ideal CPU targets
• Short bursts: 80–90%
• Sustained peaks: 60–70%
• Off-hours: 20–30%
If you’re consistently below these thresholds, you’re likely over-allocated.
What next?
With all the money you just saved, go invest in a great database monitoring solution.
It will pay for itself after just a single right-sizing exercise.
If you like what you’ve read, please subscribe so you don’t miss my latest posts…
Brendan McCaffrey 
2 Comments