Oracle / ULA Guide
Oracle ULA on AWS. Licensing and counting.
Running Oracle on AWS under a ULA is free during the term and risky at the exit. This guide covers how Oracle counts on AWS and why cloud cores may not survive certification.
Running Oracle on AWS under a ULA is free during the term and risky at the exit. This guide covers how Oracle counts on AWS and why cloud cores may not survive certification.
Running Oracle on AWS under a ULA looks simple while the term is active, because deployment is unlimited. The risk sits at the exit. This guide covers how Oracle counts on AWS and why cloud cores may not survive certification.
An Oracle ULA lets you deploy named products without counting during the term. AWS deployment falls inside that right, so nothing blocks you from running Oracle on EC2 or RDS while the agreement is live.
The exit is where AWS changes the math. Certification turns deployed usage into a fixed count, and the contract decides whether cloud cores are part of that number.
Oracle licenses on AWS under its cloud computing policy, not the standard on premises core factor rules. The ratio is set by vCPU.
Under the Oracle cloud licensing policy, two vCPUs count as one processor license when hyperthreading is on, and one vCPU counts as one license when it is off.
The cloud policy is a public document, not a clause in your contract. Oracle can change it. The safe position is to license to it while keeping your own independent count of what you deploy.
The Oracle partitioning policy and the core factor table govern on premises hardware. On authorized cloud, Oracle uses the flat vCPU ratio instead, so per chip core factors do not reduce your AWS count.
During the term, AWS deployments are not counted at all, because the ULA grants unlimited deployment of the named products.
You can scale Oracle on EC2 and RDS freely while the agreement is active. There is no per instance charge and no running tally during the term.
Unlimited during the term lulls teams into heavy AWS growth. That growth only has value at exit if the contract lets you certify it. Track it from day one.
Sometimes. The answer lives in the certification clause, and it is the most important sentence in the whole agreement for an AWS heavy estate.
Some ULAs allow certification of deployments in authorized cloud. Many older agreements restrict the certified count to on premises installations. Read your exact wording before you plan AWS scale.
If the contract excludes cloud, every Oracle core you ran on AWS drops out of the certified count. After exit you must license that capacity again at the Oracle technology price list rate, or move it back on premises.
The common advice is that a ULA makes cloud licensing a non issue because deployment is unlimited, so teams scale Oracle on AWS freely and plan to certify the lot at exit. We disagree, and the gap is expensive. In nearly half of the AWS heavy estates we reviewed, the certification clause excluded public cloud, so those cores carried no perpetual value and had to be relicensed after exit. The buyer side move is to read the clause first, count on premises and cloud separately, and keep the workloads you intend to certify on infrastructure the contract actually recognizes. Unlimited deployment is not the same as a countable entitlement.
How Oracle on AWS is counted, during the term and at exit
| Scenario | During the ULA term | At certification |
|---|---|---|
| EC2 bring your own license | Unlimited, not counted | Counted only if the clause allows cloud |
| RDS bring your own license | Unlimited, not counted | Counted only if the clause allows cloud |
| On premises deployment | Unlimited, not counted | Always countable |
| Counting metric | None during term | Allocated vCPU under the cloud policy |
| Core factor table | Not applicable on cloud | Not applicable on cloud |
Source: Redress Compliance advisory engagement file, 2024 to 2025.
On AWS the ULA gives you freedom during the term and a bill at the exit. The cores you cannot certify are not an asset. They are a future list price purchase.
Three failures recur, and all of them are avoidable with an early read of the contract.
White Paper ยท Oracle
How to Exit an Oracle ULA Without Overpaying
The certification trap, the support reset, and the timing that protects your leverage. Read it free.
Teams apply the core factor table to AWS out of habit. On authorized cloud the flat vCPU ratio applies, so the core factor neither helps nor hurts. Count it correctly.
Heavy AWS growth in the final year feels free because deployment is unlimited. If the clause excludes cloud, that capacity evaporates at exit.
Relying on Oracle to tell you what you deployed is a weak position. Keep your own monthly count of Oracle cores on AWS across EC2 and RDS.
Align the deployment plan with what the contract will let you certify.
Confirm whether authorized cloud is certifiable before you scale Oracle on AWS. The clause sets the entire strategy.
Maintain two running counts so you always know what is certifiable and what is at risk at exit.
If cloud is excluded, keep the Oracle you intend to certify on infrastructure the contract recognizes. Do not strand value on AWS.
Oracle licenses its software on AWS under a policy that counts two vCPUs as one processor license when hyperthreading is on, and one vCPU as one license when it is off. The policy is not contractual, so the safe position is to license to it while keeping your own count.
Yes, you can deploy Oracle on AWS during the ULA term because deployment is unlimited while the agreement is active. The risk is not the term. It is whether those AWS deployments can be counted when you certify and exit.
Whether AWS deployments count at certification depends entirely on your contract language. Many older ULAs only allow certification of on premises deployments, so cloud cores are excluded and lost at exit. Read the clause before you scale Oracle on AWS.
Oracle cores on AWS EC2 are counted from the allocated vCPUs using Oracle's cloud policy ratio. The Oracle Processor Core Factor table does not apply to authorized cloud, so a two vCPU instance with hyperthreading on equals one processor license.
Oracle on AWS RDS can be run under a license included model or bring your own license, while EC2 is bring your own license only. Under a ULA you use bring your own license, so the counting question follows you onto RDS as well.
The biggest Oracle ULA mistake on AWS is scaling cloud deployments late in the term and assuming they will inflate the certified count. If the contract excludes cloud at certification, that capacity vanishes at exit and you pay to relicense it.
No, the Oracle Processor Core Factor table does not apply to authorized public cloud such as AWS. Oracle uses its cloud computing policy instead, which sets a flat vCPU to license ratio rather than the per chip core factors.
Protect an AWS exit by confirming the certification clause early, counting on premises and cloud separately, and keeping Oracle workloads that you intend to certify on countable infrastructure. Align the deployment plan with what the contract will actually let you certify.
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.
