Oracle BYOL: Using On-Premises Oracle Licenses in OCI, AWS, Azure, and GCP

Oracle BYOL: Using On-Premises Oracle Licenses in OCI, AWS, Azure, and GCP

• OCI: 1 Processor license = 2 OCPUs; fully supported, easiest compliance.
• AWS/Azure/GCP: 1 Processor license = 2 vCPUs (hyper-threaded); Oracle-approved clouds, but limited features (e.g., no RAC).
• Audit risks: Track usage accurately; Oracle frequently audits cloud deployments.
• Cost: BYOL reduces cloud costs by avoiding duplicate licenses; support contracts are required.

Introduction to Oracle BYOL and Its Purpose

Oracle BYOL (Bring Your Own License) is a program that allows organizations to apply their existing on-premises Oracle software licenses to cloud deployments. Essentially, instead of purchasing new licenses in the cloud, you “bring” the licenses you already own. BYOL aims to maximize the value of prior investments in Oracle software and provides flexibility for deploying workloads in the cloud without incurring duplicate licensing costs.

Oracle’s BYOL program offers 100% workload compatibility and license mobility, meaning customers can easily move workloads between on-premises and the cloud​. By leveraging BYOL, companies can accelerate cloud adoption at a lower cost because they avoid paying for Oracle licenses twice (once on-prem and again in the cloud)​. It also helps maintain consistency in licensing across hybrid environments.

In practice, BYOL is supported in Oracle’s own cloud (Oracle Cloud Infrastructure, OCI) and certain third-party clouds. Oracle explicitly permits Bring Your Own License (BYOL) for authorized public cloud providers, enabling IT managers to reuse licenses for databases, middleware, and other Oracle software in these environments.

This article provides an expert-level guide on using Oracle BYOL in Oracle Cloud Infrastructure (OCI) and other third-party clouds, such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

We will explore the specific rules for each environment, including core-to-cloud conversion rates (e.g., how many cloud vCPUs are covered by an on-premises processor license), supportability and certification status, license mobility considerations, audit and compliance risks, and the associated costs. Real-world examples and a comparison table are included to help IT managers plan deployments and remain compliant.

Oracle BYOL in Oracle Cloud Infrastructure (OCI)

Oracle Cloud Infrastructure is Oracle’s preferred environment for customers to use Bring Your Own License (BYOL), as it is purpose-built for Oracle workloads. In OCI, BYOL is straightforward: one Oracle Processor license from on-prem typically covers two OCI compute units (OCPUs)​.

An OCPU in OCI represents one physical core with hyperthreading, which appears as two vCPUs in the instance. This mapping effectively mirrors Oracle’s standard core factor of 0.5 for Intel cores, where two vCPUs = 1 license.

In other words, if you have a license for 1 Oracle processor on-premises, you can deploy up to 2 OCPUs of that product on OCI without needing an additional license. For example, a company with an Oracle Database Enterprise Edition license can launch an OCI database VM with 2 OCPUs (equivalent to two Intel cores or four vCPUs) and cover it with their single on-premises license under BYOL.

OCI’s BYOL support is built into many of Oracle’s cloud services. When provisioning resources like an Oracle Autonomous Database, Oracle Database Cloud Service, or WebLogic Server on OCI, you often have a choice between “License Included” or “BYOL” pricing. Choosing BYOL means you attest you have sufficient licenses, and in exchange, Oracle charges a lower rate for the cloud service since the license cost is not included.

Oracle’s documentation emphasizes that customers can leverage BYOL with full workload compatibility – the same software running on OCI as on-prem – and Oracle guarantees license mobility back and forth​.

This means you can move a license to OCI for a period and later bring it back on-premises if needed, with no penalty or special lengthy assignment term (unlike some vendors who enforce 90-day transfer rules).

Core Conversion and Examples: The core conversion for OCI BYOL is very favorable. One processor license typically corresponds to two OCPUs for most Oracle products on an x86-based OCI infrastructure. Oracle also provides rules for special cases:

• Standard Edition databases: These are licensed per socket on-premises. In OCI, Oracle treats 1 Processor license as covering up to 4 OCPUs for Standard Edition databases​. For instance, Oracle Database Standard Edition 2 (SE2) can be used on an OCI VM with up to 4 OCPUs per license. SE2 is limited to 8 OCPUs per instance, which would consume two licenses​. Named User Plus (NUP) licenses can also be used under Bring Your Own License (BYOL) in OCI by converting them to the equivalent OCPU coverage (e.g., SE2 requires a minimum of 10 NUPs per 8 OCPUs).
• Oracle Autonomous Database services: BYOL can also be applied here. For example, if you have an Oracle Database Enterprise Edition with the Multitenant option licensed on-premises, you can provision an Autonomous Database in a BYOL model on OCI and only pay for cloud compute and storage, since your license covers the database software. Oracle’s Universal Credits Service Description outlines the exact mappings for each service, but the high-level rule remains one license → 2 OCPUs for Enterprise Edition databases and middleware​.

Real-World Deployment Scenario (OCI): Imagine an enterprise running an Oracle WebLogic Server cluster on-premises with four processor licenses. They plan to lift and shift this application to Oracle’s cloud. In OCI, they deploy WebLogic Server on VMs with a total of 8 OCPUs. Using BYOL, their existing 4-processor licenses cover the 8 OCPUs (since one license is required per 2 OCPUs) with no additional license purchase.

They simply ensure their support contracts remain active and report the usage to Oracle. Oracle’s tooling in OCI can help track BYOL usage. For instance, when creating an OCI database, selecting “BYOL” prompts for your license type and confirms that you understand the required licenses, which helps with compliance tracking.

OCI, Oracle’s environment, is fully certified and supported for all Oracle software. Oracle support teams have direct insight into the environment and can assist with any issues. Because OCI is Oracle’s cloud, there’s minimal risk of any hidden licensing traps—the rules are transparent, and Oracle’s sales teams often encourage BYOL to OCI by highlighting cost savings and ease of compliance.

Oracle even offers programs like Oracle Support Rewards, where OCI usage can earn credits toward on-premises support fees, to incentivize customers to move their Oracle workloads to OCI. In summary, OCI provides the most seamless BYOL experience: straightforward core conversion, complete support, and integrated services that recognize your on-prem licenses for immediate cost reduction.

Oracle BYOL in Amazon Web Services (AWS)

AWS is a popular destination for running Oracle databases and applications. Oracle has authorized AWS for Bring Your Own License (BYOL) under certain conditions. Amazon EC2 (Elastic Compute Cloud) and Amazon RDS (Relational Database Service) are the primary AWS services where you might run Oracle software with your licenses:

• EC2 (Infrastructure-as-a-Service): You can launch EC2 virtual machines (instances) with the operating system of your choice (e.g., Oracle Linux, RHEL, Windows) and install Oracle Database, WebLogic, or other Oracle software. Using BYOL on EC2 means you are responsible for licensing that software according to Oracle’s policies.
• RDS for Oracle (Managed DB Service): AWS offers Oracle’s managed database service. RDS has two licensing options: “License Included” (available only for Oracle Standard Edition 2 on RDS) and “Bring Your Own License” (available for Oracle Enterprise Edition and Standard Edition 2)​. In the BYOL model, you use your existing Oracle Database licenses to run an RDS instance, and you must have the appropriate licenses (with Software Update License & Support) for the chosen DB edition and instance size​. Essentially, RDS BYOL shifts the licensing responsibility to you, similar to EC2, while AWS handles the database upkeep.

Core Conversion in AWS: Oracle’s cloud licensing policy defines how to count AWS vCPUs against Oracle licenses. For AWS EC2 or RDS, Oracle considers each set of 2 vCPUs (virtual CPUs) as one processor license, provided that hyper-threading is enabled on the instance​.

Since most AWS instance types have hyper-threading (one AWS vCPU typically corresponds to one hyper-thread on a core), 2 AWS vCPUs equal 1 Oracle processor license for products licensed by CPU. If an instance type has multi-threading disabled (which is uncommon), then one vCPU would count as one license. Notably, Oracle’s standard Core Factor table does not apply in cloud environments​ – the conversion is simplified to vCPUs only, regardless of CPU model.

For Oracle Database Standard Edition (licensed per socket up to certain limits), Oracle’s policy treats up to 4 vCPUs in AWS as equivalent to one socket (one license)​. Each chunk of 4 vCPUs requires an additional Standard Edition license, rounding up to the nearest multiple of 4. Importantly, Standard Edition 2 is limited to instances with a maximum of 8 vCPUs in AWS, due to its 2-socket/16-thread on-premises limit. For example, running Oracle Database SE2 on an AWS instance with eight vCPUs would require two processor licenses (since one license covers four vCPUs) and meet the SE2 size limit. However, trying to run on a 12 vCPU instance would violate licensing rules, as it exceeds the eight vCPUs limit for SE2.

Example – BYOL on EC2: Suppose you want to run Oracle Database Enterprise Edition on an AWS EC2 instance with eight vCPUs (let’s say, an m5.2xlarge instance with eight vCPUs). With hyperthreading, Oracle counts two vCPUs = 1 license. So, for eight vCPUs, you need four processor licenses of Oracle Database Enterprise Edition. If you have four licenses from your on-prem environment, you can assign them to cover this AWS instance. Oracle’s policy document even provides an example: a 4-vCPU AWS instance requires two licenses, because four vCPUs are counted as two processors under BYOL. Following the same logic, eight vCPUs require four licenses, 16 vCPUs require eight licenses, and so on.

Example – BYOL on RDS: If you use Amazon RDS for Oracle in the BYOL model, AWS will ask you to confirm you have licenses for the instance’s vCPU count. For instance, launching an RDS Oracle EE database with four vCPUs requires 2 Oracle EE licenses (BYOL), similar to the EC2 example above. AWS provides guidance to “follow Oracle’s licensing policies for cloud environments” and even points to Oracle’s official policy document​.

When using RDS BYOL, you continue to pay for Oracle support and contact Oracle for any database-specific support needs. In contrast, AWS supports RDS platform operations. AWS and Oracle have a multi-vendor support process to assist customers in BYOL scenarios, so you will receive help from Oracle for database issues, even if the database runs on AWS.

Supportability and Certification on AWS: Oracle includes AWS in its “Authorized Cloud Environments” list, meaning Oracle officially permits and supports the use of licenses there. However, Oracle does not certify AWS’s virtualization platform for all Oracle products.

In practical terms, Oracle will provide support as long as the software runs on a supported operating system (for example, Oracle Database on Oracle Linux or Windows Server on AWS is fine, since those operating systems are certified). The fact that it’s an EC2 VM is generally acceptable.

Oracle’s FAQ with Microsoft (a similar case) states that customers can run supported Oracle software in non-Oracle clouds and still receive support, as Oracle provides license mobility to these environments​. In AWS, there are a few caveats:

• Certain Oracle products or configurations are not supported on third-party clouds. A prime example is Oracle RAC (Real Application Clusters) on Amazon Web Services (AWS) EC2. Oracle’s cloud policy does not list RAC as an allowed option on authorized clouds, effectively disallowing RAC under BYOL on AWS. Moreover, Oracle Support has explicitly stated that they will not support RAC issues on AWS (per MOS Note 2688277.1)​. The workaround for high availability is using Oracle Data Guard or AWS’s multi-AZ RDS features instead of RAC.
• AWS provides features like “AWS Optimized CPUs,” which allow you to disable some vCPUs on an instance to reduce licensing costs. Oracle’s policy requires counting the maximum vCPUs of the instance type, not the number you use. For example, if you use an instance type with eight vCPUs but only activate 4, Oracle still expects you to license for 8 vCPUs because that’s the instance’s capacity. So, IT managers should avoid assuming they can cut licenses by tuning CPU counts—Oracle won’t recognize that reduction unless the instance type is smaller.
• If you use AWS Dedicated Hosts or bare-metal instances to run Oracle, Oracle will treat them similarly: you must license the full physical core capacity​of that host. Every physical core (and its threads) count on an AWS bare metal instance with hyper-threading. In short, the standard rule of two vCPUs = 1 license still applies per core thread.

Real-World Deployment Scenario (AWS): Consider a retail company migrating its Oracle E-Business Suite application stack to AWS. They set up Oracle Database on an EC2 instance (16 vCPUs) and Oracle WebLogic servers on other EC2 instances. The database will require eight processor licenses (for 16 vCPUs), which the company already owns from its on-prem deployment. They use AWS’s License Manager service to track the usage of these licenses across their AWS accounts​, ensuring no more instances are launched than their licenses allow. For the WebLogic middleware (licensed by CPU), they apply the same rule: each EC2’s vCPUs are counted 2-for-1.

The company records AWS instance types, vCPU counts, and corresponding license assignments. In the case of an Oracle audit, they can produce AWS instance reports and demonstrate that they adhered to Oracle’s licensing policy for AWS. They also avoid disallowed configurations, such as RAC, and use Oracle Data Guard on AWS for database failover.

With these practices, they successfully run their workload in AWS under BYOL, taking advantage of AWS’s scalability while remaining compliant with Oracle’s rules.

Oracle BYOL in Microsoft Azure

Microsoft Azure is another major public cloud where Oracle licenses can be used. Oracle and Microsoft have a strategic cloud partnership, and Oracle explicitly “provides license mobility for customers who want to run Oracle software on Microsoft Azure.”​

This means your Oracle licenses are fully portable to Azure, and Oracle will support customers running Oracle software on Azure just as they would on other authorized environments​. In fact, as part of the partnership, Oracle and Microsoft established interoperable cloud capabilities, such as OCI-Azure Interconnect. Still, even if you deploy Oracle products directly on Azure VMs, the Bring Your Own License (BYOL) rules apply similarly to AWS.

Core Conversion in Azure: The Oracle cloud licensing policy uses the same formula for Azure as for AWS. Every two vCPUs in an Azure VM counts as one Oracle processor license, with hyper-threading enabled​. Azure VM sizes typically have hyper-threading (referred to as vCPUs in Azure documentation), so effectively, you again license every two Azure vCPUs as 1.

If an Azure VM has hyper-threading disabled (or uses types where one vCPU equals one core), then one vCPU equals one Oracle license. However, such scenarios are rare. The Oracle Core Factor table is not used for Azure—Oracle doesn’t differentiate between Azure’s Intel or AMD cores; the blanket 2-for-1 rule applies​.

For Standard Edition databases on Azure, the rules mirror AWS:

• Up to 4 vCPUs = 1 Oracle SE processor license​.
• 5–8 vCPUs = 2 licenses, and so on, rounding up in increments of four.
• Oracle Database SE2 is limited to Azure VMs with a maximum of 8 vCPUs. Anything above that would break the SE2 license terms, which limit it to 2 sockets and 16 threads​. SE (older Standard Edition) is limited to 16 vCPUs on Azure, which corresponds to 4 licenses, matching its 4-socket on-premises limit.

Supported Azure Scenarios: You can run Oracle databases on Azure IaaS (Infrastructure-as-a-Service) by deploying an Azure VM (Linux or Windows) and installing the Oracle Database. Microsoft even provides Azure Marketplace images for Oracle Database on Oracle Linux, making it easier to get started.

Oracle WebLogic Server and other middleware can also run on Azure VMs under Bring Your Own License (BYOL). Azure does not offer an Oracle-managed database service similar to AWS RDS. Instead, Oracle and Microsoft introduced Oracle Database@Azure in 2023, which is essentially Oracle-managed databases running on Oracle Exadata hardware within Azure data centers— a specialized case that goes beyond simple Bring Your Own License (BYOL). The customer is responsible for compliance with the standard BYOL on Azure VMs, just like on AWS.

Oracle has published guidance that Oracle software is supported on Microsoft Azure as long as you have valid licenses and support. Oracle’s FAQ confirms that customers can run supported Oracle software on Azure and that Oracle will provide direct support for these Azure deployments, using an Oracle Support account.

From a supportability standpoint, running Oracle Database or WebLogic on an Azure VM with Bring Your Own License (BYOL) is an endorsed scenario. Oracle treats Azure as an authorized cloud environment, which means you only need to license the virtual cores of your Azure instances, not the underlying hardware itself. (Unlike non-authorized clouds, there is no “full host licensing” requirement​.)

Example – BYOL on Azure: Consider a software company migrating its product, which uses Oracle Database and Oracle WebLogic, from on-premises to Azure. They chose an Azure VM size, Standard_E8s_v3, which has eight vCPUs, for the database. Under Oracle’s BYOL policy, they count eight vCPUs as two processor licenses required for Oracle Database Enterprise Edition (EE). They allocate 4 of their existing licenses to cover this.

For WebLogic, suppose they use two Azure VMs, each with four vCPUs, for the application servers. Each 4-vCPU VM counts as 2 processor licenses for WebLogic. Those licenses are available from their on-prem WebLogic deployment, which they now repurpose in Azure.

After migration, they keep the on-prem systems turned off (or repurposed) to ensure they are not using the same licenses concurrently in two places. They can move the licenses back if they ever need to revert to on-premises (license mobility is unrestricted). They also document the Azure VM sizes and maintain proof that their Azure deployment never exceeded their licensed vCPU allowances at any time.

One real-world scenario unique to Azure is running Oracle on Azure as part of a multi-cloud architecture with Oracle Cloud Infrastructure (OCI). Some organizations use the Oracle-Azure Interconnect to run application tiers in Azure connected to an Oracle Autonomous Database in OCI, for example. In that case, the Oracle database might run in OCI (with BYOL or Oracle’s cloud subscription) while the app servers run in Azure with BYOL for WebLogic.

Oracle’s licensing policy differences between OCI and Azure would apply in such a design (we will compare these differences shortly). However, within Azure, BYOL follows the same pattern as AWS – count Azure vCPUs, apply the 2-for-1 rule, and ensure compliance with Oracle’s cloud policy.

Azure-specific considerations: Azure offers VM series with constrained vCPU counts (for example, a VM type where you can limit the active cores to reduce licensing). Like AWS’s case, Oracle requires licensing the maximum possible vCPU count of the VM size, not the running count if constrained​.

So, if you use an Azure VM type with eight vCPUs but limit it to four vCPUs, Oracle still considers it to be eight vCPUs for licensing. Additionally, Azure has an option called Azure VMware Solution (AVS) for running VMware-based workloads.

Note that Oracle does not recognize the Azure VMware Solution as a supported or authorized environment. If you were to run Oracle in AVS, Oracle’s rules would treat it like any other VMware scenario (requiring all physical cores of the ESXi hosts to be licensed, which is typically very costly)​.

The bottom line is to stick with standard Azure VM deployments for Oracle BYOL, which are fully covered by the authorized cloud policy.

Oracle BYOL in Google Cloud Platform (GCP)

Google Cloud Platform has recently been accepted as an authorized environment for Oracle BYOL. Oracle added GCP to its list of authorized public cloud providers in June 2024​. This inclusion means GCP is now on par with AWS and Azure in terms of Oracle’s licensing policy in the cloud. Customers can run Oracle databases and other Oracle software on GCP and apply their existing licenses under BYOL, following the same rules as AWS and Azure.

Core Conversion in GCP: The Oracle policy for authorized clouds is extended to GCP, using the same vCPU counting method: 2 GCP vCPUs equal 1 Oracle processor license (with hyper-threading enabled). GCP’s Compute Engine instances also use vCPUs that correspond to the number of hardware threads.

Thus, if you launch a GCP VM with 8 vCPUs, you need 4 Oracle licenses, just like with AWS or Azure. If you happen to use an instance type or configuration with multi-threading disabled (for example, some specialized Google CPU options), then it would be 1 vCPU = 1 license. Oracle explicitly states that the core factor table doesn’t apply, so the calculation is straightforward for typical cases​.

For Standard Edition Oracle databases on GCP, the policy is identical to AWS and Azure: up to 4 vCPUs = 1 license, 5-8 vCPUs = 2 licenses, and so on. SE2 is capped at 8 vCPUs on GCP (SE at 16 vCPUs). In other words, GCP is fully aligned with the same socket-to-vCPU mapping used in other clouds for Oracle SE licenses.

Deployment Options on GCP: Unlike OCI, AWS, or Azure, Google Cloud doesn’t have a native Oracle-managed database service. So BYOL on GCP usually involves one of two approaches:

• Google Compute Engine VMs: You can create a VM (for example, using a Google-provided image, such as Oracle Linux, or a custom image) and install Oracle Database or other software. This is similar to running Oracle on AWS EC2 or Azure VM.
• Google Bare Metal Solution: Google offers a Bare Metal Solution (BMS) for Oracle, essentially a dedicated bare-metal server hosted in Google’s data center, connected to Google Cloud Platform (GCP) services. This solution was initially designed to accommodate Oracle workloads with strict licensing or performance requirements, such as Oracle RAC, or for customers who did not want to be subject to virtual environment licensing rules. You’re running on physical hardware on a Bare Metal Solution server, so Oracle’s standard on-prem licensing terms apply (with core factors, etc., as appropriate). BMS requires BYOL since Google doesn’t provide Oracle licenses; customers install their own Oracle software on the box. If you use BMS, you would license it like an on-premises deployment (e.g., count physical cores using Oracle’s core factor table). However, now that GCP VMs are an authorized environment, many customers can run Oracle directly on GCP VMs with Bring Your Own License (BYOL), unless they specifically need something like Real Application Clusters (RAC), which might still necessitate Bare Metal.

Support and Certification on GCP: Oracle’s acceptance of GCP as an authorized cloud means that Oracle will permit the use of its licenses there. Still, Oracle’s support position for GCP is similar to AWS and Azure—Oracle will support issues as long as they are related to Oracle software and are reproducible on a supported operating system. No special Oracle-Google support agreement is announced (unlike the Oracle-Microsoft partnership), but being “authorized” implies that Oracle customers running on GCP won’t violate any policies.

Google has documentation on BYOL for certain software and notes that they support customers bringing licenses for software with dedicated hardware requirements (Oracle databases are often cited in this context)​. In practice, as long as you abide by Oracle’s cloud policy for GCP, you should be in good standing for compliance and support. Oracle’s licensing experts note that “Google Cloud is an authorized Oracle cloud provider… BYOL is explicitly allowed for existing Oracle licenses,” with the familiar vCPU counting rules.

Example – BYOL on GCP: A financial services company runs an Oracle analytics database on Google Cloud Platform (GCP). They chose a Compute Engine instance type n2-standard-16 (16 vCPUs). Per Oracle’s policy, that instance would require eight processor licenses of Oracle Database Enterprise Edition (16 vCPUs / 2 = 8 licenses). The firm has a pool of Oracle licenses from its data center, so it allocated 8 to this GCP environment. They install Oracle Database on the GCP VM and apply their license keys (or simply document that it’s a BYOL deployment).

If they used a Bare Metal Solution server with 16 physical cores, they would apply Oracle’s on-premises core factor (for x86, typically 0.5 per core), which also results in needing eight licenses if the server has 16 cores with a factor of 0.5. The difference is that in a VM, they count virtual CPUs directly, whereas in BMS, they count actual cores. The firm opts for a VM to take advantage of the flexibility of cloud VMs and the authorized environment rules. Over time, they monitor the usage; if they scale the instance up, they know to acquire more licenses or reallocate from elsewhere to cover any additional vCPUs.

One consideration on GCP is that Oracle usage on GCP was a gray area before it became an authorized environment. Some companies used Google’s Bare Metal or limited their GCP Oracle deployments to avoid compliance uncertainty. Now, with Oracle’s June 2024 update, GCP is formally authorized​, so the same licensing peace of mind exists as with AWS and Azure.

IT managers should still stay vigilant: ensure that any migration to GCP is communicated to Oracle (especially if you’re in an unlimited license agreement or need to true up licenses) and that the deployment stays within the bounds (for example, not enabling live migration of Oracle VMs across hosts in an unmanaged way that could resemble an unauthorized scenario – though Google’s standard VMs are fine as is).

Comparison of BYOL Across OCI, AWS, Azure, and GCP

The table below compares key aspects of Oracle BYOL in Oracle Cloud (OCI) versus the third-party clouds AWS, Azure, and GCP:

Table Legend: OCPU = Oracle CPU in OCI; vCPU = virtual CPU (thread) in cloud VMs; Authorized Cloud = a cloud recognized by Oracle’s policy for licensing by vCPU. ULA = Unlimited License Agreement.

Oracle’s Licensing Policy Differences: OCI vs Third-Party Clouds

Oracle’s licensing policy has some distinct differences when comparing Oracle’s cloud (OCI) to third-party providers (AWS, Azure, GCP):

• Core Counting and Core Factors: On-premises, Oracle uses a Processor Core Factor table (e.g., Intel x86 cores have a factor of 0.5) to calculate the licenses needed. In OCI and authorized clouds, Oracle essentially incorporates that 0.5 factor by using the two vCPUs = 1 license rule. OCI’s OCPU definition closely matches this (1 OCPU = one physical core = 2 vCPUs), so the conversion is equivalent across OCI and others for typical x86 instances. However, Oracle has additional OCPU mappings for other processor types in OCI, such as Ampere ARM CPUs, with different conversion rates. For instance, Ampere OCPUs may have a different license mapping. Those are specific to OCI service descriptions and not relevant to AWS, Azure, or GCP, which are all x86-based. In general, OCI and third-party clouds follow the rule that one on-premises processor license covers two hardware threads in the cloud, so there is parity in core conversion for Enterprise Edition and most Oracle products.
• Standard Edition Licensing: A subtle difference arises in how Standard Edition is treated. In OCI, Oracle documentation states that 1 1-processor license covers 4 OCPUs for Standard Edition databases​. In AWS, Azure, and GCP, the policy states one license per 4 vCPUs for Standard Edition, which is the same ratio. The limits (e.g., SE2 up to 8 vCPUs) are consistent between OCI and other clouds. So functionally, there isn’t a difference; Oracle simply phrases it in terms of OCPUs vs vCPUs. The key takeaway is that Standard Edition programs are limited to smaller VM sizes (up to 8 vCPUs for SE2) in any cloud, including Oracle Cloud Infrastructure (OCI).
• License Inclusivity: One major difference is that OCI offers “license-included” options for many Oracle services, whereas third-party clouds do not sell Oracle licenses as part of their IaaS offering (the exception being AWS RDS for Oracle SE2). In OCI, if you don’t want to BYOL, you can subscribe to an Oracle Database cloud service and pay an hourly rate that includes the license. In AWS, Azure, and GCP, you typically must bring your own license (BYOL) for Oracle software, except in the niche AWS RDS case. This means OCI gives you a choice: BYOL vs. Oracle-included, whereas on AWS, Azure, and GCP, BYOL is the primary model for Oracle software deployments. This difference isn’t a licensing rule variation, but it affects planning – e.g., if you lack enough licenses, on OCI you could choose to use Oracle’s licenses in the cloud at a higher cost; on AWS, you’d have to acquire more licenses from Oracle or use only Standard Edition on RDS license-included.
• Contractual Terms and Policy Status: Oracle’s Cloud Computing Policy (the document governing AWS, Azure, and GCP use) is a publicly available policy but is not a contractual part of your license agreement. It’s essentially Oracle’s declared policy that allows the virtual core to count on those clouds. In OCI’s case, the mapping of licenses to OCPUs is usually embedded in the Oracle Cloud terms of service or service descriptions. Practically, Oracle adheres to these policies, but IT managers should note that Oracle could technically update the Authorized Cloud policy (as they did to add GCP in 2024) at any time. Always ensure you have the latest policy reference when planning to use​third-party clouds. OCI’s terms are under Oracle’s control, so there’s less ambiguity – when you use BYOL on OCI, it’s clear-cut in Oracle’s documentation and reflected in how OCI billing works.
• Product Availability and Restrictions: Oracle typically allows full feature usage in OCI, whereas other clouds may have restrictions. For example, Oracle Real Application Clusters (RAC) is available in OCI (on Exadata Cloud Service), and customers can use their RAC licenses there. In contrast, as noted, Oracle does not permit RAC under the Authorized Cloud policy on AWS, Azure, or GCP. This is a policy difference – OCI is Oracle’s turf, and they allow RAC. Still, on third-party clouds, Oracle’s license policy effectively forbids it unless you license entire physical hosts, which is impractical in the public cloud. Similarly, Oracle may introduce new features or cloud-only editions, such as Autonomous Database or certain SaaS/PaaS offerings, with no BYOL equivalent in other clouds. OCI is optimized for Oracle software, with all options available. Third-party clouds provide flexibility for mixed workloads, but sometimes at the cost of not being able to use certain Oracle-specific capabilities due to licensing or support limitations.
• Support and Partnerships: Using BYOL in OCI means your support experience is unified through Oracle. In third-party clouds, you may encounter a combination of vendor support (e.g., AWS or Azure for infrastructure issues, Oracle for software issues). Oracle’s partnership with Microsoft has made running Oracle on Azure smoother, with collaborative support and even the possibility of running Oracle Linux and receiving support from both sides​. There is no similar formal partnership with AWS or GCP, although Oracle does support customers on these platforms. From a policy perspective, Oracle has formally acknowledged AWS, Azure, and Google Cloud Platform (GCP) as acceptable. In contrast, any other cloud, such as IBM Cloud, Alibaba Cloud, or a smaller provider, is not covered by a special policy. If a customer runs Oracle on an unauthorized cloud, Oracle could demand licensing of the entire physical environment or refuse to acknowledge soft-partitioning, which is a significant difference (essentially a non-starter without an unlimited license)
  . Thus, the policy difference is binary: OCI and the “Big 3” clouds follow the relaxed virtual-core counting, while other clouds do not. IT managers should plan to stick with OCI, AWS, Azure, or GCP for Oracle’s cloud deployments to take advantage of BYOL legitimately.
• Unlimited License Agreements (ULA) handling: A noteworthy difference in policy involves ULAs. Oracle ULAs are contracts that allow unlimited usage of certain Oracle software for a period, after which you certify usage. Oracle’s policy explicitly states that licenses under a ULA can be used in authorized clouds, including OCI, AWS, Azure, and GCP. Still, you may not include those cloud deployments in your certification at the end of the ULA term​. Suppose you deploy widely in AWS, Azure, or GCP under a ULA. In that case, when it’s time to count your licenses for perpetual certification, Oracle expects you not to count the VMs in those clouds – unless you negotiated an exception. On OCI, however, Oracle might be more lenient (this is not formally documented, but some customers negotiate ULAs that include cloud use). It’s a nuanced area, but essentially, Oracle wants to prevent someone from using a public cloud’s elastic nature to ramp up usage just before ULA certification. BYOL users with ULAs must be cautious and ideally obtain written clarification from Oracle on how cloud use will be counted. This is a difference in how Oracle handles true-ups in OCI compared to others: Oracle is both the cloud provider and licensor in OCI, so such issues can be managed directly with Oracle representatives, whereas in third-party clouds, Oracle relies on audit rights and policy documents.

The core licensing metric (vCPU/OCPU conversions) is largely the same between OCI and the big third-party clouds for Oracle BYOL. The differences lie in feature availability (OCI allows more, for example, RAC), support arrangements, and contractual nuances such as ULA handling and the availability of license-included models.

OCI is generally the path of least resistance for Oracle workloads; Oracle wants customers there, and thus it smooths out licensing. At the same time, AWS, Azure, and GCP offer more freedom to integrate with other technologies without requiring careful compliance management for Oracle licenses.

Risks and Best Practices When Using BYOL (Audits & Compliance)

Using BYOL for Oracle in the cloud offers cost benefits, but it also comes with the responsibility to remain compliant with Oracle’s licensing rules. Oracle is known for its rigorous license audits, and cloud deployments are not exempt from scrutiny.

IT managers must be proactive in managing this risk. Below, we outline common risks and the best practices to mitigate them:

Common BYOL Risks:

• License Miscounting: A major risk is underestimating the number of licenses required for a cloud deployment. If you misunderstand the vCPU-to-license conversion or forget that an instance’s maximum vCPU count must be licensed (even if not fully utilized), you could deploy more Oracle software than your licenses cover. For example, mistakenly counting an eight vCPU instance as needing two licenses instead of 4 would put you out of compliance. Oracle audits can catch these mistakes by examining the metadata of cloud instances.
• Unauthorized Cloud Use: Deploying Oracle in a non-authorized cloud or virtualization environment can lead to significant compliance issues. As noted, if you run Oracle on a provider not covered by Oracle’s cloud policy (or on an unmanaged VMware cluster in a cloud), Oracle might require you to license the provider’s entire physical infrastructure for Oracle. For instance, this scenario can happen inadvertently if a dev team spins up an Oracle VM in a niche cloud or on a platform like Azure VMware Service without approval. The risk is an astronomically high license liability if audited.
• Feature/Option Usage Without Licensing: Oracle software offers many separately licensed options, such as Oracle Database Enterprise Edition options like Partitioning and Advanced Security. In the cloud, enabling features or using enterprise options (especially on an image or managed service) is easy without realizing a license is required. BYOL means you must own licenses for any activated options. For example, an audit might reveal the use of Oracle Advanced Compression in an RDS instance, and Oracle would expect you to have a license for it.
• Non-compliance with BYOL Terms in PaaS: If using Oracle’s PaaS services in OCI under BYOL (like Autonomous Database BYOL), a risk is not having the equivalent license edition or configuration on-prem. For instance, using BYOL for an Autonomous Data Warehouse requires an Oracle Database Enterprise Edition with the appropriate options on-prem. Using BYOL beyond what your license entitlements allow (such as using Exadata-size shapes with only standard DB licenses) would be non-compliant.
• Audit Trail and Usage Data: In on-prem environments, usage is relatively static and within your control. In the cloud, resources can be spun up and down dynamically. This elasticity can complicate tracking – for example, if an Oracle VM was scaled up for a week and then scaled back down, you need to account for that peak usage in your licensing. Oracle’s audit could request cloud provider logs or other evidence of historical maximum usage. A lack of proper tracking is a risk, as you may overlook a period of non-compliance.
• ULA Trap in the Cloud: As discussed, if you operate under a ULA and deploy in the cloud, thinking it’s “free” usage, you risk not being able to count that usage later, which can result in ending the ULA with fewer licenses than you need in the cloud. This can lead to a costly purchase after the ULA. It’s risky to assume a ULA covers cloud deployment unless explicitly allowed.

Best Practices for BYOL Compliance:

• Understand and Document Policies: Always obtain the latest Oracle licensing policy for cloud environments​ and ensure your team understands the core conversion rules and product-specific limits. Document how these rules apply to your chosen cloud instances (e.g., create an internal wiki: “For AWS m5.4xlarge (16 vCPU) = 8 Oracle licenses needed”). Keep Oracle’s policy document and any Oracle communications (such as Oracle reps confirming something in writing) in your records.
• Inventory and Tagging: Maintain an inventory of all Oracle software’s cloud instances. Tag these resources in your cloud account (e.g., tag instances Oracle=Yes and record how many licenses are assigned). Cloud providers offer tagging and even specific license tracking services, such as AWS License Manager, Azure Monitor with custom tags, and GCP labels. Use these services to quickly identify all Oracle BYOL deployments.
• Use License Management Tools: Leverage tools to monitor license usage:
  • In AWS, AWS License Manager is used to track Oracle license consumption across accounts​. You can set up rules that map instance types to license counts and receive alerts for non-compliance.
  • In Azure, consider Azure’s built-in reporting or third-party tools that integrate with Azure Resource Graph to list all VMs and their vCPU counts. Microsoft’s Cloud Adoption Framework for Oracle on Azure also suggests methods to track licenses.
  • Oracle LMS (License Management Services) and third-party license management firms offer tools that can connect to cloud APIs to continuously audit Oracle usage. Using such tools or services can help prevent audit findings by catching issues early.
• Architect with Compliance in Mind: When designing cloud architecture for Oracle workloads, bake in licensing considerations:
  • Prefer authorized instance types and services. To stay within allowed configurations, choose single-instance database setups over RAC in AWS or Azure.
  • Avoid clouds or services where license tracking is difficult. For instance, containerized Oracle deployments (e.g., running Oracle Database in Docker on Kubernetes) can be challenging. If you do so, consider using Oracle’s own Kubernetes operator or sticking to single-node deployments to avoid inadvertently spreading across hosts.
  • If you need high availability, use approaches such as Data Guard, Active Data Guard (if licensed), or cloud-native HA features (e.g., AWS Multi-AZ) instead of unsupported clustering.
• Stay Within Bounds (No Over-Provisioning): Don’t temporarily provision a larger VM or more vCPUs than you have licenses for. If you must temporarily scale up (say for a batch job), ensure you have spare licenses available or immediately decommission extra capacity within 10 days (Oracle’s contracts often have a 10-day rule for temporary spike on certain license types, though not officially for database – but in practice, short bursts might be argued if not persistent). The safest route is never exceeding your licensed core count at any time.
• Maintain Support Contracts: BYOL requires you to maintain your Oracle Support agreement for the licenses used in the cloud. This ensures you remain technically compliant (right to upgrades, patches) and is crucial for getting help. If support has lapsed during an audit, Oracle might retroactively bill for that or worse. Additionally, with active support, you can log issues with Oracle, even for cloud-deployed systems, and get patches for them.
• Audit Readiness: Conduct periodic internal audits. Simulate an Oracle audit by gathering evidence of your cloud deployments:
  • Take screenshots or exports of cloud dashboards showing each Oracle VM’s vCPU count.
  • Keep records of when each instance was started and stopped. Many compliance teams use monthly snapshots of usage.
  • Ensure you have a paper trail of license purchases (entitlement documents) and support renewal forms, so you can quickly show auditors that you own X licenses and are using them in the cloud.
  • If using a ULA or a pool of licenses, clearly allocate the pool to different environments (e.g., 20 licenses allocated to AWS production, 10 to Azure DR, etc.) out of a total of 30 licenses.
• Engage Oracle and Experts Proactively: If in doubt, engage Oracle License Management Services (LMS) or a third-party Oracle licensing expert before making a big cloud move. Sometimes, Oracle may offer a contractual amendment or cloud-specific clause if you negotiate, especially for large enterprise agreements. Independent advisors (like Redress Compliance) can also assess your cloud licensing stance​ . This can be invaluable in avoiding pitfalls that others have learned the hard way.
• Graceful Exits and Entries: When moving a license between on-prem and cloud, do it cleanly:
  • For example, if you plan to migrate an Oracle DB to AWS, consider decommissioning or archiving the on-prem instance at the cutover time and note the date. That way, if you are later questioned, you can show that from that date onward, the license is used in AWS instead of on-premises, not concurrently in both.
  • Similarly, if you burst a workload to the cloud for testing while keeping on-prem alive, ensure you have extra licenses or terminate the test within a short, allowable timeframe.
  • Use Oracle’s concept of Licensing Rules for Disaster Recovery, if applicable. Oracle offers some leniency for standby databases, etc. If you use the cloud as disaster recovery (DR) for on-premises or vice versa, be sure to follow those rules (e.g., a passive standby in the cloud might not require a full license if it’s truly idle and meets the Data Recovery Licensing policy).
• Stay Up to Date with Policy Changes: Oracle’s cloud licensing landscape can evolve. For instance, GCP’s addition in 2024 was a significant change​. Oracle could adjust terms or add new authorized environments. Always review Oracle’s official communications or ask your Oracle representative annually about any changes to the BYOL policy for the cloud. Align your compliance strategy with the latest rules.

By adhering to these best practices, you can confidently leverage Oracle BYOL in OCI, AWS, Azure, or GCP while minimizing the risk of an audit surprise. The key is vigilance and documentation—know your licenses and cloud usage and match them precisely.

With careful management, BYOL allows you to enjoy cloud scalability and agility for Oracle workloads without incurring the wrath of Oracle’s licensing auditors, all while maximizing the ROI of your existing licenses.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit