Oracle Cloud at Customer Licensing Guide: BYOL, OCPU Rules and Cost Optimisation

The Two Oracle Cloud at Customer Licensing Models

All Oracle Cloud at Customer deployments — Exadata Cloud@Customer, Compute Cloud@Customer, and the Dedicated Region — offer two fundamental licensing approaches: Licence Included and Bring Your Own Licence (BYOL). Choosing between them correctly is one of the most financially consequential decisions in any Oracle Cloud at Customer deployment.

Licence Included (LI)

Under the Licence Included model, the Oracle software stack — Oracle Database, Oracle Database options, and associated middleware — is bundled into the Cloud at Customer service subscription fee. The customer pays a single per-OCPU-hour rate that encompasses both the infrastructure and the Oracle software licence. No existing Oracle licences are required, and no separate Oracle support fee is charged for the software running under the LI model.

Licence Included pricing is Oracle's preferred selling model because it creates a clean new revenue stream without requiring any analysis of the customer's existing licence estate. Oracle's list price for Licence Included Oracle Database Enterprise Edition on Exadata Cloud@Customer is approximately $1.344 per OCPU-hour, compared to a BYOL rate of approximately $0.448 per OCPU-hour for the same service — a premium of approximately 200 percent for the licence component. At enterprise consumption volumes, this difference compounds to millions of dollars annually.

Licence Included is genuinely appropriate in specific scenarios: organisations that have no existing Oracle Database licences (greenfield deployments), organisations that have terminated on-premises Oracle support and need a fully managed path back to Oracle Database without reinstating support, and smaller workloads where the simplicity of a single per-consumption rate outweighs the economics of maintaining an on-premises licence estate.

Bring Your Own Licence (BYOL)

Under the BYOL model, the customer applies existing perpetual Oracle software licences to the Cloud at Customer deployment. The customer pays only for the infrastructure and platform layer — Oracle charges a significantly lower per-OCPU-hour rate that excludes the software licence component. The customer's existing Oracle licences and active support contracts remain valid and are applied against the Cloud at Customer deployment.

BYOL delivers the lowest total cost of Oracle Cloud at Customer for enterprises with significant existing Oracle Database licence estates. The economics are most compelling when the existing licences are under-utilised on-premises — applying the same licence investment to Oracle-managed cloud infrastructure eliminates the need to purchase new cloud licences while maintaining the on-premises licence asset for potential future use or redeployment.

BYOL requires that existing Oracle support contracts remain active. Oracle support fees increase by 8 percent annually, so the cost of maintaining active support for BYOL licences must be modelled over the Cloud at Customer contract term to calculate the true BYOL total cost of ownership. Support fees that have been allowed to lapse cannot be reinstated without paying all back-support and reinstatement penalties.

OCPU Counting on Oracle Cloud at Customer

Oracle measures and charges for software consumption on Cloud at Customer in Oracle Compute Units (OCPUs). Understanding how OCPU counting works — and how it maps to on-premises processor licence requirements — is fundamental to managing Cloud at Customer licence obligations correctly.

The OCPU to Processor Licence Mapping

On Oracle Cloud at Customer, one OCPU equals one Oracle processor licence. This is a significantly more favourable counting rule than the equivalent on-premises counting for Intel or AMD servers, where Oracle applies a 0.5 core factor, meaning two physical cores require one processor licence. On Cloud at Customer, each OCPU provisioned requires exactly one Oracle processor licence under BYOL — there is no core factor applied.

For enterprises migrating workloads from VMware or physical server environments to Oracle Cloud at Customer, this OCPU-to-licence ratio can represent a meaningful reduction in licensing requirements. A workload running on a physical server with 32 Intel cores (requiring 16 processor licences at the 0.5 core factor) migrated to 16 OCPUs on Exadata Cloud@Customer requires 16 processor licences under BYOL — the same count. However, the workload's actual performance on Exadata OCPUs may be dramatically higher than on the equivalent core count on a general-purpose server, meaning fewer OCPUs may be needed to support the same workload.

Named User Plus on Cloud at Customer

Oracle's Named User Plus (NUP) metric can also be used for BYOL on Cloud at Customer, subject to minimum NUP-per-processor requirements. For Oracle Database Enterprise Edition, the minimum is 25 NUP per processor (or per OCPU on Cloud at Customer). For NUP-licensed deployments, the minimum per-OCPU count must be maintained regardless of actual user numbers, which can make NUP licensing more expensive than processor licensing for high-utilisation databases on Cloud at Customer.

For most Cloud at Customer deployments, processor (OCPU-based) licensing is the appropriate metric. NUP is typically only cost-effective when the total user population is small relative to the processor count — a scenario that is rare in production Cloud at Customer environments.

Concurrent OCPU Management

On Exadata Cloud@Customer, database workloads are measured by the OCPUs actively consuming database resources at any given time, not the total OCPUs provisioned to the Exadata system. This means that customers can provision database services with higher OCPU limits than their BYOL licence count, as long as actual concurrent consumption stays within licensed limits. Oracle's LMS monitoring tools track peak concurrent OCPU usage, and compliance is measured against peak consumption rather than provisioned capacity.

This creates a compliance management requirement: enterprises must monitor and manage peak OCPU consumption actively, rather than simply counting provisioned database instances. Autonomous Database on Exadata Cloud@Customer manages OCPU scaling automatically, which can cause unexpected licence consumption spikes if peak consumption limits are not explicitly configured.

Database Options and Management Packs on Cloud at Customer

One of the most commercially significant Oracle Cloud at Customer licensing topics is the treatment of Oracle Database options and management packs — features that are separately licensed from the Oracle Database Enterprise Edition base product on-premises, and that carry the same separate licensing requirements on Cloud at Customer.

Options and Packs That Require Separate Licensing

The following Oracle Database features are separately licensed options that are not included in the Oracle Database Enterprise Edition base licence or the Exadata Cloud@Customer infrastructure subscription. Their use on Cloud at Customer under the BYOL model requires that the customer owns the corresponding option licences with active support, or pays separately for them:

• Real Application Clusters (RAC): Required for multi-node database clustering. Each node in a RAC cluster requires RAC licences in addition to Database EE licences.
• Partitioning: Used for table and index partitioning in large databases. A frequently auto-enabled feature that creates retroactive compliance risk if not explicitly licensed.
• Advanced Security (TDE): Required for Transparent Data Encryption. TDE is increasingly activated as a default security practice, creating widespread accidental activation.
• In-Memory Database: Provides the in-memory column store. Enabled via a database parameter and frequently activated without a formal licensing decision.
• Advanced Compression: Required for data compression features. Activating any compression beyond basic table compression triggers this requirement.
• Diagnostics and Tuning Pack: Required to use AWR reports, ADDM, SQL Tuning Advisor, and related performance diagnostic tools. Frequently used by DBAs without awareness of the licensing requirement.
• Database Vault: Required for access control and privilege management features.
• Label Security: Required for row-level security based on data classification labels.

Autonomous Database and Options

Oracle's Autonomous Database service on Exadata Cloud@Customer includes all Oracle Database options within its service pricing — when using Autonomous Database under the Licence Included model, no separate options licences are required. However, under the BYOL model for Autonomous Database, the customer must own the full suite of Database options that Autonomous Database uses, including RAC, Partitioning, Advanced Security, In-Memory, Diagnostics and Tuning Pack, and Advanced Compression. The Autonomous Database BYOL discount (approximately 50 percent of the LI rate) is only available if the customer owns all required option licences with active support.

This Autonomous Database BYOL options requirement is frequently misunderstood and creates a compliance exposure for customers who believe they are entitled to BYOL discounts but do not hold all required option licences. An independent licence review before committing to Autonomous Database BYOL is essential.

Support Obligations Under Cloud at Customer

Oracle support fee management is one of the most financially significant aspects of Oracle Cloud at Customer licensing. Understanding how support obligations interact with Cloud at Customer subscriptions prevents costly surprises over the contract term.

BYOL Support Requirements

Under BYOL, the customer must maintain active Oracle support for all licences applied to the Cloud at Customer deployment. Oracle support fees increase by 8 percent every year on the renewal date unless explicitly negotiated otherwise. Over a five-year Dedicated Region commitment, uncapped 8 percent annual increases on the support base compound to approximately 47 percent above the starting support cost — meaning that a $2 million support base in year one reaches approximately $2.94 million by year five if no cap is negotiated.

CIOs should negotiate a support cost cap as part of any Cloud at Customer commercial agreement. Oracle's commercial teams resist support caps but will agree to them for sufficiently large or strategic commitments. A typical negotiated outcome is a cap of 0 to 3 percent annual increase on support fees, compared to the standard 8 percent, representing a meaningful long-term saving on the total cost of Cloud at Customer ownership.

Support Rewards on Cloud at Customer

Oracle's Support Rewards programme applies to Cloud at Customer deployments, providing credits against on-premises Oracle support fees based on Cloud at Customer consumption. For every $1 spent on qualifying Cloud at Customer services, Oracle credits $0.25 against Oracle support fees ($0.33 for customers with active ULA or PULA agreements). These credits accumulate in the customer's Oracle account and are applied against the next support renewal invoice.

Support Rewards do not reduce the 8 percent annual support increase — support fees increase each year, and then the rewards credit is applied against the increased amount. The net effect is a reduction in the cash outflow for support, but not a reduction in the contractual support base used to calculate future year increases.

Support for Retired Products on Cloud at Customer

When workloads are migrated from on-premises to Cloud at Customer under the Licence Included model, the corresponding on-premises Oracle Database licences may no longer be actively used. Oracle does not automatically reduce support fees when licences are migrated to LI on Cloud at Customer — the support fee for the on-premises licences continues unless the licences are formally terminated. Terminating on-premises licences when migrating to LI Cloud at Customer eliminates the double-payment for the same software, but also eliminates the option to move back to on-premises deployment at a later date without purchasing new licences or reinstating support.

Licence Portability and Exit Rights

Oracle Cloud at Customer is marketed as providing the benefits of on-premises deployment with Oracle Cloud management — but licence portability and exit mechanics require careful contractual attention.

BYOL Licence Portability

Oracle BYOL licences used on Cloud at Customer are the same perpetual licences as used on-premises. When a Cloud at Customer deployment ends, those BYOL licences remain valid and can be redeployed to any licensed environment: another on-premises server, a different Cloud at Customer system, or an authorised public cloud deployment. BYOL provides genuine licence portability that Licence Included does not.

Under LI, all software rights terminate with the Cloud at Customer service subscription. There is no perpetual licence entitlement — ending the LI subscription ends the right to run Oracle Database on that workload. Organisations that anticipate needing the flexibility to migrate away from Oracle Cloud at Customer should strongly prefer BYOL to preserve their software asset.

Contract Exit Mechanics

Oracle Cloud at Customer contracts are structured as multi-year service agreements with limited exit provisions. Oracle's standard terms do not provide for-convenience termination rights within the committed term. CIOs should negotiate specific exit provisions before signing: the right to terminate with defined notice in specific circumstances (regulatory changes, Oracle material breach, force majeure), data portability obligations, and Oracle's obligations to assist with migration and data extraction if the relationship ends.

Without explicit data portability and migration assistance provisions in the contract, customers in a Cloud at Customer exit are dependent on Oracle's goodwill to recover their data and workloads from Oracle-managed infrastructure located in their own facility. This is a leverage position Oracle can exploit in renewal negotiations.

BYOL vs Licence Included: Decision Framework

The decision between BYOL and Licence Included is best made on the basis of a total cost of ownership model that incorporates all relevant variables: existing licence estate value and coverage, current support cost trajectory, planned consumption volumes, contract term length, and anticipated workload growth.

BYOL is typically the better economic choice for organisations with: large existing Oracle Database EE licence estates with active support; workloads requiring Oracle Database options already owned; long Cloud at Customer contract terms (five years or more) where support savings accumulate significantly; and strategic intent to maintain Oracle Database as a core platform, making licence asset preservation valuable.

Licence Included is typically appropriate for: greenfield Oracle Cloud at Customer deployments with no existing licence estate; organisations migrating away from on-premises Oracle toward full cloud management and seeking a clean break from on-premises support obligations; small or temporary workloads where the analysis overhead of BYOL licence matching exceeds the cost saving; and Autonomous Database workloads where the simplicity of LI pricing avoids the complex options licence requirements of Autonomous Database BYOL.

Many enterprise Cloud at Customer deployments ultimately use a hybrid model — BYOL for core production database workloads where existing licences provide cost advantage, and LI for Autonomous Database or new workloads where option licence coverage is incomplete. The optimal mix requires detailed analysis of the specific licence estate and workload profile.