Oracle Database on Azure. The buyer side way.

Oracle Database on Microsoft Azure is now three decisions, not one: the deployment path, the licensing model, and the counting rule you can defend in an audit. Get the path wrong and you overpay on infrastructure. Get the count wrong and you hand Oracle an audit finding. This guide walks the four paths, the authorized cloud environment rules that Azure actually runs under, the vCPU math with worked numbers, and the buyer side moves that keep the bill honest.

What changed for Oracle on Azure in 2026?

Two years ago, running Oracle Database on Azure meant one thing: your own licenses on an Azure virtual machine, counted under Oracle's cloud policy. That option is still the workhorse, but the landscape around it has widened. The managed service Microsoft and Oracle launched together has moved from limited preview to general availability across many regions, and Oracle now markets it as Oracle AI Database@Azure. It places genuine Oracle Cloud Infrastructure hardware, including Exadata, inside Azure data centers, with low latency links to your Azure application tier. Microsoft describes the offering on its Azure Oracle Database page, and the two companies confirmed general availability in a joint announcement.

What has not changed is the thing that decides your bill. Oracle software on Azure is still licensed under the same authorized cloud environment rules that have governed public cloud deployments for years. The new managed service adds a pricing model to compare against, not a way to escape the counting math. A buyer who understands the vCPU rule can now use it as a benchmark: if the managed service does not beat your own licenses on a virtual machine, you keep the virtual machine.

What are the four deployment paths for Oracle on Azure?

Oracle Database reaches Azure through four routes, and each treats licensing differently. The route decides whether you carry the license or the rate carries it for you, and it sets the counting rule you will defend if Oracle audits. Choosing the route by habit, rather than by a modelled cost, is the single most expensive mistake we see.

Bring your own license on an Azure virtual machine

You run Oracle on an Azure virtual machine using licenses you already own, and Oracle's cloud policy counts the vCPUs of that machine. This path gives the most control and carries the most responsibility: you size the instance, you track the count, and you defend it. It is almost always the cheapest option for an organisation that already holds Enterprise Edition or Standard Edition Two licenses with support current, because the only new spend is Azure compute. The risk is that the same freedom that lets you size tightly also lets you oversize, and every extra pair of vCPUs is another processor license on the books.

Oracle AI Database@Azure, the managed service

Oracle AI Database@Azure runs Oracle hardware inside Azure data centers and presents it as a managed service. It spans three service shapes: Oracle Exadata Database Service on dedicated infrastructure, Oracle Autonomous Database on shared Exadata, and Oracle Base Database Service for lighter workloads that do not need engineered systems. Oracle describes the family on its Oracle Database at Azure page. Pricing matches OCI Exadata Cloud, the spend can draw down a Microsoft Azure commitment, and disaster recovery across the OCI backbone does not add Azure egress charges. The trade is operational simplicity for a metered rate, and the buyer question is always whether that rate beats your own licenses on a virtual machine for the same workload.

License included versus bring your own license

Within the managed service you choose whether to apply owned licenses or take the rate with licenses included. Bring your own license lowers the meter but assumes you hold current, unencumbered licenses to apply. License included is cleaner to run and easier to exit, but you pay for the entitlement inside the service rate whether or not you also own perpetual licenses on the shelf. Organisations mid ULA, or holding licenses they cannot cleanly redeploy, often find license included removes a compliance headache. Organisations with a paid up perpetual estate usually find bring your own license wins on five year cost.

Third party hosting on Azure

A hosting provider can run Oracle on Azure on your behalf, and the licensing terms then follow the hosting arrangement rather than the standard cloud policy. Some hosters hold the licenses; some require you to bring yours; some sit in a grey zone that Oracle's authorized cloud environment definition does not neatly cover. Read the hosting contract before you assume the vCPU rule applies, because a hosting model that is not an authorized cloud environment can revert to on premises counting, which changes the math entirely.

What do the authorized cloud environment rules actually cover?

Azure sits on Oracle's authorized cloud environment list, alongside AWS and Google Cloud. That listing is what makes the vCPU rule apply and the on premises core factor table fall away. The rule lives in Oracle's cloud licensing policy, and the programs eligible to use it are listed in Oracle's authorized cloud environments document. Reading both, and pinning the version in force, is the foundation of a defensible position.

What the policy governs

The policy sets the vCPU conversion for eligible Oracle programs on authorized cloud environments and defines how the count is taken. It is the reason a 16 vCPU Azure virtual machine with hyperthreading on needs eight Enterprise Edition processor licenses rather than sixteen. It governs the base database and, by extension, the counting basis for every option you layer on top.

What the policy does not give you

The policy is not a contract term. It sits in a document Oracle publishes and can revise, and it does not become part of your agreement simply because you relied on it. Three consequences follow, and each is a place we routinely see estates exposed.

• No core factor benefit. The 0.5 multiplier that halves x86 counts on premises does not exist on Azure. You count vCPUs, not factored cores, and stacking the two is a 50 percent under licensing error.
• Policy, not contract. Because Oracle can update the rule, pin the version in force at each deployment and keep it with your records. If the rule changes, your defence is the version you deployed under.
• Edition limits still bite. Standard Edition Two carries a hard vCPU ceiling on Azure, and running past it is a licensing breach, not a performance choice.

How does the vCPU to processor math work?

The rule is short and the money is in applying it precisely. With hyperthreading enabled, which is the Azure default on most database capable sizes, two vCPUs equal one Oracle processor license. With hyperthreading disabled, one vCPU equals one license and your count doubles. Owned licenses move onto the Azure virtual machine through bring your own license, and the count is taken on the virtual machine's provisioned vCPUs, not on how many you happen to be using.

The Standard Edition Two trap on Azure

Standard Edition Two is where the cloud gives Azure a worse deal than AWS, and almost nobody notices until an audit. Oracle caps Standard Edition Two at a set number of vCPUs per database, and the cap depends on how the cloud maps vCPUs to cores. Because Azure counts one vCPU per core, Standard Edition Two on Azure is limited to four vCPUs per database. On AWS, which maps two vCPUs per core, the same edition allows eight. A workload that fit Standard Edition Two comfortably on AWS can breach the edition entirely when lifted to Azure at the same instance size, forcing an unplanned move to Enterprise Edition at several times the cost. Size the Standard Edition Two footprint to the Azure cap, or price the Enterprise Edition move deliberately, never by accident.

Where the count really grows: options and packs

The base database licence is rarely the whole bill. Every priced option and management pack you deploy licenses on the same processor count as the database underneath it. Turn on Real Application Clusters, Partitioning, Advanced Security, the Diagnostics Pack or the Tuning Pack on an eight processor database, and each of those is another eight processor line. The Diagnostics and Tuning packs are the most common surprise, because a monitoring or performance tool can enable them by default and generate usage that Oracle's scripts will find. Before you deploy, inventory which options are switched on, confirm you hold the matching processor count for each, and disable anything you are not licensed to run.