Oracle on AWS is licensed under Oracle's authorized cloud environment policy, which counts two vCPUs as one Oracle processor license when hyperthreading is on, so your AWS instance size drives the license count directly.
What policy governs Oracle on AWS?
Oracle on AWS is governed by the authorized cloud environment policy, a policy document that Oracle applies to AWS and Microsoft Azure. The policy is not part of the signed contract, but Oracle uses it to define how processor and Named User Plus licenses map onto cloud instances, and most customers run their AWS estate against it because it is more favourable than counting physical hosts they do not control.
Because it is a policy and not a contract term, the wording can change. The buyer move is to keep the version of the policy that applied when you deployed, so that an audit is measured against the rule that was in force, not a later revision.
How do you count vCPUs for Oracle on AWS?
You count vCPUs by pairing them into Oracle processors. Under the authorized cloud policy, when hyperthreading is enabled you license one Oracle processor for every two vCPUs, and when it is not enabled you license one processor for each vCPU. The core factor table does not apply in authorized cloud, so the vCPU count, not the underlying chip, drives the number.
That makes instance sizing a licensing decision. An instance with 16 vCPUs and hyperthreading on needs eight Oracle Database Enterprise Edition processor licenses. Doubling the instance doubles the licenses, which is why right sizing the instance is the cheapest control you have.
Oracle on AWS processor counts at a glance
| AWS vCPUs | Oracle processors | Note |
|---|---|---|
| 2 | 1 | Two vCPUs to one processor |
| 8 | 4 | Typical small production node |
| 16 | 8 | Mid sized node |
| 64 | 32 | Large node, license cost scales with size |
Does BYOL or License Included apply on AWS?
Both apply, and the choice changes who owns the compliance risk. Bring your own license means you carry your existing Oracle licenses onto AWS and stay responsible for counting them correctly. License Included, through Amazon RDS for Oracle, bundles the license into the hourly rate so Amazon handles the entitlement, though only for Standard Edition Two and a defined feature set.
For Enterprise Edition and for options, bring your own license is the usual route, and that is exactly where audit exposure sits. The license travels with you, so the counting discipline has to travel with it.
How do Standard Edition and Enterprise Edition differ on AWS?
Standard Edition Two and Enterprise Edition count differently on AWS. Standard Edition Two is licensed by counting vCPUs in a defined way and is capped to smaller instances, which makes it cheaper but limited. Enterprise Edition uses the authorized cloud processor count and unlocks options and management packs that each carry their own license.
The trap is enabling an Enterprise Edition option on an instance you sized for a lean deployment. A single option such as Diagnostics or Tuning Pack adds a full set of processor licenses across the instance, so feature control matters as much as instance sizing.
Why is cloud migration an audit trigger?
Cloud migration is an audit trigger because it changes Oracle's visibility and revenue at the same time. Moving to AWS often reduces support spend and signals that an account is shifting away from Oracle infrastructure, and declining support spend together with a cloud migration are two of the classic triggers Oracle watches. The migration itself can also create transient overcounts if instances are left running or sized larger than needed.
The defense is an evidence file built as you migrate. Recording instance types, vCPU counts, hyperthreading state, and the policy version in force gives you a clean answer ready before any audit letter arrives.
What is the buyer move for Oracle on AWS?
The buyer move is to size instances to the license you hold, fix the option footprint, and keep the policy version on file. Counting two vCPUs as one processor is simple arithmetic, but it only protects you if the instance, the features, and the policy are all documented at the moment of deployment rather than reconstructed under pressure.
This is buyer side work. We position as an independent buyer side advisory with deep Oracle licensing expertise, and the AWS rules reward customers who treat instance sizing and feature control as licensing controls from day one.
A worked example
Consider an anonymized retail group that lifted an Oracle Database Enterprise Edition workload onto AWS during a data centre exit. Engineers sized the instances for headroom at 32 vCPUs each with hyperthreading on, and left two non production instances running. Oracle's preliminary finding counted every running vCPU at list price, opening the number in seven figures. No client names, sector level example only.
The buyer side defense right sized the production instances to real demand, shut down and evidenced the idle non production nodes, and confirmed the authorized cloud policy version in force at deployment. Counting two vCPUs as one processor against the corrected footprint brought the settled position to a fraction of the opening number.
Where to go next
This piece links up to the Oracle Virtualization Licensing Guide. Keep reading across the cluster:
Download the Oracle Virtualization Licensing Guide for the full framework, or get a quote.