Oracle / AWS
Oracle licensing on AWS. The 2026 compliance rules.
Oracle Database licensing on AWS turns on the vCPU rule and the gap between Oracle policy and your signed contract. Size to the boundary and document the deployment.
Oracle Database licensing on AWS turns on the vCPU rule and the gap between Oracle policy and your signed contract. Size to the boundary and document the deployment.
Oracle Database licensing on AWS turns on the vCPU rule, the bring your own license terms, and the gap between Oracle policy and your contract. This guide covers the math, the traps, and the moves.
On AWS, Oracle counts vCPUs, not physical cores, and the core factor table does not apply. The mapping is simple but unforgiving. Size the instance to the boundary or pay for the next license tier. Oracle frames the rule in its cloud licensing policy.
With hyperthreading on, two vCPUs equal one processor license. With hyperthreading off, one vCPU equals one processor license. An instance with 8 vCPUs and threading on needs 4 processor licenses.
Standard Edition Two carries a vCPU cap on authorized cloud environments. Above the cap you must move to Enterprise Edition, which changes the cost model entirely.
AWS sits on Oracle's authorized cloud environment list alongside Azure. The vCPU rule applies only to platforms on that list. The core factor table, which helps on premises, is set aside in the core factor table itself.
The vCPU rule lives in a policy document, not in your signed contract. Oracle can update the policy. Your agreement governs what you owe, so the gap between the two is where audit disputes live.
Your order and master agreement define the licensed metric and quantity. They rarely mention the cloud policy by name. That silence is the issue.
The policy sets the vCPU conversion for authorized cloud environments. It is guidance Oracle applies, not a contractual guarantee to you. Pin the policy version in force at deployment.
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
Bring your own license lets you run owned licenses on AWS. The mechanics differ between EC2 and RDS for Oracle, and the count still follows the vCPU rule. AWS documents the options on its RDS for Oracle page.
Bring your own license on AWS
| Deployment | License model | Counting |
|---|---|---|
| EC2 with owned licenses | Bring your own license | vCPU rule, you manage compliance |
| RDS for Oracle, license included | Pay as you go | Included in the hourly rate |
| RDS for Oracle, bring your own | Owned licenses | vCPU rule applies to the instance |
| Dedicated host | Owned licenses | Physical cores under host terms |
RDS for Oracle offers a license included path and a bring your own license path. The license included rate bundles the Oracle license into the hourly price. AWS sets out the choices in its RDS licensing options.
The standard advice is to treat the Oracle cloud policy as a guarantee you can rely on. We disagree. In roughly 2 of 3 estates we reviewed, teams sized AWS deployments against a policy that is not part of their contract and can change. The vCPU rule is how Oracle applies the count today, not a promise in your agreement. The buyer side move is to pin the policy version in force at deployment, document each instance against it, and size to the vCPU boundary. The policy is the practice, but the contract is the law.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
On AWS, Oracle counts vCPUs and the core factor disappears. The instance size is the license decision.
Five moves recur in well managed Oracle on AWS estates.
Oracle counts vCPUs on AWS. With hyperthreading on, two vCPUs equal one processor license. With hyperthreading off, one vCPU equals one license. The core factor table does not apply.
No. The processor core factor table applies on premises but is set aside on authorized cloud environments such as AWS. The vCPU rule governs the count instead.
No. The vCPU rule sits in a policy document, not your signed contract. Oracle can update the policy, so pin the version in force at deployment and document each instance against it.
Standard Edition Two carries a vCPU cap on authorized cloud environments. Above the cap you must move to Enterprise Edition, which changes the license model and the cost.
On EC2 you bring your own license and manage compliance yourself under the vCPU rule. RDS for Oracle adds a license included path that bundles the Oracle license into the hourly rate.
Yes. You can run owned licenses on EC2 and on RDS for Oracle under the bring your own license model. The count still follows the vCPU rule for the instance.
Sizing against the policy as if it were contractual, and running instances one tier larger than the workload needs. Both raise the license count at the vCPU boundary.
Inventory every instance, record vCPUs and threading, pin the policy version you relied on, and document each deployment. A clear record against the rule in force is your strongest position.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
