Oracle BYOL: Rules and Risks in the Cloud

Oracle is known for the complexity of its licensing, its audits, the high cost of its licenses and associated annual support fees. Maintaining license compliance is critical to avoid large financial risks.

Most organisations have already moved or are planning to move some of their Oracle programs into the cloud. Using existing licences to cover deployments in different clouds (BYOL) is making license compliance even harder.

Existing Oracle licenses, those purchased in the past to cover your on-premises deployments, do allow you to license deployments in different cloud environments. However, different rules apply depending on the cloud provider and the specific contractual terms and conditions in your agreements.

Let’s have a look at a number of different scenarios:

Oracle Cloud Infrastructure and Oracle Compute Cloud @ Customer

Oracle Cloud Infrastructure (OCI) and Oracle Compute Cloud @ Customer are solutions that Oracle is positioning to every single end-user. The rules for determining the number of licenses customers need for these solutions are hidden at the bottom of Oracle’s Processor Core Factor Table (Processor Core Factor Table (oracle.com)).

These rules specify how to convert your existing Processor or Named User Plus licenses into the metric for Oracle’s cloud usage, Oracle Compute Units (OCPUs).

For x86 servers, the following ratio applies:

• Processor license covers use of the product on 2 OCPUs.

Using your Named User Plus licenses (NUP) is possible as long you license the greatest number of a) the actual number of (direct and/or indirect) users and b) the minimum number of Named User Plus licenses per Processor (per 2 OCPU) as applicable for the Oracle program

For example, for programs with a license minimum of 32 NUP licenses per Processor, you must have a minimum of 32 NUP licenses for every two OCPUs of x86.

Some similar rules with different ratios and minima apply to Ampere platform (Altra/Altramax and AmpereOne) and Oracle Ravello.

Specific rules are applicable for licensing Oracle programs with Standard Edition One, Standard Edition or Standard Edition 2 in their names (with some exceptions). In the on-premises world, those programs require you to count each occupied socket and to license it with a Processor license. In Oracle Cloud, one Processor license equals the consumption of four OCPUs. In case you make use of Oracle Database Standard Edition 2 with your Named User plus licenses, you need to comply with a minimum of ten Named User Plus licenses for each instance with up to eight OCPUs.

Approved Cloud Environments

Oracle has agreements with three public cloud providers. The list of providers and the specific rules applicable can be found in the public document called Licensing Oracle Software in the Cloud Computing Environment and include:

• Amazon (EC2 and RDS)
• Microsoft Azure
• Google Cloud Platform (since June 11th, 2024)

Oracle only allows you to license the virtual capacity (instead of licensing the physical capacity) if you make use of one of these four “Authorised Cloud Environments”, apart from licensing programs for Oracle’s own Cloud Infrastructure or Oracle’s Engineered Systems.

For those Authorised Cloud Environments, Oracle require end-users to license the maximum vCPUs of their instances applying the following ratios:

• One (1) Processor license covers two (2) vCPUs if multi-threading is enabled.
• One (1) Processor license covers one (1) vCPU if multi-threading is NOT enabled.

Please note that in all cases, Oracle’s Processor Core Factor is NOT applicable (as it is applicable for on-premises deployments only).

For Oracle programs with Standard Edition One, Standard Edition 2, or Standard Edition in the product name, an instance with up to four (4) vCPUs is considered to be one socket, and it requires one Processor license. A cloud instance with seven or eight vCPUs would require two Processor licenses.

The usual deployment restrictions are applicable as well, but carried over to virtual capacity as Oracle Database Standard Edition may only be deployed on instances with a maximum of 16vCPU (4 Processor licenses), and Oracle Database Standard Edition 2 may only be deployed on instances with a maximum of 8vCPU (2 Processor licenses). In addition, the minimum number of Named User Plus licenses is also applicable (e.g. ten Named User Plus licenses for Oracle Database Standard Edition 2 as a minimum for an instance with 8vCPU)

 

Important Considerations:

As an end-user you should keep several things in mind:

• If you enter into an Oracle Unlimited License Agreement for a limited period, then you may deploy the Oracle programs in Authorised Cloud environments, but your standard terms and conditions will not allow you to certify such deployments at the end of the contract. As an end-user, you would need to negotiate non-standard language in your agreement to be able to certify such cloud deployments.
• If you enter into an Oracle Unlimited License Agreement on a perpetual term (PULA), then you may deploy the Oracle programs in Authorised Cloud environments. You should, however, pay extra attention in case your organisation evolves (e.g. as a result of divestitures, mergers and/or acquisitions) because the standard terms and conditions will only allow those legal entities that are listed in the agreement to be allowed to make use of the software.
• If you make use of “Constrained vCPUs” (Azure) and/or “Optimised vCPUs” (AWS) instances, you should keep in mind that Oracle requires you to count the maximum capacity of the instance (in terms of size) and not the maximum size that has ever been used (despite what some cloud providers have said).
• If you make use of AWS for VMware and/or Azure VMware solution, you should keep in mind that these environments are not Authorised Cloud Environments, and as such, counting the number of vCPU to determine the number of Oracle licenses is NOT allowed. Oracle requires end-users to license the complete infrastructure (read: enter into an Unlimited License Agreement) unless specific non-standard language is agreed upon (which is unlikely for most end-users)
• If you use dedicated hosts (bare metal), as offered by AWS and Azure, Oracle requires you to license the maximum number of vCPUs of the underlying physical servers (and not the actual maximum of vCPUs that have been used at any time on the servers). In other words, if the cores of the servers are hyperthreaded, bare metal hosts are to be licensed fully.

Any other cloud environment?

Oracle does not have specific agreements with cloud providers other than the ones listed above.

Oracle does not accept virtualisation, such as VMware or similar, which most other providers rely on, as a method for reducing the number of licenses required. So if a cloud provider is using VMware as the virtualisation technology, then Oracle would require licensing all the cores of all the ESX hosts of the cloud provider. This is because the virtual machine with the Oracle software installed can live migrate from one vCenter to another (unless storage and network isolation has been implemented). In this scenario, end-users in practice would only be able to license such an environment through an (expensive) Unlimited License Agreement to keep the costs acceptable.

Some cloud providers use terminology such as “private cloud” and “bare metal cloud” for some of their offers. Oracle tends to consider those terms as not reliable, as some layer of virtualisation might be implemented without the end-user being aware of it. Those environments are, because of this, treated as any other non-approved public cloud vendor environment.

Deploying in a cloud environment without having complete and accurate insight into the actual license implications typically results in (unforeseen) financial risk. Be prepared, and engage SoftwareONE’s Oracle Advisory Service experts before, during, and after your transformation to the cloud to avoid and save costs!