How do you calculate Oracle cloud licenses from vCPUs?
You calculate Oracle cloud licenses by dividing the running vCPU count by two where hyper threading is enabled, so a 32 vCPU Oracle estate on an authorized cloud is 16 processor licenses. In this anonymized example, a mid sized financial services firm ran Oracle Database Enterprise Edition across four instances of eight vCPUs each on an authorized public cloud. Thirty two vCPUs at two per processor is a clean sixteen processor licenses, and the firm held exactly sixteen. On the steady state footprint, the estate was compliant.
The preliminary finding told a very different story. It claimed the firm needed more than fifty processor licenses, a figure roughly three times the steady state. The gap did not come from the running instances. It came from two assumptions layered on top of them: that the autoscaling group should be counted at its maximum permitted size rather than its real usage, and that a disaster recovery standby in a second region was a fully active deployment. Both assumptions pushed theoretical capacity into the count, which is the classic shape of an inflated cloud finding.
| Element | Oracle finding | Verified position |
|---|---|---|
| Four 8 vCPU instances | 16 processors | 16 processors |
| Autoscaling headroom | Counted at peak | Never ran Oracle |
| DR standby, second region | Full deployment | Cold, under 10 days |
| Total claimed | 50 plus processors | 16 processors |
Why was the cloud finding inflated?
The cloud finding was inflated because it counted capacity that never ran Oracle and a standby that sat cold, treating both as fully licensable. The autoscaling group was configured to scale up to a large ceiling for a different application tier, and Oracle was pinned to four fixed instances that never participated in that scaling. Counting the autoscaling maximum assumed Oracle could run on instances it was never deployed to. The platform configuration showed the pinning plainly, which is why the assumption did not survive contact with the evidence.
The standby was the second source of inflation. It was a cold disaster recovery node in another region, brought up only to test failover, and the failover log showed it ran Oracle on six days across the year, well inside the 10 day rule. The finding had counted it as a continuously active second deployment. Once the autoscaling pinning and the failover log were on the table, the theoretical capacity fell away, and the count returned to the sixteen processors the running instances actually used.
What was the buyer move?
The buyer move was to rebuild the count from the real footprint, support it with platform evidence, and read the whole finding against the contract. The team pulled instance configuration showing the four pinned Oracle instances, autoscaling settings showing Oracle was excluded from the scaling group, and the dated failover log for the standby. That evidence converted the finding from a claim about what the account could run into a count of what it did run. The cloud computing policy is a policy document and not the contract, so the contract reading carried the remaining weight.
The verified outcome was a reduction of 70 percent from the preliminary figure, bringing the requirement back to the sixteen licenses the firm already held, with no purchase required. This sits squarely within the pattern that an independent line by line review of findings typically cuts claims by 60 to 80 percent. The lesson generalises: cloud findings are routinely built on peak capacity and idle standbys, and the buyer who holds the configuration evidence and the failover log can return the count to reality. If you are facing a cloud finding and want it costed properly, a quote is the place to start.
The next step
This article is part of our Cloud and OCI Licensing cluster. Read the pillar, the Oracle virtualization licensing guide, for the full picture, and these related reads: cloud DR and Oracle licensing, and autoscaling and the license count.