Deployment on AWS is unlimited while an Oracle ULA runs. What survives certification is decided by the clause generation, the 365 day averaging rule, and the evidence file you kept through the term.
An Oracle ULA on AWS is generous in the term and unforgiving at the exit. Deployment is unlimited while the agreement runs, but whether those AWS cores survive certification is decided by one clause, one averaging rule, and the evidence you kept. This guide covers exactly that intersection.
A ULA grants unlimited deployment of the named products during the term, and AWS sits inside that right. Nothing blocks you from scaling Oracle on EC2 or RDS while the agreement is live.
The exit is where AWS changes the math. Certification converts deployed usage into a fixed perpetual count, and three separate mechanisms decide what AWS contributes to that number: the clause, the averaging rule, and the evidence.
Under its cloud policy, by allocated vCPU, and the counting basics take one paragraph. The Oracle cloud licensing policy counts two vCPUs as one processor license where hyperthreading is enabled, and one vCPU as one license where it is not.
The general mechanics, instance families, RDS models, and the full vCPU conversion, live in the Oracle Database on AWS licensing guide. This page stays on the ULA intersection: what those vCPUs are worth when you certify.
The cloud policy is a public document Oracle can change, not a negotiated term. License to it, but keep your own independent count of every deployment, because at certification the contract language outranks the policy.
The processor core factor table governs on premises hardware only. On authorized cloud the flat vCPU ratio replaces it, so per chip core factors neither reduce nor inflate an AWS count.
The certified quantity becomes your perpetual entitlement and sets your post ULA support base. Counting AWS at the wrong ratio does not just misprice the term. It hard codes the error into everything that follows the exit.
Nothing is counted and nothing is billed, because the ULA makes deployment unlimited. That freedom is real, and it is also the trap, because teams scale AWS heavily on the assumption that the growth converts into entitlement later.
Record AWS Oracle deployments monthly from day one: instance identifiers, regions, instance types, vCPU allocations, hyperthreading state, and the Oracle products on each. The certification argument is won or lost on whether this record exists.
A tagging standard applied at launch makes the certification inventory a query instead of a project. Three tags carry most of the weight.
It depends on which of three clause generations your agreement carries, and reading that clause is the first task of any AWS heavy ULA. The generations behave completely differently at the exit.
Clause generation versus certification outcome on AWS
| Clause generation | AWS during the term | AWS at certification | The move that protects you |
|---|---|---|---|
| Silent | Unlimited | Contested; Oracle reads silence as on premises only | Legal read early, negotiate clarity, plan repatriation |
| Express exclusion | Unlimited | Zero; AWS cores drop out entirely | Keep certifiable workloads on countable infrastructure |
| Inclusion with averaging | Unlimited | Counted at the final year average | Scale early in the final year, evidence monthly |
Whatever generation you hold, the final year decisions reduce to three rules, applied in order.
Certification fights over cloud counting became publicized around 2022 and 2023, and Oracle's practice hardened afterward in three visible ways. We now treat all three as standard behavior in every AWS heavy certification.
Take an estate holding a steady 400 Oracle vCPUs on AWS for the first nine months of the final year, then scaling to 800 vCPUs for the last three months hoping to inflate the count.
Point in time count versus the 365 day average
| Measure | vCPUs | Processor licenses at 2:1 | Comment |
|---|---|---|---|
| End date snapshot | 800 | 400 | What the team expected to certify |
| Final year average | 500 | 250 | Nine months at 400 plus three months at 800 |
| The gap | 300 | 150 | Capacity that must be relicensed or removed after exit |
The spike bought 150 fewer processor licenses than the team assumed, and the shortfall surfaces after the term ends, when there is no ULA left to cover it. Sustained deployment early in the final year is worth far more than a late surge.
If your generation of clause excludes cloud, every Oracle core on AWS drops out of the certified count at exit. Recovering that capacity afterward means buying licenses at the Oracle technology price list, or repatriating workloads to countable infrastructure before the term ends.
Instance level records covering the period the clause measures, which under averaging language means the entire final year. A screenshot of the console on the last day convinces nobody, least of all the reviewer whose counter proposal depends on doubting it.
The cloud platform team exports, the license owner reconciles, and the file builds monthly through the term, not retrospectively at certification time. Rebuilding a year of AWS history after the fact is possible but weak, and reviewers know the difference.
Store the exports outside AWS as well, in the same contract file that holds the ULA itself. Evidence that lives only in the account it describes has a way of losing its history at exactly the wrong moment.
Source: Redress Compliance advisory engagement file, AWS estate reviews 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.
Seven traps account for nearly every AWS certification loss we have reviewed, and all seven are avoidable with an early read of the contract and a running evidence file. None of them requires Oracle to do anything clever. They are self inflicted, which is the good news, because self inflicted losses respond to process.
White Paper · Oracle
Oracle Multicloud & Universal Credits
BYOL and universal credits across clouds. Read it free.
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 or averaged it down, so those cores carried far less perpetual value than the teams believed, and some had to be relicensed after exit at full price. The buyer side move is to read the clause first, count on premises and cloud separately, and place the workloads you intend to certify on infrastructure the contract actually recognizes. Unlimited deployment is not the same as a countable entitlement.
Four moves, sequenced early, keep the AWS estate certifiable. Everything else is commentary on these.
Identify which clause generation you hold and get a legal read on any ambiguity. The clause sets the entire AWS strategy, including whether AWS growth has any exit value at all.
Two running tallies, updated monthly, so you always know the certifiable number and the at risk number. Mixed counts hide the exposure until it is too late to fix.
If the clause excludes cloud, keep the deployments you intend to certify on infrastructure the contract recognizes, and treat AWS as term convenience rather than exit value. Do not strand entitlement where the contract cannot see it.
Renewals and extensions are the moment to negotiate cloud inclusive certification language, or at least to bound the averaging mechanics. The ULA renewal negotiation tactics page covers how to trade for it.
Only if your certification clause allows it. Older agreements are silent or exclude cloud, in which case AWS cores drop out at exit, while many later agreements admit authorized cloud measured as the average deployment across the final 365 days of the term.
It is the mechanism in cloud inclusive ULAs that counts authorized cloud deployments as the average across the final year rather than the end date quantity. A late spike therefore contributes only its time weighted share, which makes final quarter scaling a poor certification strategy.
At the cloud policy ratio: two vCPUs per processor license where hyperthreading is enabled, one where it is not. The processor core factor table does not apply on authorized cloud, so per chip factors change nothing on AWS.
Instance level records across the measured period: monthly inventories with instance types and vCPU allocations, License Manager reports, billing extracts corroborating instance hours, and RDS class listings. Point in time console screenshots at the end date are routinely challenged.
Oracle's practice hardened. Silent clauses are now read against cloud counting, evidence requests span the full final year, and averaging language is standard in new and renewed agreements. Assume all three behaviors in any current certification planning.
BYOL instances on RDS follow the same clause logic as EC2, so they certify only where cloud counting is admitted. License included RDS instances never certify, because the underlying Standard Edition 2 license belongs to Amazon, not to you.
Scaling AWS late in the term on the assumption it inflates the certified count. Between exclusionary clauses and the averaging rule, late growth converts poorly or not at all, and the capacity must then be relicensed at list after exit.
Read the clause first, run separate cloud and on premises counts from day one, export instance level evidence monthly, and keep the workloads you intend to certify on infrastructure the contract recognizes. Then fix the clause itself at the next commercial event.
How BYOL, universal credits and Database@Azure actually price out across Azure, AWS and OCI, and where the count inflates.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
