Contents
Key takeawaysHow a ULA treats AWSThe cloud clauseCounting vCPUs on AWSThe 365 day averageEvidence Oracle expectsWhat we have seenTerms to negotiateWhat to do nextFAQYou can run as much Oracle on AWS as you like while a ULA runs. At certification, only the capacity your clause admits, the averaging rule credits and your records prove becomes licenses you own.
- The clause decides. Your ULA's certification wording, which is silent, excludes cloud or admits it through a 365 day average, settles whether AWS counts at all.
- Late scaling barely counts. Under averaging, capacity added in the final quarter certifies at roughly a quarter of its size, so build early in the term.
- Records must cover a year. Oracle expects instance level evidence across the final year, and an end date export cannot support a year long average.
- Cloud uses the vCPU ratio. Two vCPUs equal one processor license with hyperthreading on, and the core factor table does not apply on AWS.
- License included RDS is Amazon's. It never enters your certified count, so move anything you want to own onto bring your own license.
- The exposure is large. Cloud reached 20 to 60 percent of the Oracle footprint by the final ULA year for the customers we reviewed.
How does an Oracle ULA treat Oracle running on AWS?
During the term, an Oracle ULA covers AWS like any other location. The agreement grants unlimited deployment of the named products, so you can run as much Oracle on EC2 or on Amazon RDS as you like without a count, a true up or a purchase order.
The exit is different. Certification turns what you deployed into a fixed number of perpetual licenses, and AWS capacity only makes that journey if your contract admits it, the counting rule credits it and your records prove it. Capacity that fails any of those tests keeps running after the term but has no license behind it.
| Mechanism | What it controls | What to do about it |
|---|---|---|
| The clause generation | Whether cloud is admitted at all | Read your certification language now, years before exit |
| The 365 day average | How much of the cloud footprint converts | Build AWS capacity early in the term, never in the final quarter |
| The evidence file | Whether the count can be proven | Keep instance level records across the whole final year |
| The vCPU ratio | How cores translate into licenses | Model at two vCPUs per processor license with hyperthreading on |
| RDS license included | Capacity that never becomes yours | Use bring your own license for anything that must certify |
Why does AWS capacity feel free during a ULA?
It is free while the term runs. An architecture team moving Oracle workloads to AWS in the middle of a ULA meets no licensing friction at all, and every signal the business receives says the migration costs nothing in Oracle terms.
That is how cloud grows into a large share of the Oracle footprint without anyone treating it as a licensing decision. The cost only appears at certification, when the unlimited right ends and the count becomes permanent.
What happens to AWS capacity that does not certify?
It has to be licensed again after the exit, at full price. The instances do not switch off when the term ends. They keep running, and from that date every processor above your certified quantity is a new purchase made with no unlimited right to trade and very little negotiating room.
The exit mechanics are covered in our exit strategy guide, and the count itself in the certification guide.
How to Negotiate Your Oracle SaaS Renewal: The Five Moves at the Table
Which cloud clause does your ULA certification contain?
Your ULA's own certification language decides whether AWS counts, and Oracle's general cloud policy does not override it. We see three generations of wording in ordering documents, and you should classify yours before any cloud architect plans another migration.
- Silent. Older agreements say nothing about cloud. Silence does not mean AWS will count. It leaves the treatment of AWS capacity open until certification, when you have the least time to argue it.
- Excluding. The clause removes third party cloud deployments from the certification. Under this wording your entire AWS footprint converts to nothing, however long it ran.
- Averaging. Many later agreements admit cloud, but only as an average of deployment across the final 365 days of the term.
Read the paragraph with your contracts team and write the answer down in one line that architects can understand, for example "AWS counts at the 12 month average". That line should sit next to every cloud migration business case for the rest of the term.
Why the end of term deployment push backfires on AWS
The standard advice before a ULA certification is to deploy as much as you can in the final months, because capacity added inside the term is free and becomes permanent. For on premises servers that advice holds. For AWS under an averaging clause we advise against it.
A 365 day average credits a final quarter push at roughly a quarter of its size, so the classic end of term scramble buys little entitlement. The better course is to bring AWS capacity online early in the term, ideally before the final year starts, and to read the deployment plan and the certification clause together at signature.
Oracle multicloud and universal credits
How bring your own license and universal credits price out across AWS, Azure and OCI.
Get the white paper →How does Oracle count Oracle Database licenses on AWS?
Oracle counts AWS by vCPU under its published policy for Authorized Cloud Environments. Two vCPUs equal one processor license when hyperthreading is enabled, and one vCPU equals one processor license when it is not. The Oracle Processor Core Factor Table does not apply to AWS instances.
That last rule surprises buyers who model cloud on server assumptions. On premises, a current Intel or AMD core carries a core factor of 0.5 and needs half a license. On AWS, the same core with hyperthreading presents two vCPUs and needs a full license, twice as much.
- Cloud rules. Our note on the Authorized Cloud Environment policy covers AWS, Azure and Google Cloud counting.
- On premises rules. The core factor guide explains the table that applies to your own servers.
What changes for Standard Edition 2 on AWS?
Standard Edition 2 can only be licensed on AWS instances of up to 8 vCPUs. An instance of 4 vCPUs or fewer counts as one socket, and every further 4 vCPUs, rounded up, adds another.
Named User Plus licensing for Standard Edition 2 carries a minimum of 10 users per 8 vCPUs. Our page on SE2 vCPU limits covers the edge cases.
Do RDS license included instances count toward certification?
No. A license included RDS instance runs on Amazon's Oracle license, which you rent by the hour and never own, so it can never enter your certified count. Amazon offers license included only for Standard Edition 2. Enterprise Edition on RDS is always bring your own license, so it draws on your ULA and counts like EC2.
- Check the license model per instance. Each RDS instance records its license model, and you can change it by modifying the instance.
- License the standby. Under bring your own license, a Multi-AZ deployment needs licenses for the primary and the standby instance.
- Switch before the window opens. If Standard Edition 2 is one of your ULA products, any SE2 database you want to own after the term should move to bring your own license well before the final year, so it runs on your license for the whole averaging period.
Does the hyperthreading setting matter?
Yes. It decides whether two vCPUs or one make up a processor license. AWS allows you to set active cores and threads per core at launch through Optimize CPUs, on EC2 and on RDS for Oracle. Whatever configuration you choose, keep the instance level record of cores and threads, because that is the figure you will be asked to support.
How does the 365 day averaging rule change the certified count?
Where your clause uses it, the certified cloud quantity is the average deployment across the final year of the term. Capacity that ran all year counts in full. Capacity that arrived late counts in proportion to the days it ran.
Say your ULA covers Database Enterprise Edition and you run 240 vCPUs of it on EC2 with hyperthreading on. At two vCPUs per license that is 120 processor licenses. The table shows what the same 120 certifies to, depending on when it went live. Prices are Oracle's list: $47,500 per processor license and $10,450 a year per processor for support.
| When the capacity went live | Days running in the final year | Certified processors | Shortfall to relicense | List cost of the shortfall |
|---|---|---|---|---|
| Before the final year | 365 | 120 | 0 | $0 |
| Start of the final 6 months | About 183 | About 60 | 60 | $2,850,000 plus $627,000 a year support |
| Start of the final quarter | About 91 | About 30 | 90 | $4,275,000 plus $940,500 a year support |
The last row is the end of term scramble. You pay nothing for those 90 processors while the ULA runs, then face a list price of more than $4 million to keep running them afterward. Discounts will reduce that figure, but you negotiate it after the unlimited right has gone.
How should you schedule AWS migrations inside a ULA term?
Work backward from the date the averaging window opens, which is 12 months before the end date. Anything that must be owned after the ULA should be live and stable before then. Workloads that will be retired, or moved to license included services, can land later because they were never going to certify.
What evidence does Oracle expect for AWS deployments?
Oracle expects instance level records that span the whole final year of the term. A year long average can only be supported by a continuous record, and a screenshot of the console on the last day proves nothing about the 364 days before it.
Which AWS records prove a year long average?
- AWS Config history. Configuration items for each EC2 and RDS instance show the instance type, CPU options and the dates each configuration applied.
- Cost and Usage Report. Hourly line items with resource IDs show when each instance ran and on which instance type.
- RDS instance details. The DescribeDBInstances API returns the instance class, engine edition, license model and Multi-AZ setting for each database.
- EC2 CPU options. The DescribeInstances API returns the core count and threads per core, which settle the hyperthreading question for each instance.
- Oracle side records. Instance names, versions and the DBA_FEATURE_USAGE_STATISTICS view tie each AWS host to the Oracle products and options actually used.
- AWS License Manager. If you set license rules there, it tracks vCPU consumption against them across accounts.
Keep the extracts monthly in one place, owned by the licensing team rather than the cloud team. Accounts get closed and retention settings get changed during migrations, and a gap of a few months breaks the average you are trying to prove.
What mistakes cost buyers most at certification?
- Counting license included RDS. It inflates the draft count, and when Oracle strips it out the certified number falls below the figure your team planned around.
- Using core factors for cloud. Modeling AWS at 0.5 per core understates the license need by half.
- Assuming a point in time count. Buyers who planned for an end date figure found the averaging rule in the final quarter, after their scaling decisions were made.
- Missing accounts. Oracle workloads in AWS accounts run by a subsidiary or a project team are easy to leave out of both the count and the evidence.
What have we seen in AWS ULA certifications from 2024 to 2026?
Across 20 to 30 Oracle customers running on AWS that we advised in 2024 to 2026, the cloud counting clause was the most expensive line in the agreement. By the final ULA year, cloud held 20 to 60 percent of the Oracle footprint, often under contracts that excluded it at certification.
Everything the clause leaves out was free to run during the term and costs full price to keep after it.
In nearly half of those customers, teams had scaled Oracle on AWS without checking whether those cores could certify, because the question never came up while deployment was free. In the largest case, relicensing excluded AWS capacity after exit ran into seven figures, for cores that had run for three years without a licensing question.
What cloud terms should you negotiate into a ULA renewal?
Put cloud counting on the renewal agenda from the first draft, because it is one of the five clauses usually missing when Oracle sends the paper. The terms below close the gaps this page describes.
- Explicit inclusion of AWS. Name Authorized Cloud Environments in the certification clause, so silence cannot be read against you.
- The counting ratio in the contract. Write the two vCPU per license rule into the ordering document, so a later revision of Oracle's cloud policy cannot change your certified number.
- The measurement point. Ask for the end date count to apply to cloud as it does on premises, or at least an averaging window that starts when each workload goes live.
- Agreed evidence. List AWS Config history and billing records as acceptable proof, so the evidence debate is settled before it starts.
- Entity and account coverage. Confirm that AWS accounts owned by any entity covered by the agreement fall inside the certification.
What will the Oracle account team say, and how should you reply?
- "Cloud is covered under your ULA." Reply that deployment is covered during the term, and ask Oracle to confirm in writing how AWS processors will be counted at certification.
- "Counting follows our standard cloud policy." Reply that the policy is a document Oracle can revise at any time, and ask for the ratio to be written into the ordering document.
- "The averaging language is standard." Reply that standard wording is a starting point, and show the migration plan that the average would penalize.
- "Certification is a formality." Reply that your officer signs the number, and that you will certify only what your evidence file supports.
- At signature or renewal. Classify the clause and negotiate cloud wording.
- Before the final year. Land every AWS workload you want to own and, if SE2 is a ULA product, move the SE2 databases you want to keep off license included RDS.
- 12 months out. Start monthly evidence extracts for every Oracle instance on AWS.
- 3 months out. Reconcile the running average against your target count and fix gaps in the record.
- End date. Calculate the certified average from the full year of records.
The rest of our ULA material, from entry to exit, is in the Oracle knowledge hub.
What to do next
- This week. Pull the certification clause, classify it as silent, excluding or averaging, and tell the cloud architects what it means for their plans.
- This month. Map current Oracle capacity on AWS at the cloud ratio, separating bring your own license from license included RDS.
- This quarter. Set up monthly instance level evidence extracts, so the file covers the whole final year once the window opens.
- Before the final year opens. Resequence planned cloud scaling so it lands early in the term wherever averaging applies.
- Before renewal talks. Put cloud counting language on the agenda. Our Oracle advisory team reviews the clause with you and models what your AWS footprint will certify.
Frequently asked questions
Does Oracle allow ULA deployment on AWS?
Yes, for as long as the agreement is live. AWS falls within the unlimited deployment right for the products your ULA names, on EC2 and on RDS with your own license. The restriction arrives at certification, when deployed usage becomes a fixed perpetual count and only admitted capacity converts.
How does Oracle count Oracle on AWS?
By allocated vCPU under Oracle's cloud licensing policy. Each processor license covers two vCPUs if hyperthreading is on, or one vCPU if it is off. Server core factors play no part, which is why buyers who carry their on premises models into the cloud usually underestimate the count.
What decides whether AWS cores certify?
The certification language in your own ULA ordering document. Some older contracts say nothing about cloud, some exclude it, and many later ones admit it through a 365 day average. Oracle's general policy does not settle the question, so get a written reading of your clause before planning any migration.
What is the 365 day averaging rule?
It is contract wording that certifies cloud deployment at its average over the last year of the term. Each instance contributes in proportion to the days it ran in that year, so capacity added a few months before the end date adds only a small fraction of its size to your perpetual count.
What evidence does Oracle expect for AWS?
A continuous, instance level record covering the final year of the term. In practice that means configuration history, billing line items and database details for every Oracle instance, collected at regular intervals. A single end date console export or screenshot cannot support an averaged figure.
Do RDS license included instances count?
No. Amazon supplies the Oracle license on those instances and charges for it by the hour, so none of that capacity becomes your entitlement. Customers that grew on license included RDS during a ULA found at certification that it added nothing to their count.
Can you switch an RDS for Oracle instance from license included to bring your own license?
Yes. AWS supports changing the license model by modifying the DB instance. License included is offered only for Standard Edition 2, so this matters when SE2 is one of your ULA products. Make the switch before the averaging window opens so the instance runs on your license for the full year.
What happens if AWS capacity is excluded?
You buy licenses for it after the exit, at full price, or shut it down. The instances keep running once the term ends, so the gap is immediate. For the largest customer we reviewed that recovery cost seven figures, which is why the clause and the records need attention years before the end date.