Short answer: Oracle vCPU counting in the cloud follows one rule: where hyper-threading is enabled, two vCPUs require one Oracle Processor license; where it is disabled, one vCPU requires one Processor license. This applies on AWS, Azure, and Google Cloud, replaces the Core Factor Table, and is the calculation behind most cloud compliance gaps.
Key Takeaways
- The 2:1 rule. With hyper-threading on, two cloud vCPUs = one Oracle Processor license. A 32-vCPU instance running Database EE therefore needs 16 Processor licenses.
- Hyper-threading doubles or halves your bill. Disable it and the ratio becomes 1:1 — the same 32-vCPU instance now needs 32 licenses.
- No Core Factor in the cloud. The 0.5 x86 multiplier does not apply in Authorized Cloud Environments; you cannot stack it on top of the vCPU rule.
- SE2 caps differ by provider. Standard Edition 2 maxes out at 8 vCPUs on AWS and 4 vCPUs on Azure and GCP per database.
- Miscounting is common. In our reviews, vCPU/hyper-threading errors appear in roughly 30% of first-time cloud Oracle deployments we assess (Oracle Licensing Experts, 2026).
How Does Oracle Count vCPUs for Licensing in the Cloud?
Oracle vCPU counting is the method Oracle uses to convert virtual CPUs into Processor licenses in a public cloud. A vCPU (virtual CPU) is the unit of compute a cloud provider presents to your instance — usually one hardware hyper-thread. The rule is fixed: where hyper-threading is enabled, two vCPUs require one Oracle Processor license; where it is disabled, one vCPU requires one Processor license. This applies to Oracle Database Enterprise Edition and most option packs in Authorized Cloud Environments.
The reason Oracle uses vCPUs at all is that you cannot see or count the physical cores inside an AWS, Azure, or Google datacentre, and Oracle publishes no Core Factor for them. So Oracle counts the one number that is visible and verifiable from inside your instance. That makes the calculation simple in principle — but the simplicity hides three traps that generate most cloud back-licence claims: hyper-threading status, the SE2 caps, and the assumption that the Core Factor still applies.
How Does Hyper-Threading Change Oracle vCPU Counting?
Hyper-threading is the single largest variable in cloud Oracle cost. When a cloud instance has hyper-threading (or simultaneous multithreading) enabled, Oracle counts two vCPUs as one Processor license — the 2:1 ratio. When hyper-threading is disabled, each vCPU represents a full core to Oracle, so the ratio becomes 1:1 and the license requirement for the same vCPU count doubles.
This is where buyers lose money without realising it. Most default AWS, Azure, and GCP instance types ship with hyper-threading enabled, so the favourable 2:1 ratio applies — but certain HPC and specialised shapes disable it, and some teams disable it deliberately for performance. If you architect on the assumption of 2:1 and the instance is actually running 1:1, every Oracle workload on it is under-licensed by half. Oracle's audit team checks the actual thread configuration, not your intention. Our Oracle license optimization service validates hyper-threading status across every cloud instance before it becomes audit exposure.
| vCPUs on instance | Hyper-threading ON (2:1) | Hyper-threading OFF (1:1) |
|---|---|---|
| 4 vCPUs | 2 Processor licenses | 4 Processor licenses |
| 8 vCPUs | 4 Processor licenses | 8 Processor licenses |
| 16 vCPUs | 8 Processor licenses | 16 Processor licenses |
| 32 vCPUs | 16 Processor licenses | 32 Processor licenses |
| 64 vCPUs | 32 Processor licenses | 64 Processor licenses |
Oracle's cloud licensing policy is non-contractual, which Oracle's sales team rarely volunteers. The 2:1 vCPU rule you are budgeting against is published in a PDF Oracle can revise at will. We cover that exposure in full in our guide to the Oracle Authorized Cloud Environment policy — but the headline is: count correctly, then get the counting method written into your contract so Oracle cannot move the goalposts mid-term.
Is Oracle vCPU Counting the Same on AWS, Azure, and GCP?
The Enterprise Edition 2:1 rule is identical across AWS, Azure, and GCP, but Standard Edition 2 counting diverges because the three providers define a vCPU differently. On AWS, two vCPUs map to one physical core, so SE2 is capped at eight vCPUs per database. On Azure and Google Cloud, one vCPU maps to one core, so SE2 is capped at four vCPUs per database. The cap exists because SE2 is a socket-based product and the cloud has no sockets to count.
That asymmetry catches teams that lift-and-shift an on-premise SE2 workload into the cloud. On-premise, SE2 simply allows up to two populated sockets per server; in the cloud it is hard-capped at a vCPU number that is often far smaller than the instance they have provisioned. Provision a 16-vCPU box for SE2 on Azure and you are not lightly over-deployed — you are running a configuration SE2 cannot legally occupy. We break the socket mechanics down in our companion piece on Oracle Standard Edition cloud socket rules.
Not sure your cloud vCPU count is defensible?
Our Oracle Cloud advisory service recounts every AWS, Azure, and GCP Oracle workload against the current rules and flags the hyper-threading and SE2 gaps before Oracle's audit team does.
Does the Oracle Core Factor Table Apply to Cloud vCPUs?
No. Oracle's cloud policy states explicitly that the Core Factor Table does not apply in Authorized Cloud Environments. On-premise, an x86 core carries a 0.5 Core Factor, so 32 physical cores require 16 Processor licenses. In the cloud, the 0.5 multiplier is replaced by the vCPU rule — you count vCPUs at 2:1 instead of cores at 0.5. You cannot apply both.
The error we see most often is double-discounting: a team counts 32 vCPUs, halves to 16 under the 2:1 rule, then halves again to 8 by mistakenly applying the Core Factor. That instance is under-licensed by 50%, and it is exactly the kind of arithmetic Oracle's LMS scripts are built to expose. The vCPU rule already contains the only discount the cloud offers; there is no second multiplier. For the broader framework, our Oracle Database Licensing Guide sets out how Processor and Named User Plus metrics interact across on-premise and cloud.
How Do I Calculate Oracle Licenses for a Cloud Instance?
Counting Oracle licenses for a public-cloud instance is a five-step calculation. Follow it in order for every Oracle workload before you deploy — and again before any audit data leaves your organisation.
- Identify the vCPU count of the instance type running Oracle software.
- Confirm hyper-threading state — enabled means 2:1, disabled means 1:1.
- Apply the ratio to convert vCPUs to Oracle Processor licenses (round up to the next whole license).
- Add option packs separately — RAC, Partitioning, Diagnostics Pack, Tuning Pack and Advanced Security each need licensing on the same Processor count.
- Check SE2 caps if you are running Standard Edition 2 — 8 vCPUs on AWS, 4 on Azure/GCP.
A financial-services firm running Oracle Database EE plus Partitioning and Diagnostics Pack across 64 AWS vCPUs had licensed only the base database, missing the option packs on the same Processor count. Our team recounted the estate, quantified the gap before Oracle did, and built the remediation into a contract renewal — converting a potential seven-figure back-licence claim into a planned, discounted purchase. See our client case studies for comparable engagements.
Frequently Asked Questions
How does Oracle count vCPUs for licensing in the cloud?
Oracle counts cloud vCPUs by a fixed rule: where hyper-threading is enabled, two vCPUs require one Oracle Processor license; where it is not enabled, one vCPU requires one Processor license. This vCPU method applies in Authorized Cloud Environments — AWS, Azure, and Google Cloud — and replaces the on-premise Core Factor Table.
How many Oracle licenses do I need for a 32 vCPU AWS instance?
A 32-vCPU AWS instance running Oracle Database Enterprise Edition with hyper-threading enabled requires 16 Oracle Processor licenses, because Oracle counts two vCPUs as one Processor. If hyper-threading is disabled, the same instance requires 32 Processor licenses. Option packs are licensed separately on the same count.
Does hyper-threading change Oracle vCPU counting?
Yes. Hyper-threading is the single biggest factor in cloud Oracle cost. With it enabled, two vCPUs equal one Processor license (2:1). With it disabled, one vCPU equals one Processor license (1:1) — doubling the license requirement for the same vCPU count. Always confirm the actual thread state, not the assumed one.
Is Oracle vCPU counting the same on AWS, Azure, and GCP?
The Enterprise Edition 2:1 rule is the same across AWS, Azure, and GCP, but Standard Edition 2 differs: SE2 is capped at eight vCPUs on AWS and four vCPUs on Azure and GCP, because AWS counts two vCPUs per core while Azure and GCP count one vCPU per core.
Does the Oracle Core Factor Table apply to cloud vCPUs?
No. Oracle's cloud policy states the Core Factor Table does not apply in Authorized Cloud Environments. The 0.5 multiplier used for on-premise x86 cores is replaced by the vCPU counting rule, so you cannot apply a Core Factor on top of the 2:1 vCPU conversion — doing so under-licenses the workload by half.
Do option packs need separate licensing on cloud vCPUs?
Yes. Oracle Database options such as RAC, Partitioning, Diagnostics Pack, Tuning Pack, and Advanced Security are each licensed on the same Processor count as the base database. A 32-vCPU instance needing 16 EE Processor licenses also needs 16 of each option in use — a frequent and expensive omission in cloud deployments.