Oracle Policy
Oracle cloud licensing policy, 2026 read.
Oracle counts by vCPU on the named third party clouds and the core factor does not apply. The authorized list, the arithmetic, and the version you should pin into the contract.
Oracle counts by vCPU on the named third party clouds and the core factor does not apply. The authorized list, the arithmetic, and the version you should pin into the contract.
Oracle's cloud licensing policy is a document Oracle writes, revises and publishes on its own. It changes how your licenses are counted on three named third party clouds, it says on its face that it is not part of any contract, and almost every enterprise cloud migration is priced against it anyway.
Every Oracle cloud deployment sits under two documents. Your ordering document and master agreement set the floor, and this policy describes how Oracle intends to apply that floor to somebody else's infrastructure. Read them together or you will misprice the migration.
The primary sources here are Oracle's own: Licensing Oracle Software in the Cloud Computing Environment, the Authorized Cloud Environments document, the Oracle Partitioning Policy, the Processor Core Factor Table, and the Oracle Technology Global Price List.
It is a policy Oracle publishes and revises without your signature, and no, it is not a contract. The document itself says so, in a disclaimer most buyers skim past on the way to the counting table.
Nobody countersigns it. Oracle drafts it, dates it, posts it, and replaces it when commercial priorities change. Your ordering document does not usually incorporate it by reference, which is exactly why the version date matters as much as the rules inside.
Oracle cannot simply hold up the policy and declare your count settled. It has to argue that your agreement's definition of Processor, applied to your deployment, produces the number in the policy. That is an argument, not an automatic outcome.
You do not get to use the same disclaimer as a shield. If the policy is not binding, then the favorable parts are not binding either, and you are back to counting physical hardware you do not own and cannot inspect.
That is the trap in the clever reading. In a multi tenant cloud, the on premises rule is unanswerable, because you cannot count the cores in a host Amazon will never show you. Most buyers who win the argument about the policy lose the argument about the number.
Which document actually decides your cloud count
| Document | Signed by you? | Can Oracle change it alone? | What it decides |
|---|---|---|---|
| Master agreement and ordering document | Yes | No | The metric, the quantity, the territory, the definition of Processor |
| Cloud licensing policy | No | Yes, without notice | How Oracle intends to count vCPUs on three named clouds |
| Partitioning policy | No | Yes, without notice | Which technologies Oracle accepts as a boundary anywhere |
| Cloud service descriptions and price list | Only when referenced in your order | Yes, at any time | The OCPU conversion and rates on Oracle's own cloud |
| An amendment that pins a dated policy version | Yes | No | Everything above, for the term you negotiated |
Three providers and four named services. The policy lists Amazon Elastic Compute Cloud, Amazon Relational Database Service, the Microsoft Azure Platform and Google Cloud Platform, and nothing else.
This is the most common factual error in circulation. Guidance written before Oracle added Google Cloud Platform is still quoted freely, and it leads teams to price Google workloads under the on premises core factor rule when the vCPU rule applies.
Check the version date on whatever you are reading, including this page. A cloud policy summary without a version reference is worth nothing.
Because the policy exists to describe third party clouds. OCI is Oracle's own service, sold under Oracle's cloud service terms, with its own conversion published in the service descriptions and the OCI price list.
By vCPU, and without the core factor. That single sentence accounts for most of the budget surprises in Oracle cloud migrations, because it silently doubles the requirement for the same silicon.
Take 32 physical cores of a standard x86 processor. On your own hardware the core factor is 0.5, so you need 16 Processor licenses, or $760,000 at list.
Move that workload to a hyperthreaded cloud shape and it presents as 64 vCPUs. Two vCPUs per license gives 32 Processor licenses, or $1,520,000 at list and $334,400 of annual support. Same silicon, double the license.
The same database, counted four ways
| Where it runs | Counting unit | Requirement | EE at list | Annual support |
|---|---|---|---|---|
| Own hardware, 32 physical cores, factor 0.5 | Physical core | 16 Processor | $760,000 | $167,200 |
| AWS, Azure or Google Cloud, 64 vCPU shape, hyperthreading on | vCPU | 32 Processor | $1,520,000 | $334,400 |
| Same providers, 32 vCPU shape, hyperthreading not enabled | vCPU | 32 Processor | $1,520,000 | $334,400 |
| Same providers, 32 vCPU shape, hyperthreading on | vCPU | 16 Processor | $760,000 | $167,200 |
Read the last two rows together. At the same advertised instance size, a shape without hyperthreading costs exactly double the one with it, which is the opposite of what most architects assume when they turn threading off for performance reasons.
An instance sized at twelve vCPUs is therefore not a Standard Edition 2 deployment at all. It is an Enterprise Edition deployment, at nearly three times the price per unit, that nobody put in the business case.
Azure publishes constrained vCPU sizes that expose a fraction of a shape's cores while keeping its memory and storage throughput. Oracle counts the vCPUs available to the instance, so the licensable number falls with them.
It is a real lever and it is worth modeling. Get the treatment confirmed in writing before you build a business case on it, because the policy does not name the feature and an auditor may open at the full shape size.
Under Oracle's own service terms, in OCPUs rather than vCPUs. The cloud licensing policy does not reach OCI at all, which is a distinction worth holding onto when someone quotes the policy at you about an Oracle cloud deployment.
An OCPU is one physical core with hyperthreading enabled, which the operating system sees as two vCPUs. On a shape without hyperthreading, an OCPU is one core presenting one vCPU.
For bring your own license, one Enterprise Edition Processor license covers two OCPUs. Because each OCPU is two vCPUs, the same license buys roughly twice the compute on OCI that it buys on an Authorized Cloud Environment.
License included folds the database fee into the hourly rate and you own nothing afterward. BYOL strips that fee out and applies entitlements you already hold, while you continue paying support on them.
The comparison is arithmetic, not preference. Our BYOL guide works through the support cost per consumed hour, which is the number that actually decides it.
These are Oracle operated racks inside a partner region. They are priced under Oracle's cloud terms rather than the vCPU rule, so a workload can move from an Azure virtual machine into Oracle Database@Azure and change counting model without leaving the region.
The cloud policy is not a contract, and that is not good news. The only version of it that protects you is the dated one written into your ordering document.
Your architecture gets re read against wording it was never designed for. The policy has been revised repeatedly, Oracle publishes no change log alongside it, and revisions apply to deployments that were built under earlier text.
No. Only the technologies named in the partitioning policy count as a boundary anywhere, and no public cloud instance shape is one of them. Instance level CPU limits, container quotas and scheduler settings are soft partitioning wherever they run.
The reasoning is the same one that catches on premises estates on Nutanix AHV and Hyper V. Our partitioning policy breakdown lists what actually qualifies.
The clever advice going around is that because the policy says it is not incorporated into any contract, you can ignore it and count under your master agreement instead. We disagree, and it is one of the more expensive pieces of advice in circulation. The agreement defines a Processor by reference to the hardware the program runs on, and in a multi tenant public cloud you can neither see nor evidence that hardware. Win the argument that the policy does not bind you and you inherit a counting rule you cannot satisfy, with the burden of proof sitting on your side of the table. The policy is best understood as the most favorable position Oracle has published, which is why the move is to pin a dated version into the contract rather than to disown it.
In the gap between how the instance was designed and how it looks on the day someone counts. Four traps produce most of the findings we see.
Read this alongside our Oracle Database in the cloud reference for the platform by platform arithmetic, and multicloud licensing if the estate spans more than one provider.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
No. The document states that it is provided for educational purposes, may not be incorporated into any contract, and is subject to change without notice. Your master agreement and ordering documents are the binding paper, and the policy describes how Oracle intends to apply them in three named clouds.
Four services across three providers: Amazon Elastic Compute Cloud, Amazon Relational Database Service, the Microsoft Azure Platform and Google Cloud Platform. Google Cloud is on the list, despite a great deal of older guidance that still says otherwise.
No, and this trips up experienced teams. OCI is Oracle's own cloud and runs under Oracle's cloud service terms, where the unit is the OCPU and one Enterprise Edition Processor license covers two OCPUs.
Two vCPUs count as one Oracle Processor license where hyperthreading is enabled, and one vCPU counts as one Processor license where it is not. The mapping is applied to the vCPUs available to the instance, so a resize changes your requirement immediately.
Not on an Authorized Cloud Environment. Oracle states this explicitly, and it is why a workload that needs 16 Processor licenses on 32 cores of your own hardware needs 32 on a hyperthreaded 64 vCPU cloud shape.
Eight vCPUs maximum on Amazon, Azure and Google Cloud, with four vCPUs counting as one socket, and a Named User Plus floor of 10 licenses per 8 vCPUs. Standard Edition allows up to sixteen vCPUs on the same four vCPU per socket basis.
No. Only the technologies named in the Oracle partitioning policy count as a boundary, and no public cloud instance shape is among them. Instance CPU limits, container quotas and scheduler settings are all soft partitioning.
Yes, and it is the single most valuable thing on this page. Ask for a clause referencing the dated policy version, so a later revision cannot reprice an existing deployment during the term you have paid for.
The on premises rules apply, including the core factor and a count based on the physical hardware. In a multi tenant environment you cannot evidence that hardware, which usually leaves you negotiating from the least defensible position available.
The governance, renewal and negotiation moves that hold Oracle cost across a five year horizon.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The cloud policy is not a contract. The contract paper sets the floor. The policy moves around it.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
Monthly brief on Oracle cloud policy moves, OCI pricing benchmarks and the buyer side moves across cloud migrations. Independent. Buyer side. Never sponsored.
