Cloud and OCI Licensing

The authorized cloud environment policy.

The authorized cloud environment policy is how Oracle counts processor licenses on AWS and Azure, generally treating 2 vCPUs with hyperthreading on as 1 processor license. It is a policy document, not a clause in your agreement, so where the two disagree the signed contract controls.

When an Oracle database moves to AWS or Azure, the first question every asset manager asks is simple. How many licenses do we now need. The answer lives in a document Oracle calls the licensing policy for authorized cloud environments, and that document does a lot of quiet work. It sets a counting rule that is generous in places and expensive in others, and because it is published rather than signed, many buyers treat it as gospel when it is closer to an opening position. Knowing what the policy says, and knowing where your contract says something different, is the whole game when your Oracle estate sits in someone else's data centre.

What is the Oracle authorized cloud environment policy?

The authorized cloud environment policy is the Oracle document that defines how processor licenses are counted on a short list of approved public clouds, primarily Amazon Web Services and Microsoft Azure. Under the rule as Oracle publishes it, you count the virtual CPUs assigned to the instance, and where hyperthreading is enabled, 2 vCPUs are treated as 1 Oracle processor license. Where hyperthreading is off, 1 vCPU counts as 1 license. The familiar core factor table that governs on premises processors does not apply in the same way, so a buyer used to multiplying cores by a factor has to switch to a vCPU count instead. The policy also names which clouds qualify, and an instance on a cloud that is not on the list does not get the benefit of the rule at all.

Is the authorized cloud environment policy part of the contract?

No, and this is the point that changes the size of a finding. The policy is a document Oracle maintains and updates on its own, not a clause inside the Oracle Master Agreement you signed. The contract language beats policy whenever the two conflict, because the agreement is the instrument both parties actually executed and the policy is a statement of Oracle's current position. This matters because Oracle can revise a policy at any time, and a cloud counting rule that looked settled when you migrated may read differently a year later. Your signed metric definitions, your processor definition, and any cloud language already in your ordering documents are the things that bind. When a preliminary cloud finding rests on the policy, the first buyer question is always whether the contract says the same thing.

How do you count licenses on AWS and Azure?

You count the vCPUs allocated to each instance running an Oracle program, then apply the policy rule to convert vCPUs into processor licenses. The arithmetic is straightforward once the instance shapes are fixed, but the exposure is created by which instances are in scope, not by the multiplication itself. An autoscaling group that briefly spun up extra instances, a non production environment that was never meant to carry full licenses, or a snapshot that kept a database alive longer than anyone realised can all enlarge the count. The defensible number comes from an accurate inventory of what actually ran, for how long, on which shapes, evidenced from the cloud provider's own console, not from Oracle's assumption about your maximum footprint.

Counting under the authorized cloud environment policy
ConfigurationPolicy ruleLicenses for an 8 vCPU instance
Hyperthreading on2 vCPUs per license4 processor licenses
Hyperthreading off1 vCPU per license8 processor licenses
Cloud not on the approved listPolicy benefit does not applyTreated on other terms

What triggers a cloud licensing audit?

A cloud migration is itself one of the recognised audit triggers, alongside virtualization, Java downloads without a subscription, mergers and acquisitions, declining support spend, and rejected sales proposals. The reason is commercial. When Oracle sees a workload leave its own infrastructure for a competitor's cloud, the account team has both a revenue gap to close and a fresh, complex estate to examine. Audits are also a sales channel, and a cloud finding can be steered toward an OCI commitment or a universal credits deal rather than a straight back license purchase. Recognising that the audit and the sales motion are connected lets you treat the finding as the opening of a negotiation rather than a settled bill.

Worked example

A mid sized enterprise lifted a cluster of Oracle databases to Azure and received a preliminary finding built on the instance shapes at their peak autoscaling moment, counted as if hyperthreading were off. The buyer side review pulled the Azure activity logs, established the actual running hours and shapes, confirmed hyperthreading was enabled on the relevant instances, and applied the 2 vCPUs per license rule the policy itself states. The defensible count came in well below the preliminary number, and the remaining gap was resolved through the commercial conversation rather than a list price purchase. Independent line by line review of findings of this kind typically cuts the claim 60 to 80 percent.

Does the policy apply to OCI?

Oracle Cloud Infrastructure runs on its own licensing terms rather than the authorized cloud environment vCPU rule, so the policy mainly governs the AWS and Azure question. On OCI the unit is the OCPU, the bring your own license and license included models change the maths, and universal credits sit underneath the commercial arrangement. That difference is part of why a cloud finding so often turns into an OCI conversation: moving the workload onto Oracle's own cloud changes both the counting rule and the commercial relationship at once. Whether that is a good deal for you is a contract and economics question, not a compliance one, and it should be modelled rather than accepted as the path of least resistance.

What is the buyer move?

The buyer move is to separate what the policy says from what your contract says, then build the count from real cloud evidence. Read your ordering documents and master agreement for any cloud or processor language that already binds, pull the provider console data that proves what actually ran, and apply the policy rule precisely where it genuinely applies. Where a finding leans on the policy alone, test it against the contract, because the agreement controls when the two disagree. The goal is a number you can defend line by line, not a number assembled from your theoretical maximum footprint.

For how universal credits and OCI commitments are structured, see OCI licensing and universal credits. For the evidence that proves what ran, see the cloud evidence file for audits. The full method sits in the Oracle virtualization licensing guide.

Free resource

Get the VMware Licensing Survival Guide.

The buyer side guide to Oracle on virtualization and cloud: what the partitioning and cloud policies say, why the contract beats them, and the line by line defense that takes an inflated finding apart.

Download the guide
The License Position

Read Oracle's next move before they make it.

A short weekly note on Oracle audits, Java, ULAs and negotiation. One development, why it matters, and one move you can make this week.

Read across enterprises in New York, London and beyond.