Counting vCPUs on AWS and Azure for Oracle Licensing

How does Oracle count vCPUs on AWS and Azure?

Oracle counts vCPUs on AWS and Azure under its cloud computing policy for authorized cloud environments, where 2 vCPUs count as 1 Processor license if hyperthreading is enabled and 1 vCPU counts as 1 Processor license if it is not. This is a different counting method from on premises, where the core factor table converts physical cores into a licensable number. In authorized cloud the table is set aside and a flat vCPU rule applies, which makes cloud sizing simpler to calculate but easy to get wrong if you carry over on premises assumptions.

The full picture of how Oracle treats virtual and cloud environments sits in the Oracle virtualization licensing guide. The cloud rule matters most when you migrate a database that was sized on physical cores and assume the same count holds in the cloud, because it rarely does.

Why does the core factor table not apply on AWS and Azure?

The core factor table does not apply on AWS and Azure because Oracle's authorized cloud policy substitutes a fixed vCPU rule for it, so the 0.5 multiplier that halves x86 core counts on premises gives you no benefit in the cloud. On premises, an Intel server with sixteen cores licenses as eight Processor licenses after the 0.5 factor. In authorized cloud the same workload is counted by vCPUs under the cloud rule, and the familiar halving from the core factor table is not what produces the number.

This catches teams who budget a cloud migration using their on premises license math. The licensable count can move in either direction depending on instance shape and hyperthreading, so the only safe approach is to recalculate from the cloud rule rather than assume parity. A clean count also protects you if Oracle later reviews the deployment, a risk discussed in repatriation and the license position.

How does hyperthreading change the count?

Hyperthreading changes the count because Oracle's cloud policy treats 2 vCPUs as 1 Processor license only when the instance has hyperthreading enabled, and most general purpose AWS and Azure shapes do. When hyperthreading is on, a vCPU is a thread rather than a full core, so two of them collapse to one license. When it is off, each vCPU is treated as a core and counts one for one, which doubles the license requirement for the same vCPU number.

The practical consequence is that instance selection is a licensing decision, not only a performance one. Choosing a shape with or without hyperthreading, and reading the vendor specification correctly, directly changes what you owe. Confirm the hyperthreading state of every instance before you accept any count, your own or Oracle's.

A worked example of cloud vCPU counting

Consider a database running on an AWS instance with 16 vCPUs and hyperthreading enabled. Under the authorized cloud policy, 16 vCPUs divided by 2 gives 8 Processor licenses. Run the same workload on a shape where hyperthreading is disabled and the 16 vCPUs count one for one as 16 Processor licenses, double the requirement for identical vCPU capacity.

Does the cloud policy override your contract?

The cloud policy does not override your contract, because it is a policy document Oracle can revise rather than a negotiated term in your signed agreement, and where the two differ the contract language governs. This is the same principle that defends customers against cluster wide virtualization claims: the policy paper is often weaker than the agreement, and contract language beats policy. Before you accept a cloud finding, read the authorized cloud policy alongside your Oracle Master Agreement and confirm which one actually binds your deployment.

For teams weighing cloud economics more broadly, the offset mechanics are covered in Support Rewards and the OCI offset, which can change the total cost picture even when the license count itself is fixed.

Your next step

Getting the cloud count right before a migration protects your budget and removes an easy audit finding later. An independent buyer side review recalculates your AWS and Azure exposure from the cloud policy, checks it against your agreement, and sizes your estate to the lowest defensible number. Read the pillar guide for the full framework on virtualization and cloud counting.