Oracle BYOL: A Comprehensive Guide to Bring Your Own License on OCI, AWS and Azure

What Is Oracle BYOL?

Oracle Bring Your Own License (BYOL) is the mechanism that allows organisations to apply their existing, perpetually licensed Oracle software licences to cloud deployments — on Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP) — without paying the cloud provider a separate software licence fee for Oracle products. In a standard cloud deployment, the cloud provider charges a combined rate covering both the infrastructure (compute, storage) and the Oracle software licence. With BYOL, you pay only for the infrastructure because you are supplying the licence yourself from your on-premises inventory.

BYOL is conceptually straightforward but operationally complex. The rules governing which licences qualify, how many cloud resources a given licence covers, what active support status is required, and how compliance is verified vary by platform and by Oracle product. Getting these mechanics wrong — over-deploying or under-licensing — creates either wasted spend or audit exposure.

Why BYOL Matters in 2026

Several converging trends make Oracle BYOL a strategically important topic in 2025 and 2026. A large number of Oracle Unlimited Licence Agreements (ULAs) are reaching their certification and renewal windows in 2025 and 2026, creating large populations of uncertified perpetual licences that organisations must either certify into their perpetual estate or surrender. Organisations that certify ULA licences gain a perpetual inventory that can immediately be applied to cloud deployments via BYOL, turning what would otherwise be a support cost into a cloud enablement asset.

Simultaneously, Oracle has been raising prices for Licence-Included cloud services and tightening the terms on BYOL eligibility, making a thorough understanding of BYOL mechanics more valuable than ever. The combination of large perpetual licence inventories, rising cloud infrastructure costs, and Oracle's Q4 commercial pressure creates a favourable environment for organisations that approach BYOL with strategic intent rather than tactical improvisation.

How Oracle BYOL Works: Core Mechanics

Understanding BYOL requires grasping several technical and commercial mechanics that govern what you can deploy and where.

Perpetual Licences and Active Support

Only perpetual Oracle licences with active, current support qualify for BYOL. This eligibility requirement has two important implications. First, if your organisation has ever allowed support to lapse on a perpetual Oracle licence, that licence cannot be used for BYOL until support is reinstated — and Oracle charges a reinstatement fee for lapsed support that typically amounts to the cumulative support that would have been paid during the lapse period, at current rates with the 8% annual escalation applied. Second, Oracle increases support fees by 8% per year on all perpetual licences, so the ongoing cost of maintaining BYOL eligibility through active support grows continuously.

The requirement for active support also means that organisations considering third-party support (from providers such as Rimini Street or Spinnaker) for Oracle Database or other technology products must understand that switching to third-party support eliminates BYOL eligibility. Organisations that use third-party support and cloud BYOL simultaneously are in breach of the BYOL conditions.

Licence to OCPU Mapping on OCI

On Oracle Cloud Infrastructure, Oracle Database licences map to OCPUs (Oracle Compute Units) at a defined ratio. The standard mappings are: one Oracle Database Enterprise Edition Processor licence covers two OCPUs of OCI database service. One Oracle Database Standard Edition 2 Processor licence covers four OCPUs of OCI database service. This mapping is more favourable than the equivalent mapping on AWS or Azure, which is one of the primary reasons OCI BYOL produces greater cost savings than BYOL on competing clouds for Oracle Database workloads.

For WebLogic Server, one WebLogic Suite Processor licence covers two OCPUs of OCI WebLogic service. Oracle's OCI BYOL mappings are formally documented in the OCI Licence Manager service and in Oracle's public BYOL policy documentation. These mappings can change when Oracle updates its cloud pricing and licensing policies, so it is important to verify current mappings rather than relying on guidance from previous years.

Oracle Licence Manager

Oracle Cloud Infrastructure provides a free, opt-in service called Licence Manager that enables organisations to register and track BYOL licence usage across OCI. Licence Manager provides a centralised view of Oracle and third-party licences being used across Compute resources, helping ITAM teams maintain visibility into cloud BYOL compliance without manual tracking. Using Licence Manager is strongly recommended for any organisation with significant BYOL deployments on OCI — it provides the compliance documentation that Oracle may request in an audit.

Oracle BYOL on OCI vs AWS vs Azure vs GCP

Oracle BYOL operates differently on each major cloud platform. The rules, economics and compliance obligations vary significantly, and the wrong platform choice for a BYOL deployment can produce materially worse outcomes than the best choice.

BYOL on Oracle Cloud Infrastructure (OCI)

OCI is where Oracle BYOL is most favourable, for several reasons. The licence-to-OCPU mapping for Oracle Database Enterprise Edition (1 licence = 2 OCPUs) is more generous than on AWS or Azure. OCI provides the Oracle Licence Manager tool for free BYOL tracking and compliance documentation. OCI's Support Rewards programme (discussed below) creates a unique financial benefit available only on OCI. Oracle's Dedicated Region Cloud at Customer option allows BYOL deployment in your own data centre with the same OCI pricing structure. For Oracle Database workloads where BYOL savings are a primary consideration, OCI is structurally the most cost-effective platform.

OCI's Autonomous Database services (ATP, ADW, AJD) also support BYOL, allowing organisations to apply existing Oracle Database licences to fully managed, self-patching database services. The BYOL rate for Autonomous Database is approximately 25% of the Licence-Included rate — representing a 75% cost reduction from the baseline cloud database price for organisations with qualifying perpetual licences.

BYOL on AWS

Oracle BYOL on AWS is permitted under Oracle's standard Licence Mobility policy, but with more restrictive terms than on OCI. On AWS Dedicated Hosts and Dedicated Instances, organisations can apply Oracle Processor licences with a standard mapping of one Processor licence per physical CPU core on the dedicated infrastructure. AWS Shared Tenancy (standard EC2 instances) does not qualify for Oracle BYOL under Oracle's standard policy — Oracle requires dedicated infrastructure for BYOL on AWS to ensure the physical processor count is deterministic and auditable.

The requirement for dedicated infrastructure on AWS significantly increases the base infrastructure cost relative to shared tenancy. For many Oracle Database workloads, the infrastructure premium for AWS Dedicated Hosts eliminates or reverses the BYOL savings that appear attractive on paper. Organisations evaluating AWS BYOL must model the actual economics including the Dedicated Host premium, not just the software licence saving.

BYOL on Microsoft Azure

Oracle BYOL on Azure operates under the Azure Hybrid Benefit framework for Oracle products. Azure allows Oracle Database BYOL on dedicated infrastructure (Dedicated Host) with similar mechanics to AWS — one Processor licence per physical core on the dedicated host. Microsoft and Oracle also offer Oracle Database Service for Azure (ODSA), which provides Oracle Database on OCI infrastructure accessible from Azure, enabling a hybrid architecture that benefits from OCI's more favourable BYOL terms while maintaining proximity to Azure application workloads.

For organisations running a predominantly Azure application estate with Oracle Database dependencies, ODSA deserves consideration as it combines Azure proximity with OCI economics for Oracle Database licensing.

BYOL on Google Cloud

Oracle BYOL on Google Cloud Platform follows Oracle's standard Licence Mobility policy, requiring Sole-Tenant Nodes (GCP's equivalent of dedicated infrastructure) for Oracle BYOL deployments. GCP does not offer an equivalent to OCI's Licence Manager, Support Rewards or the OCI-specific BYOL mappings, making GCP generally the least economically favourable platform for Oracle BYOL workloads.

Oracle Support Rewards: The OCI-Exclusive Benefit

Oracle Support Rewards is a programme exclusive to OCI that converts OCI consumption spend into credits that reduce Oracle support fees. It is one of the most financially significant BYOL-adjacent mechanisms available to Oracle customers and is worth understanding in detail.

How Support Rewards Work

For every dollar of eligible OCI consumption, Oracle awards a credit that reduces the organisation's annual Oracle support renewal invoice. Standard customers receive credits at 25 cents per OCI dollar spent (a 25% reward rate). Customers with a current Unlimited Licence Agreement (ULA) receive credits at 33 cents per OCI dollar spent (a 33% reward rate). These credits are applied against Oracle support renewals and can reduce support fees to zero — Oracle will not make cash payments for excess credits, but credits can fully eliminate support bills for the support renewal period in which they are applied.

The Economics of Support Rewards

For a large Oracle customer paying $4 million per year in Oracle support fees, $16 million in annual OCI consumption generates $4 million in Support Rewards credits at the 25% rate — sufficient to eliminate the entire support bill. For a ULA customer, the same outcome requires only $12 million in OCI consumption. This creates a compelling financial case for routing Oracle Database workloads through OCI rather than AWS or Azure, even before the licence-level BYOL savings are calculated.

Support Rewards credits apply to BYOL services on OCI's Universal Credits Model (UCM) rate card, meaning BYOL deployments that are already saving on the software licence component also generate Support Rewards credits on the infrastructure consumption. The compounding effect of BYOL licence savings plus Support Rewards credits makes OCI materially more attractive than competing platforms for Oracle Database workloads.

BYOL Compliance Requirements and Risks

Oracle BYOL offers significant cost savings but carries compliance obligations that must be managed actively. The following risks are the most common sources of BYOL compliance failures.

Active Support Verification

As established above, BYOL eligibility requires active support on every Oracle licence being applied to cloud deployments. Organisations with large perpetual licence inventories — common in enterprises that negotiated ULAs in the 2010s — must verify that every licence being used for BYOL is currently under active support before asserting BYOL status. Oracle's Customer Support Identifier (CSI) system is the authoritative record of support status, and it must be queried rather than assumed.

Licence Count Accuracy

The number of cloud OCPUs, Dedicated Hosts or virtual machines covered by BYOL is mathematically derived from the number of qualifying perpetual licences held with active support. Over-deploying — running more cloud capacity than your licensed position covers — creates the same compliance gap as installing unlicensed software on-premises. BYOL deployments must be actively monitored against the available licence inventory, not set up once and forgotten.

The "Licence in Use On-Premises" Problem

A perpetual Oracle Database licence cannot simultaneously be in use on-premises and applied to a BYOL cloud deployment unless your licence quantity covers both positions. This is the most common BYOL compliance error we encounter: organisations that apply their on-premises licence inventory to cloud BYOL deployments without accounting for the on-premises usage that those licences already cover. A licence in use on a physical production server on-premises is not available for BYOL elsewhere.

Third-Party Support Incompatibility

Organisations that have moved any part of their Oracle estate to third-party support while simultaneously asserting BYOL for those licences in the cloud are in breach of Oracle's BYOL terms. Oracle explicitly requires active Oracle support for BYOL eligibility. Ensure that any licence used for BYOL is under Oracle support, not third-party support.

ULA Certification and BYOL

During an active ULA term, you may not assert BYOL for Oracle Database on cloud platforms unless the ULA explicitly permits cloud deployment. Most older ULAs restrict deployment to on-premises infrastructure, and applying ULA coverage to cloud BYOL without an explicit cloud usage right in the ULA creates compliance exposure. Post-ULA certification, the certified perpetual licences are free from ULA deployment restrictions and can be used for BYOL.

Strategic BYOL Decision Framework

Organisations evaluating BYOL as part of their cloud strategy should work through the following decision framework to identify the highest-value opportunities and avoid the most common errors.

Step 1: Inventory Your Perpetual Oracle Licence Estate

Produce an accurate count of every perpetual Oracle Database, WebLogic, and relevant technology product licence you hold, verified against your Oracle ordering documents (and the Ordering Documents are the authoritative source, not internal spreadsheets or vendor representations). Identify each licence's current support status via Oracle's CSI system.

Step 2: Identify On-Premises Licences Available for BYOL

Subtract from your perpetual licence inventory all licences currently in use on on-premises production, development, test and disaster recovery infrastructure. The remainder represents the licences potentially available for BYOL cloud deployment. In practice, many organisations discover they have more available capacity than they realised after consolidating on-premises workloads onto fewer, more efficiently utilised servers.

Step 3: Model OCI vs AWS vs Azure Economics

For each candidate Oracle workload, model the total cost comparison between OCI BYOL, AWS BYOL (on Dedicated Hosts) and Azure BYOL. Include the OCI Licence Manager overhead, Support Rewards credits for OCI deployments, and the infrastructure premium for dedicated tenancy on AWS and Azure. For Oracle Database workloads, OCI will typically produce the best outcome. For application workloads adjacent to non-Oracle services on AWS or Azure, proximity considerations may justify AWS or Azure BYOL despite the cost disadvantage.

Step 4: Assess Active Support Costs vs BYOL Savings

BYOL requires paying Oracle support fees of approximately 22% of net licence value annually, with 8% annual escalation. For some older perpetual licences — particularly where the software is being replaced rather than extended — the support cost of maintaining BYOL eligibility may exceed the cloud savings that BYOL generates. A licence with a net value of $100,000 costs $22,000 per year in support. If BYOL on that licence saves $15,000 per year in cloud costs, maintaining support purely to enable BYOL is a net negative. This analysis is often overlooked in BYOL planning.

Step 5: Negotiate OCI Commitments to Maximise Support Rewards

OCI annual commit contracts (Universal Credits) generate Support Rewards credits. Structured correctly, a multi-year OCI commitment can generate Support Rewards credits that offset or eliminate Oracle support renewal costs, effectively making the OCI infrastructure partially or fully self-funding through support cost reduction. Oracle's Q4 window (March to May) is the correct time to negotiate OCI commit contracts — Oracle's field teams are motivated to close large OCI commitments in Q4, and both the OCI pricing and the Support Rewards credit rate are negotiable in the context of a significant OCI deal.

ULA Customers and BYOL: A Special Case

Organisations with active or recently certified Unlimited Licence Agreements have specific BYOL considerations that deserve separate treatment.

During the ULA Term

Oracle ULAs typically restrict deployment to the customer's owned or controlled data centre infrastructure. Applying ULA coverage to cloud BYOL deployments generally requires an explicit cloud amendment to the ULA. Without this amendment, cloud deployments do not count toward ULA entitlement and are not covered by ULA licensing. Oracle sales teams will sometimes verbally confirm that ULA covers cloud, but verbal assurances are not enforceable — only written contract language matters.

Post-ULA Certification

At ULA certification (the contractual event where you declare the number of each product you have deployed, and that quantity becomes your perpetual licence grant), the certified licences become standard perpetual licences free from ULA deployment restrictions. These certified licences can immediately be applied to BYOL cloud deployments, making post-ULA certification a major BYOL activation event. Organisations approaching ULA certification should model their BYOL strategy as part of the certification planning process, because the certification quantity decision directly determines how much BYOL capacity they will have available.

Importantly, Oracle support fees on ULA-certified licences are fixed at 22% of the net ULA value and continue with 8% annual escalation. Large certified licence quantities generate large support bills that BYOL cloud savings must justify. The ULA Support Rewards rate of 33% on OCI (versus 25% for standard customers) is one reason Oracle customers with recently certified ULAs find OCI commitments particularly attractive.

The PULA Option

Oracle Perpetual Unlimited Licence Agreements (PULAs) are an alternative to time-limited ULAs that provide unlimited deployment rights for a defined product set indefinitely, in exchange for a fixed annual fee. PULAs do not have certification events and do not produce a discrete perpetual licence inventory in the same way as standard ULAs. PULA holders should review their specific PULA terms before asserting BYOL, as PULA deployment rights are governed by the specific contract language rather than Oracle's standard BYOL policy.

Eight Common BYOL Mistakes to Avoid

1. Applying Lapsed-Support Licences: Only licences with active Oracle support qualify for BYOL. Verify support status via the CSI before any BYOL deployment.

2. Double-Counting On-Premises and Cloud: A licence in use on-premises is not available for BYOL simultaneously. Maintain an accurate licence position that accounts for all active deployments.

3. Using Standard EC2 for Oracle BYOL on AWS: Oracle BYOL on AWS requires Dedicated Hosts or Dedicated Instances. Shared tenancy EC2 instances do not qualify under Oracle's standard policy.

4. Assuming ULA Covers Cloud: Standard ULA terms do not include cloud deployment rights. Obtain written contract language confirming cloud deployment rights before applying ULA coverage to cloud workloads.

5. Mixing Third-Party Support and BYOL: Licences on third-party support do not qualify for Oracle BYOL. Keep BYOL licences under Oracle support.

6. Ignoring Support Costs in BYOL Economics: BYOL requires maintaining Oracle support at 22% annually with 8% escalation. For smaller licence populations, support costs may exceed BYOL savings. Always model net economics.

7. Not Using OCI Licence Manager: For OCI BYOL deployments, Licence Manager provides compliance documentation that Oracle may request in an audit. Not using it creates a compliance evidence gap.

8. Underestimating OCI Support Rewards Value: Support Rewards credits are among the most financially significant BYOL-adjacent mechanisms available on OCI and are often overlooked in BYOL planning. Include them in any OCI vs AWS cost comparison.

Summary: Oracle BYOL Best Practices

Oracle BYOL is one of the most powerful cost levers available to organisations with substantial perpetual Oracle licence inventories. The following summary captures the essential best practices for maximising BYOL value while maintaining compliance.

Maintain active Oracle support on all licences intended for BYOL use. Conduct an accurate perpetual licence inventory before any BYOL deployment, accounting for all existing on-premises usage. Prefer OCI for Oracle Database BYOL workloads to benefit from the favourable OCPU mapping and Support Rewards programme. Model the full economics including support costs, infrastructure premiums and Support Rewards credits — not just the software licence saving. Negotiate OCI annual commits during Oracle's Q4 window (March to May) to maximise both OCI pricing and Support Rewards credit rates. Review ULA terms before applying ULA coverage to cloud workloads, and structure post-ULA certifications to maximise future BYOL capacity. Keep BYOL licences under Oracle support and do not mix with third-party support for the same licence. Use OCI Licence Manager to maintain audit-ready compliance documentation.