Oracle's ACE policy withdraws the 0.5 core factor, so the same 32-core workload needs 16 processor licenses in AWS, Azure, or GCP versus 8 on comparable on-premises Intel hardware
Oracle's Authorized Cloud Environment policy counts vCPUs at 2:1 with multi-threading enabled and explicitly states the Processor Core Factor Table does not apply, doubling the license requirement for identical compute. The only remaining lever is reducing the vCPUs Oracle can see, and Azure constrained SKUs plus AWS RDS Optimize CPU cut the count 50 to 75 percent while holding memory and IOPS constant. Whether you plan around that lever, or discover it after Oracle audits you, decides a seven-figure difference on most estates over 200 processor licenses.
Prepared by Redress Compliance · August 18, 2026 · Oracle advisory. Cloud licensing and audit-defense engagements, 2024 to 2026.
Executive summary
The ACE policy is extra-contractual, and Oracle reserves the right to rewrite the counting rules at any time, which it has done repeatedly including the June 12, 2024 revision that added Google Cloud.
Nothing in your Oracle Master Agreement or OLSA addresses cloud counting, so the document setting your license requirement is a PDF Oracle can replace without notice or consent.
The single largest number in cross-cloud planning is the withdrawn 0.5 core factor: the policy states flatly that the Processor Core Factor Table is not applicable in Authorized Cloud Environments, which doubles the license count for the same Intel cores you licensed at 0.5 on premises.
A 32-core on-premises Xeon estate licensed at 16 processors becomes 32 processors' worth of vCPU exposure in AWS unless you actively constrain vCPUs.
Platform choice does not change the 2:1 ratio, but it changes how cheaply you can reduce the vCPU count Oracle counts, and Azure's predefined constrained SKUs deliver a 50 to 75 percent reduction in billable vCPUs with zero loss of memory, disk, or IOPS.
A Standard_E32-8s_v5 exposes 8 vCPUs instead of 32 while keeping 256 GiB RAM and 80,000 IOPS, taking the license requirement from 16 processors to 4.
Two failure modes account for most of the exposure we find: Standard Edition 2 instances running above the 8 vCPU ceiling, and ULA licenses deployed into ACE that cannot be counted at certification.
Both are silent until an audit or a ULA exit, and both are cheap to fix 12 months out and expensive to fix 30 days out.
How the ACE policy actually counts: vCPUs, threads, and the withdrawn core factor
The counting mechanics in Licensing Oracle Software in the Cloud Computing Environment (policies in effect as of June 12, 2024) are short enough to read in ninety seconds and expensive enough to reread every renewal.
You count the maximum vCPUs of the instance type, not the vCPUs you actually use, not the vCPUs the guest OS reports after tuning. Where multi-threading is enabled, two vCPUs equal one Processor license. Where it is disabled, one vCPU equals one Processor license.
Oracle's own worked example in the document fixes the ratio: four vCPUs with multi-threading enabled requires two Processor licenses for Database Enterprise Edition.
Standard Edition and SE2 are counted differently, with every four vCPUs treated as a virtual processor socket and instances of four or fewer vCPUs counted as a single socket, and SE2 is capped at a maximum of eight vCPUs.
Named User Plus licensing carries over intact, minimums included, which means a 25 NUP per Processor floor still bites on small cloud instances that were sized for cost, not compliance.
Then comes the sentence that does the damage: when counting Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.
That single clause is why a 32-core Xeon estate that consumed 8 licenses on premises at the 0.5 factor consumes 16 in AWS, Azure, or GCP. Nothing about the workload changed. The multiplier did.
Note also that this entire framework is extra-contractual: it is a policy PDF Oracle can revise unilaterally, and it has revised it repeatedly, including the June 2024 revision that added Google Cloud Platform to the authorized list.
Treat it as a moving target and screenshot the version in force on the day you sign, as we cover in our read of the 2026 Oracle cloud licensing policy.
| Platform | Threading state | EE count (32 vCPU instance) | SE2 treatment | Reduction lever |
|---|---|---|---|---|
| AWS EC2 | Multi-threading on (default) | 16 Processor licenses | Blocked above 8 vCPUs | Disable threads via CPU options, or downsize the instance type |
| AWS EC2 | Threads disabled for tuning | 32 Processor licenses | Blocked above 8 vCPUs | None; count doubles |
| Amazon RDS | Multi-threading on (default) | 16 Processor licenses | 8 vCPU ceiling applies | Optimize CPU on M7i/R7i reduces countable vCPUs |
| Microsoft Azure | Multi-threading on (default) | 16 Processor licenses | 8 vCPU ceiling applies | Predefined constrained SKUs (E32-16s_v5, E32-8s_v5) |
| Google Cloud | Multi-threading on (default) | 16 Processor licenses | 8 vCPU ceiling applies | Custom machine types; no predefined constrained family |
| On-premises Intel (comparison) | Physical cores, 0.5 factor | 8 Processor licenses | Socket-counted | Core factor still applies |
The row the table cannot dramatize is the second one. Your DBA team disables simultaneous multi-threading for a perfectly defensible reason: NUMA locality, cache contention, or a benchmark that improved 12 percent with threads off.
Under the ACE policy that tuning decision moves the ratio from 2:1 to 1:1 and doubles the license requirement on that instance overnight, with no ticket, no procurement conversation, and no line item anywhere until an audit script reads the CPU options.
In our engagements this is the most common source of unbudgeted exposure in otherwise well-architected cloud estates, because the person making the change has no visibility into the licensing consequence and the person who owns the license position has no visibility into the change.
Two governance controls follow directly. First, write a change-control gate: any modification to CPU options, threading state, or instance family on an Oracle-bearing host requires a licensing sign-off before it ships.
Second, capture threading state in your evidence pack quarterly, because in an audit you will need to prove multi-threading was enabled for the whole measurement period, not just on the day the script ran. Absence of evidence defaults to Oracle's preferred reading.
Where the three clouds diverge: constrained vCPUs, Optimize CPU, and Graviton
The 2:1 ratio is uniform across all three Authorized Cloud Environments. The machinery for reducing the number the ratio gets applied to is not, and that asymmetry, not the ratio, is what decides where a workload should land.
Azure is the strongest position for large memory-bound Oracle databases because Microsoft ships predefined constrained-vCPU SKUs. Standard_E32s_v5 exposes 32 vCPUs, 256 GiB of RAM, 32 disks, and 80,000 IOPS.
The predefined Standard_E32-16s_v5 and Standard_E32-8s_v5 expose 16 and 8 active vCPUs while holding the memory, storage, and I/O bandwidth of the full size.
Microsoft states in print that Oracle licensing is constrained to the reduced vCPU count, delivering a 50 to 75 percent improvement in the ratio of VM specs to billable vCPUs, and instructs third-party vendors to count available vCPUs.
That takes a 32-vCPU workload from 16 Processor licenses to 8 or 4. The catch is on the invoice, not the license: Microsoft's own documentation confirms compute cost remains at the full-size rate, so you pay for 32 vCPUs of Azure and license 8.
On a Database Enterprise Edition estate with Options at list, that trade is worth taking every time.
AWS gives you a narrower but real lever in Amazon RDS. Optimize CPU on M7i and R7i instance families reduces the countable vCPUs directly: a db.r7i.2xlarge at 8 vCPUs requires 4 Processor licenses, and the same instance with Optimize CPU set to 4 vCPUs requires 2.
On EC2 the equivalent move is CPU options at launch, with the hard constraint that you cannot change it without a stop and restart, and with the threading trap described above sitting one misconfiguration away. Google Cloud is the weakest of the three on this specific axis.
GCP has been an authorized environment since the June 12, 2024 revision, but there is no predefined constrained family with Azure's guarantee that memory and IOPS survive the vCPU cut; you are building custom machine types and defending the resulting ratio yourself.
Kill one assumption before it reaches an architecture review: Graviton and ARM earn you nothing. There is no ARM entry in the withdrawn core factor logic because the Core Factor Table does not apply inside ACE at all, and Oracle counts vCPUs regardless of the underlying silicon.
Anyone proposing Graviton as a licensing saving on Oracle Database is confusing infrastructure economics with license economics. Model the two separately, then place the workload where the reduction lever is strongest.
For estates already committed to one hyperscaler, our guidance on moving Oracle databases between clouds covers the egress and portability costs that offset the license delta.
The Oracle Core Factor Table: Counting Processors Right
Oracle licenses cores times a core factor, not raw cores. The 0.5 x86 factor, the worked counting, the virtualization trap, and where the factor does not apply.
Get the white paper →The analysis: you are not negotiating a ratio, you are negotiating what Oracle can see
Stop trying to negotiate the 2:1 conversion.
In 25 years of sitting across from Oracle LMS, Global Licensing and Advisory Services, and the regional sales teams that inherit the findings, I have never seen the ratio move, and I have never seen the withdrawn core factor reinstated inside an Authorized Cloud Environment.
The policy text is unambiguous: the Oracle Processor Core Factor Table is not applicable, and two vCPUs equal one Processor license where multi-threading is enabled. Those two sentences are the fixed cost of the platform.
What is not fixed, and what almost nobody instruments deliberately, is the number those sentences get applied to. Every dollar of remaining leverage sits in the vCPU count Oracle is entitled to count, which means the negotiation is definitional rather than commercial.
You are not arguing about price per unit. You are arguing about how many units exist.
The load-bearing word in the entire document is available. Oracle's rule is to count the maximum vCPUs of an instance type, and Microsoft's published guidance to software vendors reads the same way: count the available vCPUs and report that as the amount to be licensed.
On an Azure constrained SKU such as Standard_E32-8s_v5, eight vCPUs are available to the guest operating system, and 24 are not. They cannot be used or obtained by any process, any scheduler, or any Oracle instance running inside that VM. The plain meaning of "available" excludes them.
That is why the constrained SKU works, and why the 50 to 75 percent reduction in billable vCPU ratio that Microsoft describes is a licensing outcome and not a marketing claim.
Oracle sales has nonetheless started to assert the full chassis count. The pattern we now see repeatedly, and Microsoft's own community threads confirm it is being raised more often, is a claim that a constrained Standard_E96-24ds_v5 owes licensing on 96 vCPUs rather than 24.
That claim fails on the plain text, but it does not fail on its own. It fails only if you can produce evidence at the moment it is made.
An Oracle account manager making a 96 vCPU assertion in a commercial conversation is not conducting an audit, he is testing whether you have the operating system output to contradict him. Most buyers do not, and the assertion becomes the baseline for a remediation quote.
Read the language change in the policy as pre-positioning. Oracle swapped the older "hyper-threading" phrasing for the broader "multi-threading of processor cores." Hyper-threading is an Intel brand term.
Multi-threading covers AMD simultaneous multithreading, ARM implementations, and whatever comes next. Oracle did not widen that wording to be generous.
It widened it so that the 2:1 conversion continues to bind on Graviton, on AMD EPYC, and on any future SMT topology, and so that no customer can argue their non-Intel instance falls outside the sentence.
The same widening cuts the other way for you: on any instance where multi-threading genuinely is not enabled, the ratio becomes one license per vCPU, which is the single most expensive configuration in the document. Confirm the thread state with your platform team before you architect anything.
Then remember what this document is. It is extra-contractual. It is not incorporated into your ordering document or your master agreement, Oracle reserves the right to change it at any time, and Oracle has exercised that right repeatedly, including on the counting rules themselves.
That cuts both ways. Oracle cannot enforce the policy as a contract term without more work than it usually admits, and you cannot rely on today's PDF as a permanent safe harbour.
An architecture that is defensible only because the current version of Oracle's cloud licensing policy happens to phrase things favourably is an architecture with a revision date attached to it.
An architecture that is defensible on evidence, that the guest could never schedule work on cores it never saw, survives a policy rewrite.
The buyer-side conclusion is operational, not legal. Instrument the vCPU count before Oracle asks.
Capture OS-level proof on every ACE instance running Oracle software: processor topology, thread counts, and the constrained SKU designation, timestamped, retained per instance, and refreshed on every resize. Do the same for AWS RDS Optimize CPU settings and any GCP custom machine type.
That evidence file is the whole asset.
It converts a definitional argument you would otherwise lose in a meeting into one you win in writing, and on estates above 200 processor licenses the difference between 32 counted vCPUs and eight is the difference between 16 licenses and four on a single instance, repeated across the fleet.
The two traps that survive good architecture: SE2 ceilings and ULA certification
Two exposures survive even a perfectly constrained estate, and neither has anything to do with the 2:1 ratio. The first is Standard Edition 2. The policy defines every four vCPUs as one virtual processor socket, and SE2 is capped at a maximum of eight vCPUs in an ACE instance.
There is no core factor argument, no constrained SKU argument, and no negotiation.
Any SE2 instance running above eight vCPUs is not an interpretation dispute, it is a licensing breach visible in a single API call.
And in our experience it is one of the fastest audit escalations Oracle runs because the evidence is unambiguous and the remediation is a forced move to Enterprise Edition plus options.
Oracle Linux support compounds it: Basic Limited and Premier Limited are unavailable above eight vCPUs, so a routine resize can silently break support entitlement and license compliance in the same change ticket. The second trap is the ULA clause.
Licenses acquired under an Unlimited License Agreement may be deployed into an Authorized Cloud Environment, but those deployments cannot be included in the end-of-term certification count.
A cloud-first migration executed during a ULA term therefore moves your installed base out of the certifiable pool, and you certify a smaller number than you actually run.
| Exposure | The rule | What it costs you |
|---|---|---|
| SE2 vCPU ceiling | 8 vCPUs maximum per ACE instance, 4 vCPUs equal one socket | Forced Enterprise Edition conversion plus options at list |
| Oracle Linux Limited tiers | Basic Limited and Premier Limited unavailable above 8 vCPUs | Support gap plus uplift to full tier on every affected system |
| ULA certification | ACE deployments usable but excluded from certification | Certified quantity understates real estate, shortfall payable post-term |
The ULA row is the one that ends careers. Migrate 40 percent of your Oracle estate into AWS or Azure in year two of a three-year ULA and you will certify only the on-premises remainder, then buy the cloud footprint again at list.
The fix is sequencing, not architecture: either certify before you migrate, or negotiate an explicit amendment permitting cloud deployments to count at certification, and get it in the ordering document rather than in an email.
On SE2, the practical control is a hard technical guardrail rather than a policy reminder, because the instance type that breaches the cap is one dropdown away from the one that does not.
Tag every SE2 instance, block resizes above eight vCPUs at the infrastructure-as-code layer, and review the tag list monthly against actual running state.
Buyers planning cross-cloud moves should read the certification exposure alongside the practical mechanics in our guide to moving Oracle databases between clouds, because the timing decision, not the destination, is where the seven-figure gap opens.
Evidence base: what the policy documents say and what recurs in engagements
The source record here is thinner than most buyers assume, and that thinness is the point.
Everything Oracle asserts about cloud counting sits in one extra-contractual PDF, "Licensing Oracle Software in the Cloud Computing Environment," whose footer currently reads "policies in effect as of June 12, 2024," plus a companion eligible-programs list stamped "policies in effect as of Jan 16.
2025." Two live dates, two documents, neither incorporated into your Oracle Master Agreement or your ordering documents.
The June 12, 2024 revision is the one that added Google Cloud Platform as a named Authorized Cloud Environment, which is why so much 2022-era internal guidance still wrongly treats GCP as unauthorized.
Inside that document Oracle fixes the arithmetic with its own worked example: Database Enterprise Edition on a four-vCPU instance with multi-threading enabled requires two Processor licenses, because two vCPUs are treated as one Processor.
And the Processor Core Factor Table is declared not applicable.
On the platform side, Microsoft has published the counter-position in writing, instructing third-party vendors to count the available vCPUs and report that as the amount to be licensed, and stating that constrained SKUs produce a 50 to 75 percent increase in the ratio of VM specs to billable vCPUs.
That is a vendor-published rebuttal you can attach to an audit response, not a consultant's opinion.
The policy document itself fixes the 2:1 ratio with multi-threading enabled, removing any argument about interpretation.
Microsoft states the licensable count follows the active vCPUs while memory, disks, and IOPS stay at the full-size level.
Four patterns recur across our engagements often enough that we now treat them as defaults until disproven.
First, teams assume hyperthreading is enabled because "cloud instances usually are," and never capture OS-level evidence, which means a single disabled-SMT instance quietly doubles from a 2:1 to a 1:1 count.
Second, Standard Edition 2 sprawl above the eight-vCPU ceiling, usually created by a routine resize ticket nobody routed past licensing.
Third, ULA-era licenses deployed into ACE and never reconciled against certification scope, despite the policy's explicit bar on counting cloud deployments at certification.
Fourth, Oracle sales raising constrained-SKU claims (owing 96 vCPUs on a Standard_E96-24ds_v5) with no contractual basis, purely as negotiation pressure. Our read on the 2026 cloud policy covers why winning that argument still leaves you arguing about the number.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Version-stamp both Oracle PDFs today, screenshotting the footer dates (June 12, 2024 and January 16, 2025) and archiving the files with a hash, because Oracle reserves the right to change the counting rules at any time and you will need to prove which version governed the period under audit.
- Run OS-level vCPU and SMT evidence collection on every ACE instance this quarter, capturing lscpu or equivalent output per host, storing it with timestamps, and treating any instance where multi-threading is disabled as a 1:1 exposure that doubles the license count until the configuration is corrected.
- Remediate every Standard Edition 2 instance above eight vCPUs before you have any audit contact, because the eight-vCPU ceiling is unambiguous in the policy text, there is no interpretive defense, and the standard Oracle remedy is Enterprise Edition backdated with support arrears rather than a resize.
- Reconcile ULA cloud deployments against certification scope at least 12 months before term end, since licenses may run in an Authorized Cloud Environment but cannot be counted in the certification, so anything migrated late becomes an uncovered deployment the day the ULA closes; our note on dual-running during cutover sets out the sequencing.
- Re-baseline platform selection on billable vCPUs, not list compute price, comparing a full-size SKU against an Azure constrained variant or an AWS RDS Optimize CPU configuration on identical memory and IOPS, then presenting the delta in processor licenses (not dollars per hour) to whoever signs the infrastructure decision, because a 50 to 75 percent cut in countable vCPUs outweighs any plausible compute discount on Enterprise Edition estates.
Frequently asked questions
Does the Oracle core factor table apply on AWS, Azure, or Google Cloud?
No. The Authorized Cloud Environment policy states explicitly that the Oracle Processor Core Factor Table is not applicable when counting Processor license requirements in ACE.
That means Intel cores you licensed at the 0.5 factor on premises effectively convert at 1.0 in the cloud, doubling the requirement for identical compute. Budget cloud migrations on the 2 vCPUs to 1 Processor rule, not on your on-premises core factor math.
Is Google Cloud Platform an Authorized Cloud Environment?
Yes, since the June 12, 2024 revision of the policy. Oracle's list now names Amazon EC2, Amazon RDS, Microsoft Azure, and Google Cloud Platform. A large volume of older guidance still says GCP is excluded, which is the single most commonly mis-stated fact in cross-cloud planning.
Verify against the current PDF before you cite it internally.
How many Oracle licenses do I need for a 16 vCPU cloud instance?
Eight Processor licenses for Enterprise Edition if multi-threading is enabled, which is the default on almost all instance types. If multi-threading is disabled, the ratio becomes one Processor per vCPU, so the same instance needs 16.
Confirm the threading state with your infrastructure team rather than assuming, because performance tuning that disables it doubles the license bill silently.
Can Oracle charge me for the full vCPU count of an Azure constrained VM?
Oracle sales has raised that claim, but it does not survive the policy text. The policy requires counting available vCPUs, and Microsoft publishes explicit guidance that third-party products should count the available (active) vCPUs on constrained SKUs.
Standard Linux commands demonstrate a constrained VM exposes only the reduced count. Capture that OS-level evidence and archive it with a timestamp before any audit conversation starts.
What is the vCPU limit for Standard Edition 2 in the cloud?
Eight vCPUs maximum. The policy treats every four vCPUs as a virtual processor socket for SE, SE1, and SE2, and SE2 is capped at eight vCPUs total.
Any SE2 instance running above eight vCPUs is an immediate remediation item and a reliable audit trigger, because it is trivially discoverable from cloud provider inventory data.
Can I use ULA licenses in an Authorized Cloud Environment?
You can deploy them, but you cannot count them at certification. The policy permits ULA licenses to run in ACE while excluding those deployments from the certification count at end of term.
If a cloud migration runs during your ULA term, the volume you moved into AWS, Azure, or GCP does not contribute to your certified quantity, creating a shortfall you discover at the worst possible moment. Reconcile this at least 12 months before term end.
Is the Oracle cloud policy part of my contract?
No, and that cuts both ways. The document is extra-contractual, meaning your Master Agreement or OLSA does not address cloud counting and Oracle can revise the policy at any time, as it has done repeatedly.
That gives Oracle flexibility, but it also means Oracle cannot enforce policy terms as contractual obligations without argument. Have counsel review the policy alongside your contracts and version-stamp the PDF you relied on for each deployment decision.
