Running Oracle Licenses on OCI vs AWS: The Cost Gap

Most cloud comparisons start with compute prices, and for Oracle workloads that is the wrong place to start. The largest cost in a serious Oracle estate is rarely the infrastructure; it is the database licenses and the annual support stream attached to them. So the question that actually decides the business case is not which cloud rents a vCPU more cheaply, but how far your existing Oracle licenses stretch on each cloud. And on that question the clouds are not close. Under Oracle's own published counting rules, a given pool of Enterprise Edition processor licenses covers roughly twice as much usable compute on OCI as it covers on AWS or Azure.

We are independent consultants, not Oracle and not a reseller, and we have no reason to flatter any cloud. The gap described here is not loyalty, it is arithmetic that anyone can verify against Oracle's published policy and price lists. It also comes with genuine caveats, which we cover honestly below. This article is part of our series on Oracle licensing on OCI, and it focuses on the cross cloud comparison: how the counting works on each side, what the same licenses buy, and the second order effects that widen the gap beyond the headline ratio.

How Oracle counts licenses on AWS and Azure

Oracle publishes a policy document, commonly called the cloud licensing policy, that defines how its software is counted in what it calls authorized cloud environments. AWS, including EC2 and RDS, and Microsoft Azure are the named environments. The core rule for Enterprise Edition is this: count the vCPUs of the instance, and if hyperthreading is enabled, two vCPUs count as one processor license. If hyperthreading is not enabled, each vCPU counts as a full processor license. Crucially, the processor core factor table that on premises customers use to discount license counts on certain chips does not apply in these environments at all.

Read that carefully, because it sounds generous and is not. A modern x86 vCPU on AWS or Azure is a hardware thread, not a core. Two vCPUs with hyperthreading enabled are two threads of one physical core. So the policy rule of two vCPUs per license means, in physical terms, one license per core, with no core factor discount. On premises, the same Enterprise Edition license on a typical x86 server with a 0.5 core factor covers two physical cores. Move that workload to AWS or Azure under the policy and the license that covered two cores now covers one. Your entitlement did not shrink, but what it buys did, by half.

How the same licenses count on OCI

OCI prices compute in OCPUs, and an OCPU is defined as one physical core with both of its hardware threads, which surfaces to the operating system as two vCPUs. For bring your own license deployments on OCI x86 shapes, the effective ratio for Enterprise Edition works out so that one processor license covers two OCPUs. That is the same outcome as the on premises core factor arithmetic: one license, two physical cores, four hardware threads. The full counting rules, including Standard Edition 2 and the edge cases, are in our guide to OCPU licensing rules on OCI, but the headline is simple: OCI counts the way your data center counted, while the policy for AWS and Azure counts threads with no discount.

The arithmetic, side by side

Take a concrete estate: ten Enterprise Edition processor licenses, fully supported, the kind of pool a midsize company holds after years of on premises growth. On OCI, those ten licenses cover twenty OCPUs of database compute. Twenty OCPUs is twenty physical cores and forty vCPU threads, enough for a substantial production estate. On AWS or Azure under the published policy, the same ten licenses cover twenty vCPUs, which is ten physical cores and twenty threads. Same paper, same support bill, half the compute.

Run it the other way and the gap shows up as money instead of cores. Suppose the workload needs forty vCPU threads of Enterprise Edition capacity wherever it lands. On OCI that is twenty OCPUs and ten processor licenses. On AWS or Azure it is forty vCPUs and twenty processor licenses. If you own ten, the AWS route means buying ten more, and each new Enterprise Edition processor license carries not just its list price but an annual support stream of roughly a fifth of that price, every year, for as long as you keep it. The licensing delta alone can exceed the entire infrastructure bill, which is why Oracle license counting belongs at the top of any cross cloud evaluation, not in an appendix.

Second order effects that widen the gap

Options and packs multiply the ratio. Every separately licensed option follows the same counting as the database it runs on. If your workload uses Partitioning, Advanced Compression, Diagnostics Pack, and Tuning Pack, then doubling the processor license count on AWS doubles all of those line items too. A gap that looks like ten licenses at the database layer becomes ten licenses times every option in the stack, and options frequently add half again or more to the cost of an Enterprise Edition estate. The multiplier works in OCI's favor for exactly the same reason it works against AWS.

License Included is not symmetric. On OCI, every database service offers a native License Included rate, including Enterprise Edition and tiers that bundle the major options and packs, so a workload with no spare entitlement can simply rent the license by the hour. On AWS, RDS for Oracle offers License Included only for Standard Edition 2, with the size limits that edition carries, and Enterprise Edition on AWS is bring your own license only. There is no metered EE rate to fall back on: if you want Enterprise Edition on AWS, you must own it first. The tradeoffs between the two models on OCI are a topic of their own, covered in BYOL vs License Included, but on AWS the choice does not exist for EE at all.

Support Rewards only accrue on OCI. Oracle Support Rewards credit a portion of your OCI Universal Credits spend against your Oracle technology support bill, at published rates of a quarter to a third of eligible spend. For a company carrying a large support renewal, this quietly converts cloud spend into a support discount. Spend on AWS or Azure earns nothing against the Oracle support bill and never will. When you model total cost of ownership across clouds, this credit belongs in the model, because for license heavy estates it can offset a meaningful slice of the annual renewal.

RAC has nowhere to run on AWS or Azure native services. Real Application Clusters is not supported on EC2, RDS, or Azure VMs. Workloads that depend on RAC for availability or scale must either be rearchitected to live without it or run on services that are built on Oracle engineered systems. On OCI, Exadata Database Service and related offerings support RAC natively. For estates with RAC in the critical path, this is not a cost gap but a feasibility gate.

Embedded Oracle services blur the lines. Oracle Database@AWS, and the equivalent offerings inside Azure and Google Cloud, place OCI managed Exadata hardware inside the other cloud's data centers. Workloads on those services run on Oracle infrastructure with OCI style database services, which changes the licensing picture relative to running on native AWS or Azure compute, and brings RAC and Exadata features along with it. The commercial terms, license counting, and available credits differ by offering and by agreement, so treat these as a separate column in any comparison and verify the specifics for your contract rather than assuming the OCI rules carry over unchanged.

The caveats, stated plainly

The cloud licensing policy that defines the AWS and Azure counting is a policy document, not a contract. Oracle states explicitly that it is for educational purposes and noncontractual, which means Oracle can revise it, and your actual rights live in your ordering documents and master agreement, not in the PDF. The policy has changed before, most famously in 2017 when the counting for authorized cloud environments was made materially less favorable, and nothing prevents it from changing again in either direction. Some customers also hold contractual terms that differ from the policy. Before committing to any cross cloud plan, pull the current version of the policy, read your own agreements, and have someone qualified confirm how the counting applies to your specific entitlements. The arithmetic in this article reflects the published rules as they stand, and it is your responsibility, ideally with independent help, to verify them at decision time.

It is also worth saying that licensing is one input among several. Network ecosystems, existing AWS or Azure commitments, team skills, and data gravity all weigh on a platform decision, and there are estates where the right answer is to pay the Oracle licensing premium on AWS because everything else lives there. The point is not that OCI always wins; the point is that the license arithmetic is large enough that no comparison is honest without it.

A six step framework for comparing license cost across clouds

Step four is where most comparisons go wrong, because teams price the missing licenses at list and forget the support stream, or assume an Enterprise Edition License Included rate exists on AWS when it does not. If you want to see the framework applied to real numbers, with the crossover points worked through, our BYOL savings worked examples article runs the full calculation for several estate sizes.

What this means in practice

For organizations with significant Oracle estates, the license counting gap is usually the largest single number in the cross cloud comparison, bigger than compute pricing, bigger than egress, bigger than discounts. It does not decide every case, but it reframes the question: AWS or Azure must be better enough at everything else to overcome a roughly two to one disadvantage in what your existing licenses buy, plus the options multiplier, plus the absence of Support Rewards, plus the RAC constraint where it applies. Sometimes they are. Often they are not, and the honest move is to run the numbers before the platform politics start.

This is the work our OCI consulting practice does at the start of most engagements: an entitlement inventory, the counting applied per cloud, and a total cost model the finance team can interrogate. We run it under a fixed project fee when the scope is a single decision, under a Managed Monthly retainer when the estate needs ongoing licensing and cost stewardship, and under our Optimization model, charged as a percent of verified savings, when the goal is to recover money from an estate already deployed. We are independent, we hold no reseller relationship with any cloud, and when the numbers favor staying on AWS we say so. The comparison should be won on arithmetic, not loyalty, and the arithmetic is checkable by anyone willing to read the policy and count the threads.