AWS was 20 to 60 percent of the footprint, and one clause decided whether it counted

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 three mechanisms nobody checks until the final quarter: the clause generation, the averaging rule, and the evidence you kept.

Prepared by Redress Compliance · August 15, 2026 · Oracle advisory. 20 to 30 Oracle estates on AWS reviewed, 2024 to 2026.

• Read the certification clause now and classify it: silent, excluding, or averaging. That single paragraph decides whether your cloud strategy and your ULA are compatible at all.
• Scale AWS early in the term where averaging applies, because capacity brought online in the final months contributes a fraction of its footprint to the certified number.
• Keep instance level evidence continuously across the final year, since the averaging count can only be defended by a record that spans the window it averages.
• Move anything that must certify off license included RDS and onto bring your own license, because Amazon's license never becomes your entitlement.
• Model the count at the cloud ratio, two vCPUs per processor license with hyperthreading on, rather than at on premise core factors that do not apply.
• Negotiate cloud counting language at renewal, where it is one of the five clauses usually missing from the first draft.

The phrase unlimited deployment does exactly what it says while the agreement runs, and this is precisely what makes ULAs dangerous for cloud heavy estates. An architecture team migrating Oracle workloads to AWS during a ULA term encounters no licensing friction whatsoever: no counts, no true ups, no purchase orders.

Every signal the organization receives says this is free. And it is free, for as long as the term lasts, which is why cloud reached 20 to 60 percent of the Oracle footprint in the estates we reviewed without anyone treating the migration as a licensing decision.

Certification is where the bill arrives, and it arrives selectively. Three separate gates decide what the cloud estate contributes: whether your clause generation admits cloud at all, how much of it the averaging rule credits, and whether your evidence can prove the number. Fail the first and the entire AWS footprint converts to nothing.

Pass the first but fail the third and you are arguing a year long average with a screenshot. In nearly half the estates we reviewed, the buyer had scaled Oracle on AWS without ever checking whether those cores could be certified, which is a decision made by omission rather than by anyone in particular.

The averaging rule deserves special attention because it inverts standard ULA advice. The conventional move before certification is to deploy hard, since capacity added inside the term is free and permanent.

Under a 365 day average, a final quarter push contributes roughly a quarter of its size, which turns the classic end of term scramble into an expensive gesture. Cloud capacity has to be built early to count fully, meaning the deployment plan and the certification clause need to be read together at signature rather than discovered together at exit.

The financial consequence is simple and large. Capacity that fails to certify does not disappear; it keeps running, and it has to be relicensed at full price after the exit, at which point there is no unlimited right and no leverage.

In the largest estate we reviewed that recovery ran into seven figures for AWS cores that had been operating happily and freely for three years. Read the clause, scale early, keep the evidence, and treat cloud counting as a contract question rather than an infrastructure one.

The exit mechanics sit in the exit strategy guide, the count itself in the certification guide, and the wider library in the Oracle practice.

Watch the briefing · 4:30How to Negotiate an Oracle ULA: No Price List, Just Your Business CaseKeep the product list narrow, model the breakeven yourself, and settle the certification and cloud counting rules before signature.

Across 20 to 30 Oracle estates running on AWS, the cloud counting clause was the single most expensive line in the agreement:

The patterns: in nearly half the estates the buyer had scaled Oracle on AWS without checking whether those cores could certify, and buyers assuming a point in time count discovered the averaging rule in the final quarter, after the scaling decisions were already made.

The buyer side move is to read the clause years before the count. The wider library sits in the Oracle practice.

Does Oracle allow ULA deployment on AWS?

Yes during the term. A ULA grants unlimited deployment of the named products and AWS sits inside that right, so nothing blocks scaling Oracle on EC2 or RDS while the agreement is live. The exit is where AWS changes the math, because certification converts deployed usage into a fixed perpetual count.

How does Oracle count Oracle on AWS?

Under its cloud policy, by allocated vCPU: two vCPUs count as one processor license where hyperthreading is enabled, one vCPU as one license where it is not. The vCPU ratio applies and the on premise core factor table does not, which surprises buyers modeling cloud capacity on server assumptions.

What decides whether AWS cores certify?

Your ULA's certification language, not Oracle policy. Three clause generations exist: older agreements are silent on cloud or exclude it, while many later agreements admit cloud through a 365 day averaging rule. Read your own clause before assuming any cloud capacity will survive the count.

What is the 365 day averaging rule?

Where it applies, cloud deployment is certified on an average across the final year rather than at a point in time. That punishes late scaling: a final quarter AWS push adds only a fraction of its size to the certified count, so capacity brought online in the last months contributes far less than its footprint suggests.

What evidence does Oracle expect for AWS?

Instance level evidence spanning the final year of the term, not an end date export. Point in time screenshots fail under the averaging language, because the number being certified is a year long average that only a continuous record can support.

Do RDS license included instances count?

No. License included RDS instances run on Amazon's license, not yours, so they can never enter your certified count. Estates that scaled on license included RDS during the term discovered at certification that none of that capacity converted into entitlement.

What happens if AWS capacity is excluded?

You relicense it after exit at full price. In the largest estate we reviewed, the cost of recovering excluded AWS capacity ran into seven figures, which is why the clause, the averaging rule, and the evidence file need checking years before the term ends rather than in the final quarter.