Blog Post

Data Architecture Blog
3 MIN READ

Constrained vCPU and Oracle Licensing in Azure

DBAKevlar's avatar
DBAKevlar
Icon for Microsoft rankMicrosoft
Dec 17, 2021
Numerous times I’ve experienced misunderstanding on licensing around constrained vCPU VMs.  Sometimes the confusion is on the term, “constrained”, (I would have named this VM type, “Same CPU, bigger ...
Published Dec 17, 2021
Version 1.0
data architecture
xpabu's avatar
xpabu
Copper Contributor
Dec 21, 2021

Hi DBAKevlar ; excellent blog. I agree with all technical aspects of it, however I should raise what I've seen Oracle do in audits -- they have a particular aversion to constrained CPUs in either Azure or AWS and try and base their assessments on the original instance CPU size rather than the constrained number of vCPU. We have seen this in many cases during audit and also at less formal times, the assertion always being "you must license based on the 'original' vCPU count of the instance irrespective. Your E16ds should be licensed on the basis of 8 cores in their eyes.

 

This has recently been 'strengthened' with the 1 December 2021 updates, specifically: "customers are required to count the maximum available vCPUs of an instance type". Such a statement is still far from 'rock solid', but you could say that about the whole non-contractual document. Any assertion on the basis of maximum vCPUs is non-sensical, based on your analysis above: why on earth would anyone license cores which are not presented in any way to your instance?! There's no business benefit to the licensee for paying license for unusable cores (this extends into other 'unrecognised' configurations such as BIOS-disabled cores)!

 

There are different ways to approach this, not limited to the below:

  1. ignore the 'clarified' maximum language; use an older version of the ACE document
  2. don't release instance type to Oracle during a review, you almost certainly have no contractual obligation to do so. Simply tell Oracle 'it's 8 vCPUs with HT on'. They won't like this but it is a valid approach.
  3. disregard the whole document as it is non-contractual, base license count on contract only. Oracle will like this less but you will get to use your core factor and you will actually be better contractually-aligned; the use of the core factor table is contractually defined

Each has its own considerations based on 'risk' profile and appetite for an argument. What it is fair to say is that you shouldn't always assume "Oracle is going to use the correct procedure to audit" --we've seen many instances of this not being correct.