Oracle on Azure licensing in 2026. The vCPU rule, the four arrangements and what each one costs.

On an Azure VM, Oracle counts two vCPUs as one Processor license with hyperthreading on and one per vCPU without it. The arrangement you are in and the options you run decide the rest of the bill.

How is Oracle licensed on Azure?

Oracle Database on an Azure virtual machine is licensed under Oracle's policy for Authorized Cloud Environments, and Microsoft Azure is one of them. With hyperthreading enabled, two Azure vCPUs count as one Processor license. Without hyperthreading, each vCPU counts as one license.

The processor core factor table does not apply in an authorized cloud. Teams that halve the vCPU count for hyperthreading and then apply the 0.5 Intel and AMD core factor as well end up 50 percent under licensed, and Oracle prices that gap at list when it finds it.

Why can two VMs with the same vCPU count cost twice as much?

Whether an Azure vCPU is a hardware thread or a full core is a property of the VM series, and a DBA cannot change it from inside the database. Many series present two threads per physical core, some present one vCPU per core.

On a series without hyperthreading, the same 16 vCPU VM needs 16 licenses instead of 8. The Azure compute bill looks similar, but the Oracle bill doubles. Confirm the thread count for every Oracle VM before you size it, and again after any resize.

What limits apply to Standard Edition 2 on Azure?

Standard Edition 2 may only run on Azure instances of up to eight vCPUs, the same ceiling Oracle sets for AWS. SE2 is counted by socket: an instance with four or fewer vCPUs counts as one socket, and above that every four vCPUs, rounded up, count as one more.

So an 8 vCPU VM needs 2 SE2 licenses, $35,000 at the $17,500 list price. The ceiling applies to each instance. Resize an SE2 database to the next size up for headroom and it passes eight vCPUs, and from that day it needs Enterprise Edition, as the SE2 licensing guide explains.

Which of the four Oracle on Azure arrangements are you in?

There are four ways to run Oracle Database on Azure, and each one sets its own counting rule. In our reviews, most teams described one arrangement and were contracted for another, so settle this from the paperwork before anyone counts vCPUs.

How do you tell the arrangements apart from the finance record?

Three questions separate them: who invoices the database entitlement, which agreement the order sits under, and who is the customer of record for the infrastructure.

• Oracle invoices support, Microsoft invoices compute. You are on the VM path, and the vCPU rule applies.
• An Azure Marketplace order that references Oracle cloud service descriptions. You are on Database@Azure under Oracle's cloud terms, even though the invoice arrives from Microsoft. The order is either a private offer negotiated with Oracle sales or the public pay as you go offer.
• A partner charges a monthly environment fee. The hosting contract decides whether the vCPU rule applies at all, and who carries the compliance risk.

What is Oracle AI Database@Azure in licensing terms?

It is Oracle's managed database service on real OCI hardware inside Azure data centers, covering Exadata Database Service on Dedicated Infrastructure, Exadata on Exascale Infrastructure, Autonomous Database and Base Database Service. Azure has no license included meter for Oracle Database on a plain VM, so this service is the only way to rent the entitlement.

BYOL on the service does not use the vCPU rule, and Oracle accepts ULA entitlements as well as purchased licenses. The service description sets how your Processor licenses convert into its compute units (ECPUs on Autonomous and Exascale), so get that ratio in writing for each service you plan to use.

What does a 16 vCPU Oracle database on Azure cost at list?

At list, the database alone is $380,000 in license fees, and $572,000 with three common options. Say you run Enterprise Edition on a 16 vCPU memory optimized VM with hyperthreading on, plus Partitioning, the Diagnostics Pack and the Tuning Pack.

Prices are from the Oracle technology price list. Your discount changes the totals, but an audit finding is priced at list.

Why do options add so much?

Every priced option and pack, including RAC, Partitioning, Diagnostics, Tuning and Advanced Security, is licensed on the same processor count as the database underneath. Three options in the example add half as much again to the database fee.

The Diagnostics and Tuning Packs cause most of the surprises. On Enterprise Edition the CONTROL_MANAGEMENT_PACK_ACCESS parameter defaults to DIAGNOSTIC+TUNING, so AWR reports and the tuning advisors work out of the box, and monitoring tools use them without anyone deciding to buy the packs. The Diagnostics and Tuning Pack guide covers what counts as use.

What does sizing up for headroom add?

Say the workload needs 16 vCPUs and the team takes the 20 vCPU size for safety. That is 10 licenses instead of 8, a 25 percent increase. At $71,500 per Processor for the database and the three options, the extra headroom costs $143,000 at list, whether or not the database ever uses it.

Microsoft sells constrained vCPU sizes for this situation. Standard_E32-8s_v5, for example, keeps the memory, storage and I/O of the 32 vCPU size with 8 active vCPUs. Oracle's policy counts vCPUs and says nothing about constrained sizes, so get Oracle's position in writing before you size around them.

When does Oracle Database@Azure beat your own licenses on a VM?

It wins when its hourly rate for a workload is lower than your full cost to run that workload on a VM: Azure compute and storage plus the support on the licenses you bring. In the worked example, support alone is the last line of the table, due for every hour of the year.

Put both paths for each workload on one page, with infrastructure on both sides. If the license included rate wins, convert that workload. If it loses, keep the VM, and you have used Oracle's own price to confirm the choice.

How does part time running change the comparison?

That hourly support figure assumes the database runs around the clock, and support is due every hour whether the VM runs or not. If the same configuration ran as a test system for 50 hours a week, about 2,600 hours a year, the $125,840 of support works out to about $48.40 per running hour.

A metered license included rate has far more room to win on systems shut down at night and at weekends.

What happens to your support bill when a workload switches to license included?

Nothing changes until you terminate the licenses the workload used. Oracle's support policies let it reprice the support on the remaining licenses when you drop part of a license set, so the saving can be smaller than the line item suggests. Ask Oracle for the post termination support quote before you count the saving.

Why we do not treat Database@Azure as the default destination

Oracle account teams and many partners advise moving every Oracle workload to Database@Azure so the licensing question goes away. We disagree for most portfolios. License included only removes the count for the workloads you convert, and BYOL on the service still depends on a conversion ratio you have to check.

In about half the environments we reviewed, the other path would have been cheaper. Price the service workload by workload before anyone signs a private offer sized for the whole portfolio.

How do you check your own Oracle on Azure position?

Build the picture from system data instead of interviews. These sources answer almost every question Oracle will ask about an Azure deployment.

• VM inventory. Export every VM that runs Oracle, with its size and region, from Azure Resource Graph or the az vm list command. The size gives you the vCPU count.
• Threads per core. Run lscpu inside each Linux VM. A "Thread(s) per core" value of 2 means the two for one rule applies, and 1 means every vCPU is a license.
• Feature usage. Query DBA_FEATURE_USAGE_STATISTICS, or run Oracle's options and packs usage script from My Oracle Support, to see which options and packs have been used and when.
• Pack access. Check CONTROL_MANAGEMENT_PACK_ACCESS in every database, and set it to NONE where the packs are not licensed.
• Entitlements. Pull the ordering documents and support contracts, with the Customer Support Identifier for each license set.

The same monitoring default problem appears in Oracle middleware, and the middleware licensing guide works through it.

What goes in a license to instance register?

One row per running Oracle instance, refreshed whenever the environment changes. A spreadsheet updated once and then left behind does not count.

1. VM name, Azure size and region.
2. vCPU count and threads per core, with the date checked.
3. Database edition and version.
4. Options and packs licensed, and options and packs in use, as separate columns. Diagnostics and Tuning deserve their own line.
5. The license set and ordering document each instance draws from.
6. The version of Oracle's cloud policy in force when the instance was deployed.

What evidence protects an Oracle on Azure position in an audit?

Two documents do most of the work: a dated copy of the cloud policy version in force at deployment, and a current license to instance register. The policy explains your arithmetic, and the register proves the inputs.

The vCPU rule lives in a policy document Oracle can revise, and that document is not part of your signed contract. Keep the version you deployed under, and ask for your ordering document to reference it, so a later change does not reopen counts you made in good faith.

Two Azure VMs with the same vCPU count can carry Oracle bills that differ by a factor of two.

What will Oracle's account team say, and how should you answer?

Expect these lines in any Oracle on Azure conversation. Each has a precise reply.

• "Move to Database@Azure and the licensing question goes away." That holds only for workloads on license included. Ask for the hourly rate per workload and the BYOL conversion ratio in writing, then compare each against the VM.
• "Your licenses are fully portable to Azure." They are, under a policy Oracle can change. Ask Oracle to confirm that the policy version in force at deployment governs the instances you deploy under it.
• "Feature usage shows the Diagnostics Pack in use, so it has to be licensed." Ask for the databases and dates behind the claim, check them against your own usage data, and settle any real gap inside a wider commercial discussion rather than at list.
• "Support Rewards make the service cheaper than it looks." Model rewards as a separate line. They offset support invoices, so they only help if you keep paying support on the licenses.

What should you get in writing before you sign?

Most Oracle on Azure disputes come from terms that were assumed and never written down. Ask for these before you sign an order or a private offer.

• A reference to the dated cloud policy. It fixes the counting rule for the instances you deploy under it.
• Written confirmation of the count for your VM series. Include any constrained vCPU sizes you plan to use.
• The BYOL conversion ratio for each Database@Azure service. This sets how many licenses a given ECPU level consumes.
• A price hold on private offer rates for the full term. It keeps your benchmark valid while you move workloads.
• The right to switch workloads between BYOL and license included. The comparison changes as workloads grow or shrink.
• The support treatment for licenses you retire. Without it, the saving from converting workloads can disappear in repricing.

Consumption through Azure Marketplace can count toward your Microsoft Azure Consumption Commitment and can earn Oracle Support Rewards. Confirm both in the order, and see the Support Rewards guide for how the accrual works.

What have we seen in recent Oracle on Azure reviews?

Fredrik Filipsson and the Redress Oracle practice worked through roughly 25 to 35 Oracle on Azure environments in 2024 and 2025. In every one, the deployment path drove the cost gap far more than the Azure compute rate.

• Wrong path. In about half, the other arrangement would have been cheaper, and almost none had put the two side by side.
• Policy treated as contract. Two of three treated the revisable cloud policy as a contractual guarantee, with no fallback if it changed.
• Oversizing. vCPU oversizing added 20 to 30 percent to the processor count, almost always from taking the next instance tier for headroom.
• Unlicensed packs. Priced options ran without matching licenses in most, usually the Diagnostics and Tuning Packs switched on by a monitoring default.
• No register. Not one could produce a current license to instance register in the first week, and every one had a spreadsheet someone had stopped updating.

The 2026 picture adds a choice without changing the arithmetic. The managed service reached broad availability and is sold hard, which makes it a real benchmark to model. The workhorse is still your own licenses on a VM under the vCPU rule.

The cross cloud counting rules and the interconnect economics are in the multicloud licensing guide, and the BYOL against license included decision across clouds is in the cloud licensing analysis.

What to do next

1. Identify the arrangement. Use the finance record to confirm which of the four arrangements each Oracle workload is in.
2. Check threads and sizes. Record threads per core for every Oracle VM, and right size any VM taken a tier up for headroom.
3. Compare packs with licenses. Run the feature usage checks and set CONTROL_MANAGEMENT_PACK_ACCESS to NONE where packs are not licensed.
4. Price both paths. For each workload, compare the license included rate against VM infrastructure plus the hourly cost of support on the licenses you would bring.
5. Pin the policy and build the register. Save the policy version in force at deployment and start the register with the fields above.
6. Get the terms in writing. Put the counting, conversion and support terms into the order before you sign. The Oracle practice runs this review with you.

Frequently asked questions