2 vCPU
equal 1 Oracle Processor licence on AWS, Azure & GCP with hyper-threading on (Oracle cloud licensing policy, 2026)
Oracle licensing in public cloud runs on one rule the on-premises world never taught you: count vCPUs, forget the Core Factor Table. Get the AWS, Azure or Google Cloud count wrong and you either over-buy or hand Oracle's LMS team a back-licence claim worth multiples of your spend. This 2026 buyer-side guide explains the authorized cloud vCPU rule, why the 0.5 core factor dies in cloud, the BYOL economics, and the audit traps Oracle counts on you missing.
Not affiliated with Oracle Corporation.
Home › Oracle Cloud Licensing › White Papers › Oracle Licensing in Public Cloud
Oracle licensing in public cloud is governed by Oracle's Cloud Computing Environment policy, not the on-premises Core Factor Table. On AWS, Azure and Google Cloud — all authorized clouds — two vCPUs require one Oracle Processor licence where hyper-threading is enabled, and one vCPU requires one where it is disabled. The 0.5 x86 core factor does not apply, Standard Edition 2 is capped at eight vCPUs per instance, and mis-counting is the single largest source of cloud audit exposure.
The public-cloud licence position is set the moment you choose an instance shape. Each role owns part of getting the count right before Oracle's LMS team checks it for you.
On AWS, Azure and Google Cloud, Oracle counts vCPUs under its Cloud Computing Environment policy. Two vCPUs require one Oracle Processor licence where hyper-threading is enabled; one vCPU requires one licence where it is disabled. The metric is the same on all three clouds. The on-premises Core Factor Table, including the 0.5 x86 multiplier, plays no part — the vCPU count alone determines the licence requirement.
This is the foundational rule of Oracle licensing in public cloud, and it is deceptively simple to state and easy to get wrong. A 32-vCPU instance with hyper-threading on needs 16 Processor licences; the same workload counted with the on-premises 0.5 factor would appear to need 8, so a buyer applying the wrong rule is short by half. Oracle defines AWS and Azure as Authorized Cloud Environments precisely so the vCPU rule, not the core factor, governs. Our Oracle cloud licensing guide walks each cloud's shapes, and our vCPU counting blog shows the maths per provider.
The Core Factor Table is an on-premises construct that converts physical processor cores to Oracle Processor licences using multipliers such as 0.5 for x86. Authorized Cloud Environments are licensed under a separate Oracle policy that counts virtual CPUs directly, so there are no physical cores for the factor to act on. Oracle's cloud policy replaces the factor with the vCPU rule, and the two methods cannot be combined.
The death of the core factor in cloud is the single biggest mental shift for teams moving Oracle workloads off-premises. On-premises, the factor halved x86 core counts and shaped years of licence planning. In cloud, Oracle simply counts vCPUs, which removes the discount the factor provided and changes the economics of every workload. Buyers who do not internalise this either over-buy by ignoring the rule's simplicity or under-buy by clinging to the old factor. Our Oracle cloud migration guide shows how the count changes at the moment you move.
Oracle Database Standard Edition 2 may only run on authorized-cloud instances of up to eight Amazon vCPUs or eight Azure vCPUs. Above that, the instance is no longer eligible for SE2 licensing, and the workload must move to a compliant shape or to Enterprise Edition. The cap is a hard compliance line, not a guideline, and exceeding it quietly is one of the most common avoidable cloud violations.
SE2's cloud cap exists because Standard Edition is socket-based on-premises and Oracle translates that to a vCPU ceiling in cloud. Scaling an SE2 instance past eight vCPUs — easy to do with a routine resize — puts the workload outside its entitlement entirely, not merely short a licence. The discipline is to pin SE2 instances at the cap and to model Enterprise Edition costs before any growth pushes past it. Our Oracle license optimization team sizes the SE2-versus-EE decision before the resize forces it.
BYOL applies owned, support-active licences to the cloud and suits stable, long-running workloads where you already hold entitlement; License Included rents the licence inside the hourly rate and suits short-lived or bursty workloads. BYOL travels across OCI, AWS, Azure and GCP under one model, but only OCI adds Support Rewards and the 2-OCPU-per-licence ratio, which usually makes OCI the cheapest home for existing licence holders.
The BYOL-versus-License-Included decision is a per-workload economic call, not a default. BYOL reuses sunk licence value but commits you to keeping support active; License Included avoids that but pays a premium baked into the compute rate. For a licence holder, the multicloud picture matters: the same entitlement runs on any authorized cloud, yet OCI's Support Rewards return $0.25–$0.33 per $1 of spend against on-premises support, a lever absent on AWS and Azure. Our Oracle BYOL on AWS & Azure guide models the choice per cloud.
The main cloud audit traps are: applying the on-premises core factor to a cloud count, breaching the SE2 eight-vCPU cap, enabling chargeable options or packs without licences, letting BYOL support lapse, and assuming soft partitioning limits scope. Oracle's LMS scripts detect each. Mis-counted cloud estates routinely produce audit claims of 3–5× what the customer believed it owed, because the under-count compounds across every instance.
Cloud does not reduce Oracle audit exposure; it relocates it. The LMS team reads the same option-usage and deployment data in cloud as on-premises, and the cloud-specific traps — the dead core factor, the SE2 cap, lapsed BYOL support — are ones buyers walk into precisely because the rules differ from the on-premises habits they know. Forensic, evidence-based counting per workload is the only defence. Our Oracle audit defense advisors challenge inflated cloud claims line by line, and our case studies document multi-million-dollar reductions.
The same workload is either compliant or audit-exposed depending on which rule you count it under. The difference is invisible until Oracle runs its scripts.
vCPUs counted, hyper-threading state recorded · no core factor applied · SE2 kept at/under 8 vCPUs · options licensed · BYOL support active · deployment-to-entitlement map maintained.
0.5 core factor carried into cloud · SE2 scaled past 8 vCPUs · options enabled unlicensed · BYOL support lapsed · soft partitioning assumed to cap scope · 3–5× audit claim waiting.
In the cloud Oracle stops counting cores and starts counting vCPUs — the buyers who never make that switch are the ones the audit finds.
| Cloud | Authorized? | Count rule | BYOL / rewards |
|---|---|---|---|
| AWS | Yes | 2 vCPU = 1 licence (HT on) | BYOL; no Support Rewards |
| Microsoft Azure | Yes | 2 vCPU = 1 licence (HT on) | BYOL; no Support Rewards |
| Google Cloud | Yes | 2 vCPU = 1 licence (HT on) | BYOL; no Support Rewards |
| OCI | Oracle's own | 2 OCPU = 1 licence (BYOL) | BYOL + Support Rewards $0.25–$0.33/$1 |
| Feature | Strength | Caution |
|---|---|---|
| vCPU rule | Same simple metric on AWS, Azure, GCP | No core-factor discount — counts rise |
| BYOL portability | One entitlement runs on any authorized cloud | Voids if support lapses |
| Standard Edition 2 | Low-cost option for small workloads | Hard 8-vCPU cap per instance |
| Soft partitioning | Flexible instance sizing | Oracle does not accept it as a licence cap |
| License Included | No support obligation; bursty-friendly | Premium baked into the hourly rate |
Under Oracle's Cloud Computing Environment policy, which counts vCPUs: two vCPUs require one Oracle Processor licence where hyper-threading is enabled, and one vCPU requires one where it is disabled. AWS, Azure and Google Cloud are all Authorized Cloud Environments using this identical metric. The on-premises Core Factor Table does not apply, so the vCPU count alone determines the licence requirement.
No. The Core Factor Table, including the 0.5 multiplier for x86, is an on-premises construct that acts on physical cores. Authorized Cloud Environments are licensed under a separate policy that counts virtual CPUs directly, so there are no physical cores for the factor to discount. The vCPU rule replaces it, and the two methods cannot be combined. Carrying the factor into a cloud count under-licenses you.
Oracle Database Standard Edition 2 may only run on authorized-cloud instances of up to eight Amazon vCPUs or eight Azure vCPUs. Above that ceiling the instance is no longer eligible for SE2 and must move to a compliant shape or to Enterprise Edition. Scaling past eight vCPUs with a routine resize is one of the most common and avoidable cloud compliance violations.
Yes. BYOL applies owned, support-active Oracle licences across OCI, AWS, Azure and Google Cloud under the same model, and the licences are portable between authorized clouds. The differences are economic: only OCI adds Oracle Support Rewards ($0.25–$0.33 per $1 of spend) and uses the 2-OCPU-per-licence ratio, which usually makes OCI the cheapest destination for an existing licence holder.
Because cloud mis-counts compound across every instance. The usual cause is the on-premises core factor carried into AWS or Azure, which halves the apparent licence need; the SE2 cap and unlicensed options follow. Across 600+ engagements, mis-counted cloud estates drew Oracle audit claims of 3–5× the customer's own estimate. Forensic, per-workload counting under the vCPU rule is the only reliable defence.
No. Oracle does not recognise soft partitioning — hypervisor-based core capping such as VMware — as limiting licence scope. In public cloud you license by the vCPU rule on the instance shape, not by a soft cap. Relying on partitioning to limit your count is a trap Oracle's LMS team challenges in audits; choose instance sizes that match your licence position instead.
Benchmarks labelled "Oracle Licensing Experts engagement data, 2026" are drawn from our independent, buyer-side advisory work across 600+ Oracle engagements and $1.8B in Oracle spend advised, including public-cloud licensing and audit-defence reviews. Counting rules, the SE2 cap, BYOL terms and Support Rewards rates are taken from Oracle's published 2026 materials and corroborated against achieved positions. Primary sources:
No NDA-bound client figures are disclosed. Representative ranges are benchmarks, not quotes.
The Oracle Licensing Experts Advisory Team is an independent, buyer-side Oracle licensing practice staffed by former Oracle insiders. We count cloud estates correctly, defend audits, and negotiate cloud contracts — 100% on the buyer's side, never reselling Oracle. Learn about our team → · Not affiliated with Oracle Corporation.
Take the 2026 public-cloud Oracle licensing rules into your next AWS, Azure or GCP deployment review as a PDF.
We count your cloud estate under the vCPU rule, kill the core-factor errors, keep Standard Edition 2 inside its cap, and defend the audit claim when Oracle's LMS team comes looking — so your public-cloud position is compliant by design, not by luck.
Oracle pricing, audit and negotiation intelligence — monthly, independent, no Oracle spin.