Oracle OCI licensing: ECPU vs OCPU, BYOL and credits. Why the AWS and Azure counting rule does not apply.

OCI is not an Authorized Cloud Environment, so the two vCPU rule you use on AWS and Azure is the wrong rule. Your order's service descriptions set the ratio: one Enterprise Edition processor license covers 2 OCPUs or 8 ECPUs on Autonomous Database.

Oracle Cloud Infrastructure is the only public cloud where your software vendor also owns the meter, the hypervisor and the contract. That single fact explains every licensing difference on this page, from the counting unit to the way compliance gets checked.

Because Oracle runs the platform, it does not need a policy document to say how its software is counted. The counting sits in the service description attached to your order. That makes OCI licensing more contractual than licensing on AWS or Azure, and different enough that a reused hyperscaler model will be wrong in both directions.

Why do the OCI licensing rules differ from AWS and Azure?

Because OCI is not an Authorized Cloud Environment. Oracle's policy document, Licensing Oracle Software in the Cloud Computing Environment, names a closed list of third party clouds: Amazon EC2 and RDS, Microsoft Azure and Google Cloud Platform. Oracle's own cloud is not on that list, so the policy has nothing to say about it.

Everything in that policy stops at the edge of OCI, including its vCPU arithmetic and its Standard Edition rule that every four vCPUs count as one socket. On OCI your order and the documents it incorporates do that work instead.

What the Authorized Cloud Environments policy covers

It covers Oracle programs running on the listed clouds and sets one counting rule for them. With multithreading enabled, two vCPUs count as one processor license. Without it, one vCPU counts as one license. The core factor table is switched off entirely.

It is a policy, and Oracle publishes and revises it on its own schedule. Unless your agreement incorporates a dated version by reference, you have no contractual claim on the version you planned against. We work through that exposure on our Oracle cloud licensing policy page, and the vCPU arithmetic on our page about Authorized Cloud Environment core counting.

What governs OCI instead

Your OCI order, the service descriptions for each service on it, and the Oracle cloud services agreement. The BYOL conversion for each service is stated in that service's description, which forms part of what you signed.

That is a better position for a buyer than a policy page, and few buyers use it. If the conversion matters to your business case, cite the service description clause in the negotiation and ask for the version in force at signature to be named in the order document.

Read the last two rows together, because they pull in opposite directions. Support Rewards make OCI cheaper in total cost while you still carry a large on premises support bill. Direct visibility means Oracle never has to ask what you deployed, so compliance becomes an invoice reconciliation. That is easier to run, and far less forgiving of a wrong assumption.

For the workload by workload comparison against Amazon, see our OCI against AWS analysis and the mechanics of AWS bring your own license.

Oracle Database@Azure, @Google Cloud and @AWS follow OCI rules

This catches experienced teams. The Database@ services place Oracle owned OCI hardware inside a hyperscaler data center, connected to your tenancy in that cloud. The database runs on OCI infrastructure, so it is licensed as OCI, and the Authorized Cloud Environments policy does not reach it.

If your model applied the two vCPU rule because the service has "Azure" in its name, the model is wrong. Our page on Oracle on Azure separates the two cases. The same logic runs the other way for Cloud at Customer: the rack sits in your building, and it is still OCI for licensing purposes.

What is the difference between an OCPU and an ECPU?

An OCPU is a physical measure: one processor core with hyperthreading enabled. An ECPU is an abstracted measure that Oracle defines as cores allocated elastically from a shared pool of compute and storage servers. They are billed and licensed at different ratios, so one cannot be read as the other.

What an OCPU is on x86 and on Arm

On x86 shapes from Intel and AMD, one OCPU is one physical core presented to the operating system as two vCPUs. A shape advertised as 16 vCPUs is 8 OCPUs. Compute shapes are often quoted in vCPUs, while database services have historically been quoted and licensed in OCPUs, so read every quote for its unit before comparing it with anything.

Arm is the exception, and Oracle defines the OCPU per shape family:

• Ampere A1. One OCPU is one core and one vCPU.
• Ampere A2 and A4. One OCPU is two cores, or two vCPUs.

If you plan to run self managed Oracle software on Arm, ask Oracle in writing how an OCPU on that shape maps to a processor license. Our note on processor counts on OCI Compute shapes works through common shapes.

What an ECPU is, and where it has replaced the OCPU

Oracle introduced the ECPU in 2023, starting with Autonomous Database, to decouple billing from a fixed physical core. On Autonomous Database the switch is complete: Oracle's documentation now describes the OCPU as a retired, legacy metric and the ECPU as the billing metric for all new and existing deployments.

Elsewhere the picture is mixed. Base Database Service, for example, bills by ECPU or OCPU depending on the shape you choose. Confirm the unit for your service, edition, generation and region in the current OCI price list and the service description, and never carry an OCPU assumption into an ECPU quote.

How many processor licenses cover an OCPU or an ECPU?

Oracle publishes the ratios per service. For Autonomous Database they are set out below. The unit decides how many units one owned license covers, so a change of unit changes your entitlement requirement even when the workload has not changed.

Two limits sit alongside the ratios. Standard Edition instances cap at 32 ECPUs or 8 OCPUs. Enterprise Edition instances above 64 ECPUs or 16 OCPUs need Real Application Clusters licenses at the same ratio, and Active Data Guard follows the same ratio on both primary and standby. The detail by service is on our Autonomous Database licensing guide.

Why the core factor table does not belong in an OCI model

On premises, the Oracle processor core factor table discounts cores by processor family, which is why an Intel core counts as 0.5 of a processor license. On OCI the table is not in play. The unit is the OCPU or the ECPU, and the published conversion for your edition and service is the whole calculation.

The published Enterprise Edition ratio of two OCPUs per license already gives the result a 0.5 factor would give on x86. Two errors follow from reaching for the wrong document:

• Core factor on top of the ratio. The requirement halves on paper, and the gap shows up at true up.
• Hyperscaler vCPU rule on OCI. The requirement doubles, and you commit to licenses you do not need.

Our core factor guide covers where the table does apply.

A worked example: one database counted five ways

Say you move one Enterprise Edition database with Partitioning to OCI. On Base Database Service it needs 16 OCPUs, which is 32 vCPUs on x86. On Autonomous Database you size the same entitlement at 64 ECPUs. The table shows what each counting method says you need.

The last row is the unit drift problem in miniature. A capacity plan written in OCPUs and priced against a service that now bills in ECPUs produces a number that looks tidy and is off by a factor of four.

What does bring your own license mean on OCI?

It means you apply a license you already own against an OCI service and pay a reduced rate that covers infrastructure rather than software. Oracle lists the eligible programs on its bring your own license page, and the binding detail sits in the service description for each service.

Two different things get called BYOL, and only one is a service election

The first path is an ordinary software install. You provision OCI Compute, install Oracle Database yourself, and license it against the OCPUs the instance uses. Oracle is your infrastructure provider and nothing more.

The second path is a managed database service where BYOL is a billing election in the console, and your owned licenses offset the software part of the hourly rate.

• Self managed on OCI Compute. Maximum control and no service automation. Every patch and backup is yours. Useful for older releases and unusual configurations that no managed service supports.
• Managed service with BYOL elected. Oracle runs the automation and tooling at a lower rate than license included, and you work inside Oracle's service boundary.
• Managed service with license included. No owned license required. The highest rate and the least entitlement risk.

Buyers usually price only the second and third options because those are the ones on the quote. Price the first as well, particularly for non production and for databases you have no plan to modernize.

What the BYOL discount is worth

In the workloads we modelled in 2024 and 2025, electing BYOL removed roughly 75 to 80 percent of the license included rate for equivalent database capacity. Treat that as an observed price gap, not a rule. Oracle adjusts both rates independently, so model your workloads against the current price list rather than a remembered percentage.

The prerequisite does not change. You must own the license and pay support on it for the whole period you claim the reduced rate. Oracle's BYOL FAQ confirms that support on the on premises license continues, and that BYOL and license included cannot be mixed inside one instance.

Which options come with each database service tier?

This is where most BYOL positions break. Oracle sells Base Database Service in four editions, and the higher editions bundle database options and management packs. Under license included you rent the bundle. Under BYOL, selecting a higher edition puts those options in reach, and Oracle treats every option you use as covered by your own entitlement.

• Standard Edition. The Standard Edition database only.
• Enterprise Edition. Adds Diagnostics and Tuning Packs, Data Masking and Subsetting Pack, and Real Application Testing.
• Enterprise Edition High Performance. Adds Multitenant, Partitioning, Advanced Compression, Advanced Security, Label Security, Database Vault, OLAP, Database Lifecycle Management Pack and Cloud Management Pack.
• Enterprise Edition Extreme Performance. Adds Database In-Memory and Active Data Guard.

Two concessions narrow the gap. Oracle grants BYOL Enterprise Edition customers on its PaaS services the Diagnostics Pack, Tuning Pack, Data Masking and Subsetting Pack and Real Application Testing without an on premises license for them, though not on self managed IaaS. Transparent Data Encryption is included in every edition.

Partitioning, the rest of Advanced Security and the Lifecycle and Cloud Management Packs are not covered by a base Enterprise Edition license.

If you do not own an option the tier includes and the workload needs it, you have three choices: buy the option, drop to an edition that does not include it, or take license included for that workload. Our BYOL against license included cost comparison prices the third choice.

What do Universal Credits and the commitment lock in?

They lock a floor on your spend, and they place no ceiling on your consumption. Universal Credits is a prepaid pool you draw against across OCI services for the term you committed to. Consumption above the commitment is invoiced monthly in arrears at your rate card.

Unused credits expire at the end of the credit period

Unused Universal Credits expire and do not roll forward. Oracle's public page ties expiry to the end of the contract term, a minimum of 12 months. Annual orders usually set a yearly credit period for each annual amount, so a three year order is often three separate pools. Check which wording your order uses.

Every dollar of oversizing becomes waste with no recovery path. Commit $1,000,000 for a year, consume $750,000, and $250,000 is forfeited. Oracle sizes to a growth forecast because that is the account team's job. Sizing to a steady state you can support with data is yours. Our page on sizing Universal Credits works through the asymmetry in detail.

How Support Rewards change the economics

Every dollar of OCI consumption earns credit against your on premises technology support bill. Oracle Support Rewards accrue at 25 cents per dollar of OCI usage, rising to 33 cents for customers with a current unlimited license agreement. Rewards accrue only on a Universal Credit order, so pay as you go usage earns nothing.

Three mechanics matter more than the headline rate. You must apply the rewards to eligible support invoices yourself in the OCI Console. Rewards expire 12 months after they accrue. And they can only retire technology license support you still pay for, so they do nothing for applications support such as E-Business Suite or for subscriptions such as Java SE.

In this example the company terminated most of its on premises support in year two. The OCI spend stayed flat, but a quarter of the year two rewards had nothing left to pay for and lapsed.

Retire the on premises side too fast and you retire the bill the rewards were meant to pay. Model both together, over the full term, before you set the retirement schedule. Our Support Rewards guide covers the claim process.

Where do OCI licensing positions break?

In five places, and none of them is the unit price. Each is a question of entitlement hygiene that survived the migration unchanged.

• Double counting. One license applied against both an on premises server and an OCI BYOL instance. It cannot cover both, and Oracle can see the OCI side directly.
• Options inside a tier. The service edition bundles options you do not own, and using them under BYOL asserts that you do.
• Lapsed support. Support on the owned license expires and BYOL eligibility goes with it, usually noticed at the next renewal rather than at the time.
• Unit drift. A model built in OCPUs, priced against a service that has since moved to ECPUs.
• Wrong policy. The Authorized Cloud Environments counting rule applied to an OCI deployment, which is the wrong document by Oracle's own definition.

Each of these is cheap to prevent and expensive to unwind. The prevention is the same in all five cases: a written entitlement register, reconciled every quarter, that names which license covers which instance. If a license is moving from a data center to OCI, our page on license transfer and retention rules covers the handover.

How to check your own position

You can build the register from tools you already have. None of them needs Oracle's involvement.

• License type per database. The OCI Console shows the license type on each database system and Autonomous Database. The API and CLI return it as the licenseModel field, set to LICENSE_INCLUDED or BRING_YOUR_OWN_LICENSE.
• Options in use. Query DBA_FEATURE_USAGE_STATISTICS inside each BYOL database to see which options and packs have been used, then match the result to your entitlements.
• Spend and unit. Cost Analysis under Billing and Cost Management breaks consumption down by service and SKU, which shows whether you are paying for OCPUs or ECPUs.
• Rewards balance. The Support Rewards page under Billing and Cost Management shows accrued, applied and expiring rewards.
• Support status. Your support renewal schedule, matched license by license to the BYOL instances.
• On premises overlap. Your deployment inventory for the source servers, to confirm the old installation was removed or shut down.

What have we seen in recent OCI commitment reviews?

Across roughly 30 to 40 OCI commitment and migration reviews we ran between 2024 and 2025 (34 by our count), the main finding held steady. Buyers who chose license included by default overpaid by 20 to 35 percent, with a median of 28 percent, against a clean BYOL position they already owned.

• Oversized commitments. Universal Credits commitments were oversized in nearly two thirds of the deals reviewed. Oracle sized the annual draw to a peak forecast rather than a steady state, and the unused credit expired.
• Options misread. BYOL eligibility was misread on database options in roughly half the positions. Buyers brought the base database license and forgot the service tier they selected bundles options they do not own.
• Wrong document. Teams applied the Authorized Cloud Environments counting rule to OCI in roughly a third of the models we reviewed. It produced both over and under counts.
• Rewards left unclaimed. Support Rewards went unused in most first year migrations. The rebate against the on premises support bill lapsed because no one applied it.

Why we do not default to license included on OCI

The usual account team pitch is that license included on OCI is simpler and removes audit risk, so you should default to it. We disagree. In roughly seven out of ten OCI reviews we modelled in 2024 and 2025, the customer already owned database licenses with active support, which made BYOL cheaper by a wide margin.

The pitch also treats OCI like AWS, where the policy risk is real and contractual protection thin. On OCI the conversion sits in a service description that is part of your order, so the certainty sold at a premium is already yours. Inventory first, elect per workload, and buy license included only for capacity you lack.

On AWS your Oracle licensing is governed by a policy Oracle can rewrite. On OCI it is governed by a service description you signed, and that is the one document you can negotiate.

How should you negotiate an OCI commitment?

Work in four steps and in this order, because each one makes the next cheaper. Our guide to Oracle cloud negotiations expands each step into contract terms.

1. Inventory owned entitlements and support status. List every owned database license, option and management pack with its support renewal date. Nothing downstream holds up without this, and Oracle will build the list for you if you do not.
2. Map each workload to a licensing path. Decide per workload between self managed on OCI Compute, a managed service with BYOL, and license included. A single decision for every workload is always wrong for some of them.
3. Size the commitment to steady state. Set the Universal Credits floor to steady state consumption and buy growth later at rates locked at signature. Expansion pricing agreed at signature is worth more than a headline discount.
4. Apply and reconcile Support Rewards. Apply rewards from month one and reconcile them against the support invoice every quarter. Unclaimed rewards are the most common free money left behind in a first year migration.

What the account team will say, and what to say back

• "License included is simpler and takes audit risk off the table." Reply with your entitlement list and the published ratio for the service. Ask Oracle to price both models for each workload so the premium for simplicity is visible as a number.
• "The discount depends on committing to the three year forecast." Offer the steady state figure and ask for the same rate card on consumption above it. Oracle invoices overage monthly in arrears at the rate card in your order, so the real cost of a lower commitment is any drop in discount tier. Ask Oracle to put that number on paper.
• "Choose High Performance so everything is available." Ask which options that edition exposes that you do not own. Under BYOL, stay on the edition your entitlements support.
• "Database@Azure keeps your Azure licensing rules." It runs on OCI hardware and is licensed as OCI. Ask for the conversion in writing against the service description.
• "Support Rewards will pay your whole support bill." Ask for the model to include your retirement schedule, the 12 month expiry and the pay as you go exclusion.

Contract wording to ask for

A timeline for a first commitment or a renewal

A first commitment usually has no consumption history, so the steady state number rests on your migration plan and should sit toward its low end. At renewal you have real data from Cost Analysis, and the argument for a lower floor is easier to make.

What to do next

1. This month. Export the license type of every OCI database from the Console or the licenseModel field, and list each one against the license and support contract that covers it.
2. Before any model. Establish which unit each service you are buying bills in, OCPU or ECPU, from the current price list rather than the proposal.
3. With the quote. Pull the service description for every service on the quote and read the BYOL clause and the bundled options list.
4. Per workload. Run DBA_FEATURE_USAGE_STATISTICS on each production database before you pick its edition, so the edition matches the options you own.
5. In your model. Delete any calculation that used the Authorized Cloud Environments counting rule. It does not apply to OCI or to Oracle Database@Azure.
6. At sizing. Set the commitment from Cost Analysis history, or from the low end of your migration plan on a first order, and get the expansion rate card in writing.
7. Every quarter. Check the Support Rewards page and apply what has accrued before it reaches the 12 month expiry.
8. Before signature. Bring in independent Oracle advisory while the terms are still open.

Frequently asked questions