How does Oracle count licenses in the cloud?
Oracle counts licenses in the cloud by vCPU under its cloud computing policy, and on authorized public clouds the rule is that two vCPUs equal one Oracle processor license where hyper threading is enabled. Where a virtual machine is configured so that a vCPU maps to a full physical core rather than a thread, one vCPU counts as one processor. This is a different mechanic from on premises licensing, which counts physical cores multiplied by the core factor table. In the cloud the core factor table does not apply on the authorized clouds, and the vCPU count is the basis instead.
The authorized clouds Oracle names in this policy are Amazon Web Services and Microsoft Azure. For Named User Plus licensing the same user minimums apply, calculated against the processor count the vCPUs produce. The practical effect is that an instance with eight vCPUs and hyper threading is four Oracle processor licenses, and an instance with sixteen vCPUs is eight. Because the count rises in direct step with instance size, the single most effective control a buyer has in the cloud is choosing an instance shape that matches the licenses already owned, rather than oversizing and creating a shortfall.
Is the Oracle cloud computing policy part of the contract?
No, the cloud computing policy is a policy document and not the contract, and the signed agreement governs where the two conflict. This is the same distinction that decides virtualization disputes, and it matters just as much in the cloud. Oracle publishes the cloud policy and can revise it, but the rights that bind the parties live in the Oracle Master Agreement and its ordering documents. A cloud finding that rests on the policy is only as strong as the policy's standing against the contract, and that standing is frequently weaker than the finding implies.
The buyer move is to read any cloud claim against the agreement rather than accepting the policy as a settled rule. Where the contract defines the licensing metric, or where it predates the cloud policy and never incorporated it, the policy based count can be contested at its foundation. Contract language beats policy, and a finding presented as fixed is in practice an opening position. Treating the cloud computing policy as Oracle's argument, not as binding law, is the starting point for any cloud licensing review.
| Instance shape | Oracle policy view | Buyer move |
|---|---|---|
| 8 vCPU, hyper threaded | 4 processor licenses | Size to owned licenses |
| 16 vCPU, hyper threaded | 8 processor licenses | Confirm need before scaling |
| Autoscaling group | Peak vCPU counted | Cap and evidence the ceiling |
| Unauthorized cloud | Core factor may apply | Read the contract first |
Does moving Oracle to the cloud trigger an audit?
Moving Oracle to the cloud can trigger an audit, because cloud migration is one of Oracle's recognised audit triggers, sitting alongside virtualization, Java downloads without a subscription, mergers and acquisitions, declining support spend and rejected sales proposals. A migration is visible to Oracle through support records and licensing questions, and it often coincides with the kind of estate change that draws audit attention. The lesson is not to avoid the cloud, but to settle the licensing position before the workload moves rather than after.
The risk concentrates where deployments grow faster than the records that explain them. An instance resized upward, an autoscaling group that peaks higher than expected, or a workload that lands on more vCPUs than the licenses cover all create exposure that surfaces in an audit. Oracle's collection scripts can read cloud deployments broadly, and preliminary findings arrive inflated at list price. The buyer move is to plan the migration with the count modelled in advance, hold the evidence of the real footprint, and review any script output before it is submitted.
What evidence limits a cloud finding?
The evidence that limits a cloud finding is the contemporaneous record of instance shapes, vCPU counts and scaling ceilings that proves what the deployment actually was. In the cloud, configuration is data: instance types, the state of hyper threading, autoscaling minimums and maximums, and the dates these settings were in force are all recoverable from the platform. That record turns a broad claim into a precise count, because it shows the licensable basis rather than letting Oracle assume the maximum the account could in theory have run.
This evidence also supports the contract argument. When a buyer can show the exact vCPU footprint and the dates it applied, a finding built on a wider assumption loses its factual base, and the contract reading does the rest. An independent line by line review of findings typically cuts claims by 60 to 80 percent, and cloud findings, which are often built on peak capacity or whole account assumptions, are a common place for a large reduction. The work is to assemble the deployment record, set it against the policy claim, and read both against the signed agreement.
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: counting vCPUs on AWS and Azure, and BYOL to the cloud done right.