Core Factor in the Cloud: Why the Multiplier Disappears
Oracle's processor core factor table does not apply in the cloud. On OCI, AWS, and Azure, Oracle's cloud policy replaces the core factor with a flat two vCPU per processor rule, so the favourable on premise multipliers such as 0.5 for Intel are gone. The same workload therefore needs roughly twice the licences in the cloud as on premise.
What is the core factor, and where does it apply?
On premise, Oracle counts processor licences by multiplying the number of physical cores by a core factor drawn from its processor core factor table. An Intel or AMD x86 core carries a 0.5 factor, so sixteen physical cores count as eight processor licences. The table is the mechanism that makes on premise Oracle licensing tolerable on modern high core count hardware, and the full set of factors and rules is set out in the Oracle core factor table guide.
The instinct of every buyer who knows the on premise rules is to carry the core factor into the cloud, because it is so central to the on premise calculation. That instinct is wrong, and acting on it is the most expensive single error in cloud licensing. The cloud is governed by a different document with a different rule, and the core factor simply does not appear in it. Understanding why is essential to the whole Oracle OCI licensing model.
The cloud policy that removes the factor
Oracle's cloud counting lives in the Licensing Oracle Software in the Cloud Computing Environment policy, which governs authorized cloud environments. That document defines counting in vCPUs and states a flat conversion: two vCPUs equal one processor licence where hyper threading is on, one vCPU where it is off. It does not reference the core factor table at all. The omission is deliberate; the cloud policy is a self contained counting regime, and the core factor table belongs to the separate on premise world.
On OCI the equivalent statement is expressed in OCPUs, where one OCPU equals one processor licence, but the effect is identical because an OCPU already represents the two threads of a physical core. The detailed unit arithmetic is in OCPU versus vCPU, and the list of clouds the policy covers is in authorized cloud environments. The common thread is that no multiplier softens the count.
The doubling effect on BYOL
The practical consequence is that a workload needs roughly twice the processor licences in the cloud as it needed on premise, for identical compute. The arithmetic is direct: sixteen physical Intel cores counted as eight licences on premise at the 0.5 factor. The same sixteen cores in the cloud present as thirty two vCPUs, which count as sixteen licences under the two vCPU rule. The favourable factor is gone, so the count doubles.
| Environment | Counting rule | Licences for 16 Intel cores |
|---|---|---|
| On premise | 16 cores × 0.5 core factor | 8 processor licences |
| OCI | 16 OCPUs × 1 | 16 processor licences |
| AWS / Azure | 32 vCPUs ÷ 2 | 16 processor licences |
For a BYOL migration this is decisive. A customer carrying eight processor licences that fully covered the on premise workload will find those same eight licences cover only half the cloud deployment. The gap is not a rounding error; it is the entire core factor, and it must be budgeted as either additional licences or a smaller cloud footprint. This is the central warning in OCI migration licensing.
The doubling is not uniform across architectures, which is worth flagging for estates that ran Oracle on higher factor hardware. A workload that sat on a processor carrying a 1.0 core factor on premise sees no doubling at all in the cloud, because there was no favourable multiplier to lose; its on premise and cloud counts are already aligned. The dramatic doubling is specific to the commodity x86 estate that benefited from the 0.5 factor, which happens to be the majority of modern deployments and therefore the majority of migrations.
Why does Oracle remove the core factor in the cloud?
The core factor exists on premise to reflect the relative performance of different processor architectures, giving lower factors to commodity x86 cores and higher factors to high performance RISC chips. In the cloud, Oracle standardises on a uniform vCPU abstraction, so the architectural distinction the factor encoded no longer applies in the same way. The flat two vCPU rule is simpler to administer and, not coincidentally, more favourable to Oracle's revenue than carrying the 0.5 factor forward would be.
Whatever the rationale, the rule is settled and a buyer must plan around it rather than dispute it. The factor is a policy choice Oracle has made consistently across OCI and the authorized clouds, and no amount of architectural argument recovers it. The only lever the buyer holds is to size the cloud deployment efficiently and choose the right licensing model, not to recover a multiplier that the policy has removed. That sizing discipline is the work of the cloud and OCI practice.
The Standard Edition exception
Standard Edition 2 is the one place where cloud counting can be more generous than on premise, and it partly offsets the loss of the core factor for smaller workloads. SE2 is socket based on premise, but the cloud policy maps it to a per OCPU or per vCPU model that allows up to eight OCPUs on OCI, or four vCPUs on AWS and Azure, per socket equivalent. For a workload that fits within SE2, the cloud mapping can cover more compute per licence than Enterprise Edition ever would.
This makes SE2 worth a deliberate look during cloud planning for databases that do not need Enterprise Edition features. Where a workload could run on SE2, the generous cloud socket mapping may make it dramatically cheaper than an Enterprise Edition deployment that has lost its core factor. The SE2 detail sits alongside the Enterprise counting in OCPU versus vCPU, and the edition choice is part of the database licensing analysis.
How to plan around the lost factor
Planning around the lost core factor comes down to three moves. First, recalculate every workload's cloud requirement using the two vCPU rule, not the on premise count, so the doubling is visible in the plan rather than discovered after cutover. Second, decide per workload whether to buy the additional licences, accept a smaller cloud footprint, or use License Included, which prices in the doubling implicitly through its per OCPU rate. Third, evaluate SE2 for any workload that does not need Enterprise features.
The recalculation is the non negotiable step. A migration plan built on the on premise licence count is wrong by a factor of two, and that error compounds across the estate into a major unbudgeted exposure. Building the plan on the cloud count from the start is the difference between a migration that lands on budget and one that triggers an emergency purchase or an audit finding. The recalculation is the first deliverable in any OCI migration the practice runs.
The recalculation should be paired with a deliberate look at whether the cloud workload truly needs the same core count as on premise. Cloud processors are often newer and faster than the hardware being retired, so a workload may perform adequately on fewer OCPUs than its on premise core count would suggest. Right sizing down on faster silicon can partially offset the lost core factor, turning a blunt doubling into a more manageable increase, but only if the sizing is tested rather than assumed.
The audit consequence of getting it wrong
A buyer who applies the core factor in the cloud creates a shortfall equal to half the deployment, and because OCI and the hyperscalers do not enforce entitlement at provisioning, that shortfall runs silently until an audit surfaces it. Oracle then values the gap across every month it existed, plus back support, with the customer in a weak negotiating position because the error is unambiguous. The misapplied factor is one of the cleanest findings Oracle can make, which is exactly why it is so costly.
The defence is to never apply the factor in the first place and to keep a dated reconciliation that counts every cloud workload under the two vCPU rule against held entitlement. A position calculated correctly and documented as it is built leaves no factor shaped gap for an audit to find. Where a gap already exists from an earlier miscalculation, the cloud and OCI practice quantifies and remediates it before Oracle does.
Where a historical gap is found, the remediation sequence matters. Quantifying the exposure internally, correcting the deployment or acquiring the licences, and documenting the correction with dates puts the customer in control of the narrative before any Oracle contact. A gap that the customer has already identified and closed is a very different conversation from one Oracle discovers first, and the difference frequently shows up directly in the commercial outcome.
The buyer side view
The core factor table is an on premise mechanism that the cloud policy removes entirely, replacing it with a flat two vCPU per processor rule. The result is that identical compute needs about twice the licences in the cloud as on premise, and a BYOL migration that ignores this is short by half. Recalculate every workload under the cloud rule, evaluate SE2 where Enterprise features are not needed, and never carry the 0.5 factor into a cloud plan. To recalculate your cloud licence requirement correctly, request a consultation.
Common questions.
Does the Oracle core factor apply in the cloud?
No. Oracle's cloud policy replaces the processor core factor table with a flat two vCPU per processor rule on OCI, AWS, and Azure. The favourable on premise multipliers such as the 0.5 Intel factor do not apply, so the cloud count is not reduced by any core factor.
Why does cloud licensing cost about twice as much?
Because the on premise 0.5 core factor disappears. Sixteen Intel cores counted as eight licences on premise but present as sixteen licences in the cloud under the two vCPU rule, doubling the requirement for identical compute.
Where is the cloud counting rule defined?
In Oracle's Licensing Oracle Software in the Cloud Computing Environment policy, which governs authorized cloud environments. It counts in vCPUs at two per processor licence and never references the core factor table, making it a self contained counting regime.
Does the core factor removal affect BYOL?
Yes, decisively. Licences that fully covered an on premise workload cover only about half the same workload in the cloud, because the count doubles. A BYOL migration must budget the difference as additional licences or a smaller cloud footprint.
Is Standard Edition 2 also affected?
SE2 is the exception. Its cloud mapping of up to eight OCPUs or four vCPUs per socket equivalent can be more generous than on premise, partly offsetting the loss of the core factor for smaller workloads that do not need Enterprise Edition features.
Can I argue to keep the core factor in the cloud?
No. The removal is a consistent Oracle policy choice across OCI and the authorized clouds, and no architectural argument recovers it. The only levers are efficient sizing, the right licensing model, and evaluating SE2, not disputing the rule.