OCPU vs vCPU: How Oracle Counts Cloud Cores
An OCPU is one physical core with hyper threading on Oracle Cloud Infrastructure, while a vCPU is one hardware thread, so one OCPU equals two vCPUs. For licensing, Oracle counts every two vCPUs on an authorized cloud as one processor licence, ignoring the on premise core factor table entirely.
What is the difference between an OCPU and a vCPU?
An OCPU, or Oracle Compute Unit, is Oracle's billing unit on Oracle Cloud Infrastructure and represents one physical processor core with hyper threading enabled. A vCPU, or virtual CPU, is the unit used by Amazon Web Services and Microsoft Azure and represents a single hardware thread. Because a modern x86 core exposes two threads, one OCPU is equivalent to two vCPUs on the same silicon. This single conversion governs almost every cloud licensing calculation a buyer will ever run, and getting it wrong is the most common reason a cloud estate is over or under licensed.
The distinction matters because Oracle prices and meters OCI in OCPUs but counts licences on AWS and Azure in vCPUs. The same workload therefore looks different depending on where it runs, even though the underlying entitlement is identical. A buyer who reads an OCI shape specification in OCPUs and an AWS instance specification in vCPUs without converting between them will misstate the licence requirement by a factor of two. The conversion is not optional arithmetic; it is the heart of the Oracle OCI licensing model.
It helps to anchor the units to physics. A physical server core is a single execution engine; hyper threading exposes it to the operating system as two logical processors so the core can interleave two instruction streams and keep its pipelines full. Oracle's OCPU maps to the physical engine, while a vCPU maps to one of the two logical processors. Once a buyer holds that picture, every cloud counting question reduces to whether the unit in front of them is the physical engine or one of its threads, and the conversion follows automatically.
The Oracle cloud policy that sets the rule
The counting rule lives in a single Oracle document, the Licensing Oracle Software in the Cloud Computing Environment policy. It is a policy, not a contract clause, which is the first thing every buyer should internalise: Oracle can revise it, and the version that governs your deployment is the one in force when you provision. The policy defines an authorized cloud environment, names AWS and Azure as such alongside OCI, and sets the conversion between licences and cloud capacity.
Under that policy, when counting Oracle Processor licences for Enterprise Edition on an authorized cloud, you count two vCPUs as one Oracle Processor licence where hyper threading is enabled, and one vCPU as one licence where it is not. On OCI the equivalent statement is that one OCPU requires one Enterprise Edition processor licence, because one OCPU already represents the two threads. The two statements describe the same physics from two unit systems. The deployment specifics are worked through in Oracle Database on AWS and the broader set of authorized cloud environments.
Because the rule lives in a policy rather than a contract, a prudent buyer captures the version of the policy in force on the day each workload is provisioned and keeps it with the deployment record. Oracle has revised cloud counting before, and the entitlement you can defend is the one that matched the policy at the time. Treating the policy as a dated, versioned input rather than a fixed fact is the same discipline that protects every other cloud licence position.
Why the core factor table stops applying
On premise, Oracle multiplies physical cores by a core factor drawn from the processor core factor table, so an Intel Xeon core counts as 0.5 of a processor licence. The instinct of every experienced licensing analyst is to apply that 0.5 in the cloud as well. The policy explicitly removes it. On AWS and Azure the core factor table does not apply at all; the rule is purely two vCPUs to one licence. On OCI the OCPU already bakes the physical core into the unit, so no separate multiplier is layered on top.
The consequence is stark. A workload that needed sixteen physical cores on premise counted as eight processor licences after the 0.5 factor. The same workload on AWS, sized at thirty two vCPUs, counts as sixteen processor licences under the two vCPU rule. The cloud requirement is double the on premise requirement for identical compute, purely because the favourable core factor is gone. This is the trap examined in detail in core factor in the cloud, and it is why a like for like cloud migration is rarely licence neutral. The on premise mechanics are set out in the Oracle core factor table guide.
How Standard Edition 2 is counted
Standard Edition 2 follows a different and more generous mapping. On premise, SE2 is licensed by socket and is restricted to servers with a maximum of two sockets. In an authorized cloud the policy maps SE2 to a per OCPU or per vCPU model: on OCI, up to eight OCPUs is treated as one SE2 socket equivalent, and the same workload on AWS or Azure maps four vCPUs to one socket. The practical effect is that SE2 can cover materially more cloud compute per licence than Enterprise Edition.
| Program | OCI counting | AWS / Azure counting |
|---|---|---|
| Enterprise Edition | 1 OCPU = 1 processor licence | 2 vCPUs = 1 processor licence |
| Standard Edition 2 | Up to 8 OCPUs = 1 socket | Up to 4 vCPUs = 1 socket |
| Options and packs | Counted like the base EE metric | Counted like the base EE metric |
| Hyper threading off | Rare on OCI shapes | 1 vCPU = 1 processor licence |
The SE2 cloud mapping is one of the few places where moving to the cloud can reduce a licence count rather than inflate it, and it is worth modelling deliberately for smaller databases before defaulting to Enterprise Edition. The cost trade offs sit alongside the OCI compute licensing shapes.
Applying the rule under BYOL
When you bring your own licence, the OCPU to vCPU conversion is exactly what determines how much cloud capacity a carried licence covers. A customer holding sixteen Enterprise Edition processor licences can cover sixteen OCPUs on OCI, or thirty two vCPUs on AWS, with no core factor adjustment. The BYOL model is only economic once this conversion is run for the specific shape, because an unfavourable mapping can erode the entire infrastructure saving.
The reconciliation discipline is to record, at provisioning, the OCPU or vCPU count of every shape, the conversion applied, and the entitlement consumed. OCI and the hyperscalers will all let you scale beyond what you own without warning, so the running total of converted capacity against held licences is the single number an audit will test. Where elasticity is the point of the workload, the cleaner answer is often a License Included service that meters consumption rather than entitlement.
What happens when shapes autoscale?
Autoscaling is where the OCPU and vCPU count becomes a moving target. An OCI Autonomous Database with auto scaling enabled can burst to three times its base OCPU allocation, and under BYOL every burst OCPU must be covered by entitlement at the moment it is active. Buyers routinely licence the base and forget the burst ceiling, which means the deployment is compliant at rest and non compliant under load, precisely when nobody is watching the console.
The governance answer is to cap auto scaling at the licensed OCPU count, or to move the elastic workload to a consumption based service where Oracle meters usage and licensing is not the customer's concern. Either choice is defensible; an uncapped BYOL deployment that can silently triple its core count is not. This is one of the recurring findings the audit defence practice sees in cloud reviews.
The audit exposure from miscounting
Miscounting cores is the most common cloud audit finding, and it is almost always a doubling error from a misapplied core factor or an uncounted hyper thread. Because cloud consumption is metered continuously, a counting error does not produce a single point in time gap; it produces months of accumulated non compliance, which Oracle can value across the entire period plus back support. A sixteen core error left running for a year is not a sixteen licence problem, it is a sixteen licence problem multiplied by every month it persisted.
The defensible position is a standing reconciliation that converts every shape to processor licences using the current policy, compares the total to held entitlement, and is dated and retained. When the conversion is documented as it happens, an audit reads it as governance. When it is reconstructed under a data request, it reads as a guess, and Oracle prices guesses conservatively. The cloud and OCI practice builds this reconciliation per estate.
A worked example makes the exposure concrete. A team migrates a sixteen core production database to thirty two vCPUs on AWS, carries its eight on premise processor licences expecting them to suffice, and runs for eleven months before an audit requests vCPU counts. The gap is eight licences across eleven months, valued at full list plus back support, and because the error is a clean misapplication of the core factor, there is no ambiguity for the customer to negotiate against. The same gap caught in an internal monthly reconciliation would have cost only the eight licences, bought deliberately.
The buyer side view
Treat the OCPU to vCPU conversion as the foundation of every cloud licence calculation, not as a detail. One OCPU is two vCPUs is one Enterprise Edition processor licence, the on premise core factor never travels to the cloud, and Standard Edition 2 follows a separate and more generous map. Run the conversion per shape before you commit the architecture, cap autoscaling at what you own under BYOL, and keep a dated reconciliation so the count is governed rather than reconstructed. To validate your cloud core counts against current Oracle policy, request a consultation.
Common questions.
What is an OCPU in Oracle Cloud?
An OCPU, or Oracle Compute Unit, is one physical processor core with hyper threading enabled on Oracle Cloud Infrastructure. Because each core exposes two hardware threads, one OCPU is equivalent to two vCPUs, and one OCPU requires one Enterprise Edition processor licence.
How many vCPUs equal one Oracle processor licence?
On an authorized cloud such as AWS or Azure, two vCPUs equal one Oracle Processor licence for Enterprise Edition where hyper threading is enabled. The on premise core factor table is not applied, so the favourable 0.5 multiplier does not reduce the count.
Does the core factor table apply in the cloud?
No. Oracle's cloud policy removes the processor core factor table for authorized cloud environments. Counting is purely two vCPUs to one licence on AWS and Azure, and one OCPU to one licence on OCI, which often doubles the requirement versus on premise.
How is Standard Edition 2 counted in the cloud?
Standard Edition 2 maps up to eight OCPUs to one socket on OCI, and up to four vCPUs to one socket on AWS or Azure. This is more generous than Enterprise Edition and can make SE2 materially cheaper for smaller cloud databases.
Why does cloud licensing often cost more than on premise?
Because the on premise 0.5 core factor disappears in the cloud. A workload counted as eight licences on premise can count as sixteen in the cloud for the same compute, since the two vCPU rule replaces the core factor multiplier.
Do I need to license autoscaling bursts?
Yes, under BYOL every OCPU active during an autoscaling burst must be covered by entitlement. Cap auto scaling at the licensed count, or use a License Included service where Oracle meters consumption and licensing is handled by the provider.