ULA certification cloud counting is where most enterprises leave perpetual entitlement on the table. Oracle counts OCI, AWS and Azure deployments under three different rules at certification — and getting BYOL counting right can be the difference between certifying a defensible perpetual position and under-claiming what your ULA already paid for.
Short answer: Oracle BYOL cloud deployments are countable at ULA certification, but each cloud uses a different rule. OCI counts OCPUs (1 OCPU = 2 vCPUs). AWS and Azure use the Authorized Cloud Environment rule — 2 vCPUs per Processor license with hyperthreading, no Core Factor. Counting genuine cloud usage before expiry raises your certified perpetual quantity.
Short answer: At certification you declare every in-scope deployment, including cloud. Oracle converts each cloud instance to a Processor count using cloud-specific rules — OCPUs for OCI, vCPUs for AWS and Azure — then adds it to your on-premise count to set your permanent license quantity.
A ULA (Unlimited License Agreement) is a fixed-term Oracle contract granting unlimited deployment of named products in exchange for a single upfront fee. ULA certification is the process at the end of that term where you declare your total deployment to Oracle, and that declared count becomes your perpetual, capped license entitlement forever after. BYOL (Bring Your Own License) is the model under which you apply licenses you already own to a cloud environment instead of paying the cloud provider's license-included rate.
Because certification converts unlimited usage into a fixed number, every deployment you can legitimately count adds to the perpetual entitlement you keep. Cloud deployments are not excluded from this — they are counted alongside on-premise servers. The complication is that Oracle does not count a cloud vCPU the same way it counts a physical core. The rules diverge by provider, and the divergence is large enough to change a certified count by double-digit percentages.
Our ULA advisory service models the cloud and on-premise count together before Oracle's LMS team produces its version. The enterprises that certify the strongest perpetual position are those that understand cloud counting months before the certification date — not the ones that discover the rules during the LMS true-up.
Short answer: Yes — genuine BYOL deployments of in-scope products in OCI, AWS or Azure are countable at certification, the same as on-premise installations. The deployment must be real, in production or pre-production use, and active before the certification date. Oracle challenges artificial spikes, so the usage has to be defensible.
This is the single most misunderstood point in cloud-era ULA certification. Many enterprises assume cloud deployments either do not count, or that Oracle will not allow them to be certified into the perpetual position. The opposite is true: when a product is in scope under the ULA, its BYOL cloud footprint counts toward the certified quantity exactly like a physical server. Failing to count it means certifying a smaller perpetual entitlement than the deployment you actually ran.
The condition Oracle attaches is genuineness. A workload spun up in the final week purely to inflate the count, then torn down immediately after certification, is exactly the pattern Oracle's LMS team looks for. The defensible approach is to migrate or deploy real workloads to the cloud during the ULA term — ideally six to twelve months before expiry — so the deployment is established, instrumented and supportable as legitimate production use.
Across 40+ ULA certifications, Oracle Licensing Experts has found that correctly counted cloud BYOL deployments add an average of 18% to the certified Processor count — entitlement most enterprises forfeit by treating cloud as outside the ULA scope (Oracle Licensing Experts benchmark, 2026).
Short answer: OCI counts OCPUs, where 1 OCPU equals 2 vCPUs, so a 16-OCPU instance certifies as 8 Processor licenses. AWS and Azure use the Authorized Cloud rule: 2 vCPUs per license with hyperthreading on, no Core Factor. The same compute therefore certifies differently depending on which cloud it runs in.
Oracle's Authorized Cloud Environment policy is the document that governs AWS and Azure counting. Under it, Oracle counts an Authorized Cloud instance at two vCPUs per Oracle Processor license where hyperthreading is enabled (the default on most instance types), and one vCPU per license where hyperthreading is off. Critically, the Core Factor Table — the 0.5 multiplier that applies to Intel physical servers — does not apply in Authorized Cloud. You count raw vCPUs.
For OCI, Oracle uses its own OCPU metric. An OCPU (Oracle Compute Unit) maps to one physical core with hyperthreading, which Oracle presents as two vCPUs. The counting rule is one Processor license per two OCPUs for most Enterprise Edition deployments after the Core Factor equivalent is applied — in practice, an OCI shape with 16 OCPUs typically certifies at 8 Processor licenses. This makes OCI the most license-efficient destination, which is exactly Oracle's commercial intent: the licensing model is designed to pull workloads onto OCI.
The practical consequence at certification is that where a workload runs changes how much perpetual entitlement it generates. The same 64-vCPU footprint can certify as 32 Processor licenses in AWS, but only 16 in OCI under OCPU counting. When you are trying to maximise the certified perpetual position, that asymmetry matters — and it interacts with where you actually want to run the workload after certification. Our Oracle cloud licensing guide covers the full Authorized Cloud framework.
The table below summarises how Oracle counts a deployment of Oracle Database Enterprise Edition in each environment at certification. All examples assume a hyperthreaded instance running an in-scope ULA product.
| Environment | Counting basis | Core Factor? | Example: 64 vCPU / equivalent | Certified Processor licenses |
|---|---|---|---|---|
| On-premise (Intel x86) | Physical cores × Core Factor | Yes — 0.5 | 64 physical cores | 32 |
| OCI (BYOL) | OCPU count (1 OCPU = 2 vCPU) | Built into OCPU | 32 OCPUs | 16 |
| AWS (Authorized Cloud, BYOL) | vCPU ÷ 2 (hyperthreading on) | No | 64 vCPUs | 32 |
| Azure (Authorized Cloud, BYOL) | vCPU ÷ 2 (hyperthreading on) | No | 64 vCPUs | 32 |
| AWS/Azure (hyperthreading off) | vCPU × 1 | No | 64 vCPUs | 64 |
Two points stand out. First, OCI is the most efficient counting environment, certifying half the licenses of an equivalent AWS or Azure footprint. Second, hyperthreading status materially changes the AWS and Azure count — an instance family that does not present two threads per core doubles the certified number for the same workload. Verifying the hyperthreading status of every Authorized Cloud instance before certification is a routine but high-value check.
Our compliance review service produces a forensic deployment inventory across OCI, AWS, Azure and on-premise with a projected certified count under each rule — before Oracle's LMS team sees anything. Request a confidential cloud count modelling session.
Short answer: Migrate genuine workloads to in-scope cloud environments six to twelve months before expiry, instrument them as real production use, and document them in your deployment inventory. Deploy where the counting rule favours you while still meeting your post-ULA architecture plan. Avoid last-week spikes — Oracle challenges them.
Deployment maximisation before certification is legitimate and well-established: it is the practice of expanding genuine in-scope deployment during the ULA term so that the certified perpetual count reflects the largest defensible footprint. Cloud makes this faster than on-premise — you can stand up substantial capacity in days rather than procurement cycles. The discipline is keeping every deployment real. Follow this sequence:
Oracle's counter-tactic: Oracle's LMS team reviews deployment timelines specifically to identify artificial end-of-term spikes. A workload that appears days before certification and vanishes immediately after is the classic pattern it disputes. Maximisation only holds up when the usage is genuine, sustained and evidenced — which is why it must begin months, not days, before expiry.
Short answer: Your certified cloud deployments become a fixed perpetual license quantity, identical to on-premise certified licenses. You can keep running them as BYOL, redeploy them on-premise, or reallocate them across environments — but you can no longer exceed the certified number without buying more licenses.
The moment certification completes, the "unlimited" period ends and your entitlement is capped at the certified number. Licenses certified from cloud deployments are not tagged to the cloud — they are ordinary perpetual Processor or Named User Plus licenses that happened to be measured in the cloud. You can move them back on-premise, shift them between OCI, AWS and Azure, or consolidate them, subject to the standard counting rules in each destination.
This is why the destination you choose during maximisation matters. If you certify a large count from AWS but then move everything to OCI, you may find your OCI footprint consumes fewer licenses than you certified — leaving spare entitlement, which is fine. The reverse is the trap: certify a count in OCI under efficient OCPU counting, then redeploy to AWS where the same workload consumes twice the licenses, and you can breach your cap. Model the post-certification architecture before you lock the number.
Support cost is the other consequence. Your certified quantity sets the net license value on which Oracle bases annual support at 22% per year. A larger certified count protects your deployment flexibility but raises the support base — a trade-off our guide to ULA support after certification addresses in detail. The cloud-savvy enterprises in our case studies certify the count that matches genuine future need, not simply the largest number possible.
Four errors recur across enterprise ULA certifications involving cloud, and each one costs perpetual entitlement or creates audit exposure:
Each of these is avoidable with an independent, forensic count produced before certification. The pattern in our engagements is consistent: enterprises that model their cloud and on-premise count independently certify a defensible quantity 15–30% different from Oracle's opening LMS figure — sometimes higher where Oracle understated genuine cloud entitlement, sometimes lower where Oracle over-counted. Knowing the rules is what lets you challenge in either direction.
Yes. Oracle BYOL deployments in OCI, AWS and Azure are countable at ULA certification provided the cloud product is in scope under the ULA. Each cloud is counted under a different rule — OCI uses OCPU counting, while AWS and Azure use the Authorized Cloud Environment vCPU rule. Counting genuine cloud deployments increases your certified perpetual quantity.
Under Oracle's Authorized Cloud Environment policy, AWS and Azure are counted at two vCPUs per Oracle Processor license when hyperthreading is enabled, and one vCPU per license when it is off. The Core Factor Table does not apply in Authorized Cloud. A 64 vCPU hyperthreaded instance therefore certifies as 32 Processor licenses.
The Core Factor Table does not apply to AWS and Azure under the Authorized Cloud Environment policy — counting is done on vCPUs directly. For OCI, Oracle counts OCPUs, where one OCPU equals two vCPUs. The 0.5 Intel Core Factor only applies to on-premise and co-located physical servers.
Yes, provided the deployment is genuine, in production or pre-production use, and active before the certification date. Migrating eligible workloads to the cloud during the final months of a ULA is a legitimate way to maximise your certified perpetual entitlement, but Oracle scrutinises last-minute spikes, so the usage must be real and evidenced.
After certification your cloud deployments convert into a fixed perpetual license quantity, identical to on-premise certified licenses. You can continue running them as BYOL in OCI, AWS or Azure, redeploy them on-premise, or reallocate them — but you cannot exceed the certified number without buying additional licenses.
ULAs signed before roughly 2017 to 2019 frequently contain no explicit public cloud language. Oracle will still apply its current Authorized Cloud Environment counting policy at certification, but the absence of contract language creates disputes over whether AWS and Azure deployments are countable. Clarify cloud rights in writing before certification begins.
Weekly briefing on ULA certification trends, cloud counting rules and audit risk intelligence. Read by 2,000+ Oracle stakeholders at Fortune 500 enterprises.
Enterprises that model their certified count across OCI, AWS, Azure and on-premise — before Oracle's LMS team arrives — certify a defensible perpetual position. Our forensic inventory and count modelling has reduced Oracle's opening position by an average of 23% where it over-counted, and recovered understated cloud entitlement where it under-counted.