Oracle license mobility across multicloud: which platform is cheapest for the same workload.

An Enterprise Edition workload needs the same number of licenses on AWS, Azure and Google Cloud. The cheapest platform is decided by where your applications run, your regions, the OCI BYOL ratio in your contract, and how much support Support Rewards can retire.

How does Oracle license mobility work across AWS, Azure, Google Cloud and OCI?

For Enterprise Edition, the license count is the same on all three hyperscalers. Oracle's cloud licensing policy names Amazon EC2, Amazon RDS, Microsoft Azure and Google Cloud Platform as Authorized Cloud Environments and applies one rule to each: 2 vCPUs count as 1 Processor license with hyperthreading on, and 1 vCPU counts as 1 Processor with it off.

The same policy states that the Processor Core Factor Table does not apply in any Authorized Cloud Environment. The 0.5 multiplier you rely on for Intel and AMD servers on premises disappears once the workload runs in one of these clouds, and you cannot stack it on top of the vCPU rule.

How does OCI count differently?

OCI uses a different metric. One OCPU is one physical core with two threads, which Oracle itself treats as 2 vCPUs, so a 32 core equivalent lands at 32 OCPUs. Newer database services bill in ECPUs. The BYOL conversion for both sits in Oracle's service documents, outside the cloud policy, and that is where the variance lies.

Why a core for core migration doubles the license count

The loss of the core factor is where most migration budgets break. 32 physical x86 cores on premises need 16 Processor licenses at the 0.5 factor. A 32 vCPU cloud instance also needs 16, but it gives you only 16 physical cores.

Rebuild the same 32 cores in the cloud and you provision 64 vCPUs, which need 32 licenses. Teams that match their on premises thread count double their license requirement this way, often unnoticed until someone counts. Size on measured peak load, and test whether a newer processor generation can carry the workload on fewer cores.

Worked example: 48 cores moving to AWS

Say you run Enterprise Edition on two Intel servers with 48 physical cores between them, and you own the 24 Processor licenses the 0.5 factor requires. Oracle's current technology price list shows $47,500 per Processor license and $10,450 a year in support. Here are three ways to rebuild that capacity on AWS.

The middle row only works if the workload fits on half the physical cores it uses today. Check peak CPU across a month end and a quarter end before you commit to it, using your monitoring tools or AWR if you license the Diagnostics Pack, because the shortfall in the other two rows has to be bought.

Standard Edition 2: the vCPU cap and the Named User Plus floor

Standard Edition 2 is the one place where published readings of the cloud policy diverge. One reading caps SE2 at 8 vCPUs on AWS (2 vCPUs to a core) and 4 vCPUs on Azure and Google Cloud (1 vCPU to a core). A second reading gives 8 vCPUs on all three, with 4 vCPUs counting as one socket.

The current Oracle policy document, which we checked for this update, reads the second way: up to eight vCPUs on AWS, Azure or Google Cloud, with every four vCPUs counted as one socket. Older versions worded Azure differently, so pin the version in force at signature. Our SE2 cloud vCPU limits guide walks through the socket arithmetic.

• Named User Plus floor. SE2 licensed by user carries a minimum of 10 NUP per 8 vCPUs, however few people log in.
• Socket rounding. A 6 vCPU instance counts as two sockets, the same as an 8 vCPU one.
• No room to grow. Past 8 vCPUs you are on Enterprise Edition, with its options and the 2 vCPU rule.

Add the floor to the socket count and SE2 is often less of a bargain than it looks on a spreadsheet. Size the cap and the floor before you compare it with Enterprise Edition.

Which BYOL conversion ratio applies on OCI?

Oracle's published sources do not agree, and the gap between them is the most expensive divergence on this page.

• Oracle's mapping. The BYOL FAQ maps one Processor license to two OCPUs. Autonomous Database guidance asks for one Processor license, or 25 Named User Plus, per 8 ECPUs or 2 OCPUs, half the hyperscaler count for the same cores.
• The conflicting reading. One reading of Exadata Database Service guidance has 2 Processor licenses consumed per OCPU, a 4x swing on the same footprint.
• The RAC condition. Above 64 ECPUs or 16 OCPUs, Autonomous Database also needs Real Application Clusters licenses at the same ratio.

The source of record for every service is the PaaS and IaaS Universal Credits Service Descriptions, so the conversion rate belongs in your ordering document.

The disagreement works in your favor. Where two readings of Oracle material exist, you are entitled to ask for the favorable one in writing, and in our experience Oracle concedes a defined conversion in an ordering document far more readily than it concedes a discount.

Is Oracle cheaper to run on OCI than on AWS, Azure or Google Cloud?

At the database service level, list prices are now close to identical across venues.

• Oracle AI Database@AWS. Bought through the AWS Marketplace but priced the same as Exadata Database Service on OCI.
• Oracle AI Database@Azure. Earlier comparisons put rates per ECPU hour within 3 to 6 percent of equivalent Exadata rates on OCI. Oracle's pricing page now states the price is the same as Exadata Database Service on OCI.
• Oracle AI Database@Google Cloud. Oracle states feature and list price parity.

That parity is deliberate. It pushes the platform decision onto where your application tier already runs, the one thing Oracle cannot charge for directly. If your applications live in Azure, Database@Azure avoids cross cloud latency and egress at the OCI price.

The license count follows the service too. Database@Azure, Database@AWS and Database@Google Cloud are OCI database services, and Oracle points BYOL buyers to the Service Descriptions for their conversion rates. The 2 OCPU or 8 ECPU mapping applies there, while Oracle on a plain Azure virtual machine or EC2 instance falls under the 2 vCPU rule.

What does vary on OCI's own rate card?

The prices that move sit on OCI's own rate card, and what changes them is BYOL status, whichever cloud you pick. OCI compute lists at $0.025 per OCPU hour. The database services show the widest gaps.

• Autonomous Database on the OCPU metric. $1.34 per OCPU hour license included. Oracle's ECPU FAQ prices a 4 OCPU Autonomous Lakehouse at $5.36 an hour, which is the same rate.
• Autonomous Database on the ECPU metric. $0.336 per ECPU hour license included against $0.0807 with BYOL, a gap of 76 percent.
• Exadata Cloud Service X10M. $3.10 per OCPU hour license included against $0.81 with BYOL.

Published estimates of the BYOL saving span 40 to 80 percent depending on the service tier, and lower tiers show smaller gaps. Model your own crossover instead of quoting a headline figure. Our BYOL versus License Included crossover analysis exists because the answer depends on the workload.

Where the discount comes from

The price you can actually shift in negotiation is the Universal Credits commitment. Negotiated discounts rise with the size of the annual commit:

• $250K a year. Roughly 10 percent.
• $10M or more. Past 35 percent.

That curve is worth several times any per hour difference you will find comparing marketplace listings side by side, and so is OCI's single price across regions, covered below. Because list prices are flat across clouds, your main source of discount is committing more spend to Oracle, which is the outcome Oracle designed.

Treat the commitment tier as the thing you negotiate, and never accept a commit sized to a discount band you cannot consume within the term. Our guide to Universal Credits across Oracle's multicloud offers covers how the commit applies to each venue.

Why has Oracle made the multicloud decision a commercial one?

Because Oracle has flattened the two variables a buyer would normally use to rank platforms. The Enterprise Edition conversion is identical on Amazon EC2, Amazon RDS, Azure and Google Cloud, with the core factor withdrawn, and the Database@Cloud rate cards sit at or near OCI parity.

Every variable left is one Oracle sets on its own terms: Universal Credits discount tiers, Support Rewards accrual rates, and the BYOL eligibility language in the Service Descriptions document that your ordering document merely points to. The comparison is now about contract terms, and technical merit settles little of it.

Support Rewards on Database@AWS is a concession on venue

Oracle announced on July 8, 2025, alongside an AWS What's New notice, that customers can use existing AWS commitments and Oracle Support Rewards with Oracle Database@AWS. For a decade Oracle's position was that the only cheap place to run Oracle was OCI, and its pricing enforced that. Rewards on Database@AWS ends that argument.

Oracle would rather host your database inside another provider's data center, on a Universal Credits commit it controls, than lose the workload to PostgreSQL or a competitor's managed engine. The support annuity survives and the venue becomes negotiable. Buyers who still open with "we might have to move to OCI" are arguing against a position Oracle has dropped.

Why we would not spend negotiating time on the hourly rate

The common advice is to benchmark hourly rates across marketplace listings and push Oracle hard on price. We think that wastes your negotiating capital. The hourly rate is the number Oracle has already equalized across venues and the one it is least willing to move, because moving it would unwind the parity it built.

The commit shape is where Oracle's quota pressure lives, and where the discount curve described above gives you room. A buyer who wins on rate but accepts a commit sized to the support bill has traded the least valuable concession for the most expensive one. Spend the effort instead on two contractual terms that no rate card revision can touch:

• The conversion ratio. Write it into your ordering document, particularly on OCI where OCPU and ECPU ratios vary by service.
• The shape of the commit. Term length, ramp, rollover of unused credits, and a written promise that joining Support Rewards does not reset your discount tier.

Why cutting support and committing to cloud pull against each other

If the reward is only harvested by spending about 4x your support bill, any program that shrinks the support base also shrinks the reward. Terminating unused Processor licenses, consolidating to fewer editions or moving a workload to PostgreSQL where the economics support it all make a large commit look oversized.

A commit sized to your support bill locks in the support bill.

Oracle has built a mechanism where support reduction and cloud commitment work against each other, and that tension is by design. Decide your support reduction plan first, then size any commit against the support base you expect to keep in year three.

How much OCI spend does Oracle Support Rewards need to clear a support bill?

About four times your annual technology support bill at the standard rate. Oracle Support Rewards accrues $0.25 for every $1 of eligible OCI spend, or $0.33 for ULA customers. Oracle's own example retires a $1M support bill with $4M of OCI spend, and at the ULA rate the break even falls to about $3M.

The program only reorders a platform shortlist where planned cloud spend already sits at three to four times annual support. Below that, it is a partial discount on your support bill. Model it that way, next to the rule differences across the three venues, and read our Support Rewards guide for the enrollment mechanics.

Coverage collapses as the support base grows, the opposite of what most buyers assume. A $500K support customer can plausibly reach break even on real workload demand. A $5M support customer would need $20M of annual OCI consumption, which few reach without buying credits they will not burn, and unburned credits earn rewards no faster than burned ones.

Which conditions shrink the reward?

Each condition below cuts the effective value, so price them one by one before the program enters the business case.

• Universal Credits only. Pay as you go spend earns nothing.
• Written into the contract. The program has to be named in the cloud agreement. Check the clause instead of assuming your sales contact switched it on.
• Monthly accrual, 12 month expiry. Rewards accrue monthly and expire 12 months after issuance, so a support renewal that falls just outside the window strands them.
• No tax. Rewards cannot pay tax, which on a European or Brazilian support invoice takes 17 to 25 percent of the invoice out of coverage.
• No past due invoices. Rewards cannot be applied retroactively to support invoices that are already overdue.
• No SaaS. SaaS subscription spend does not count toward accrual.
• Named services only on AWS. Oracle Database@AWS qualifies. General EC2 or RDS spend does not.

The discount reset that can cancel the reward

The most expensive condition is the one few buyers read. An existing customer on an above standard volume discount can be reset to standard tier when a new order is placed to enable the program.

Take a 30 percent discount dropping to 20 percent on a $4M commit. That costs $400,000 a year, which is 40 percent of the $1M reward the commit was meant to earn. Get written confirmation that the new order preserves your existing tier before you sign it.

How much do regions, egress and dual running change the answer?

For a workload that must run in several regions, region choice often outweighs every other compute variable. Oracle's own pricing comparison for a 4 vCPU AMD instance shows the premiums below. They are vendor sourced, so treat them as directional and recheck them against current rate cards.

OCI charges the same rate for a service in every region. For a buyer running a single US region, that uniformity is worth nothing.

For a bank that has to run in Frankfurt, Sao Paulo and Singapore under data residency rules, regional pricing is the dominant term in the model. It compounds every year of the contract while the license count stays where it was.

Which migration costs outlast the platform choice?

A platform picked on a 5 percent hourly advantage is often locked in by a migration bill larger than three years of that advantage. In our work the two largest migration line items are rarely compute.

• Egress. Charges on the initial data movement and on any reverse movement later. Read the egress cost trap on cross cloud Oracle migrations before you sign.
• Dual running. The overlap when source and target both hold licensable cores. Oracle grants no free parallel run entitlement on Authorized Cloud Environment platforms, so model the window with our dual running cutover guidance.
• The exit itself. Price it at signature, while you still have a choice of venue.

A 90 day overlap on a 200 Processor footprint is a real second license bill. It is the number that turns a rate card win into a three year loss.

What do we see most often in Oracle multicloud licensing reviews?

Four errors recur often enough that we now test for each one by default. All four are cheap to find before signature and expensive to find in an audit.

1. Sizing by thread count. Teams match on premises thread counts and double the license need, 2x on every Authorized Cloud Environment. The core counting rules for Authorized Cloud Environments make this avoidable in an afternoon.
2. BYOL on ineligible services. BYOL gets claimed on services the underlying license was never eligible for, and it surfaces only at audit. Our note on BYOL transfer and license retention rules covers what may move where.
3. Support Rewards assumed rather than contracted. The business case counts rewards before Universal Credits and the program are in the agreement, and before anyone checks the expiry and tax rules.
4. Discount tiers that reset on new orders. The 35 percent won at a $10M commit does not carry to the next order form unless the contract says it does.

How much weight to give each source

The sources on this topic disagree, so we grade them before relying on any number. Oracle's policy documents settle the counting rules. Everything else is a reading that needs confirming in your own contract.

What will Oracle's account team say, and how should you answer?

Expect the conversation to steer toward commitment size, because that is where Oracle's quota sits. These are the lines we hear most, with the replies that keep the discussion on terms you can enforce.

• "OCI is the cheapest place to run Oracle." Ask for the same Enterprise Edition workload priced on OCI and on Database@Azure or Database@AWS side by side. With identical license counts and near identical database rates, any gap has to come from the commit or from rewards, and both can be negotiated on their own.
• "The BYOL ratio is set out in the Service Descriptions." Ask for the ratio and the document version written into the ordering document. A pointer to a document Oracle can revise gives you less than a stated number.
• "Support Rewards will pay for your support." Ask them to show the arithmetic at your actual support bill and forecast consumption, month by month, against your support renewal date.
• "Your current discount carries over." Ask for that sentence in the order. If it is true, it costs them nothing to write down.
• "A bigger commit gets you into the next discount band." Ask for a ramp and rollover of unused credits instead. A band you cannot consume is a prepayment.

What contract terms should you ask for in an OCI or Database@Cloud order?

Ask for terms that survive Oracle's rate card revisions. Oracle's cloud policy document describes itself as an educational reference that can change, so anything that matters has to be in the ordering document or the cloud agreement.

• A stated BYOL conversion ratio for each service. Name the OCPU or ECPU ratio and the Service Descriptions version, so a later revision or a different reading cannot change your count.
• An eligible license list. State which of your existing licenses may be applied to which service, so a BYOL claim cannot be challenged later.
• A Support Rewards clause. Name the program, the accrual rate and the eligible services, including Database@AWS where it applies.
• Discount tier protection. Confirm that the new order keeps your existing volume discount.
• Commit shape. Term length, a ramp that follows your migration plan, and rollover of unused credits into the next period.
• Reward timing. Align accrual with your support renewal date so credits do not expire unused.
• Policy version. Reference the cloud licensing policy version in force at signature, which settles the SE2 cap. Our summary of the 2026 cloud licensing policy tracks the current wording.

When should each step happen before you sign?

Most of this work costs little if it starts a year out. Left to the final month, each item tends to end as a concession to close the deal.

How does the cheapest platform change with the size of your Oracle footprint?

With a small support bill and one region, the cheapest platform is usually the one next to your application tier. With a large support bill, several regions or Standard Edition 2, other factors take over, as the table shows.

What to do next

1. Recount the target footprint in vCPUs or OCPUs before you approve an instance size. Without the core factor, a core for core rebuild on a hyperscaler doubles the license count, and your business case has to absorb that or size the instances down.
2. Get the BYOL conversion ratio and eligible license list into the ordering document. The published ratios conflict, so the only reliable source of record is the Universal Credits Service Descriptions version named in your order.
3. Model Support Rewards at 4x your annual technology support spend, or 3x with a ULA. Credit nothing in the business case until Universal Credits and the Rewards program are both named in the cloud contract, since pay as you go accrues nothing.
4. Price the workload in your most expensive region, never US East. Hyperscaler premiums in Europe and South America change the ranking for any workload that runs in several regions, while OCI charges one rate everywhere.
5. Demand written confirmation that a new OCI order will not reset your volume discount. A renewal or amendment is where an above standard Universal Credits tier can slide back to standard. Review the multicloud rule differences in the same drafting pass.
6. Keep the order of work. The recount is free and takes days, and contract language costs only negotiating time, so do both before any modeling. Teams that reverse the order build a Rewards case on an unverified vCPU count and find both wrong in the same audit cycle.

Frequently asked questions