Oracle software licensing in a cloud computing environment works as follows:
- Coverage: For GCP, AWS, and Azure.
- vCPU Counting: For AWS, GCP, and Azure, two vCPUs equal one Oracle CPU license if multi-threading is enabled; otherwise, one vCPU equals one Oracle Processor license.
- Cloud Licensing Calculation: The Processor Core Factor Table is not used. Licensing is based on instance size.
- Standard Edition Limitations: Oracle DB SE is limited to 16 AWS/Azure/GCP vCPUs. Up to eight Amazon, GCP, or Azure vCPUs are allowed for SE1 and SE2.
Oracle Licensing in Cloud Environments: A CIO’s Advisory Guide
Oracle software is a cornerstone for many enterprise applications, but licensing it in cloud environments presents unique challenges.
Unlike straightforward on-premises models, cloud deployments introduce new rules and potential pitfalls.
Oracle’s licensing policies in the cloud can be complex and ever-evolving, with significant financial implications for non-compliance.
CIOs planning cloud migrations or hybrid architectures must carefully navigate these rules to avoid unbudgeted costs and compliance audits.
This guide offers a comprehensive, globally applicable overview of Oracle licensing in public, private, and hybrid clouds.
Oracle’s Official Cloud Licensing Policies (Authorized vs. Unauthorized Clouds)
Oracle has formalized specific policies for licensing its software in certain public cloud environments, distinguishing between authorized cloud providers and all others.
In Oracle’s terminology, “Authorized Cloud Environments” are cloud providers with which Oracle has established explicit licensing rules for virtualized instances.
As of 2024, this list includes Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
Oracle’s policy document “Licensing Oracle Software in the Cloud Computing Environment” outlines how customers must count licenses on these authorized clouds.
Key rules in authorized clouds: For Oracle products licensed by processor (e.g., Database Enterprise Edition), Oracle permits using virtual CPUs (vCPUs) rather than physical cores as the basis for licensing.
If the cloud instance has hyper-threading enabled (as is common), each two vCPUs counts as 1 Oracle Processor license.
If hyper-threading is disabled, one vCPU counts as one license. Importantly, Oracle’s usual on-premises Core Factor Table (which gives a 0.5 multiplier for Intel cores, for example) does not apply in these cloud environments – the vCPU mapping is fixed regardless of underlying chip model.
For example, an AWS EC2 VM with eight vCPUs (and hyper-threading on) would require 4 Oracle processor licenses (because eight vCPUs / 2 = 4).
A smaller instance with one vCPU would require one license (always round up – fractional licenses are not allowed).
For Oracle’s Standard Edition (SE) databases, which are traditionally licensed per processor socket, the policy provides a similar mapping: an instance with up to 4 vCPUs counts as one socket (needing one SE processor license).
If an instance has more than four vCPUs, every increment of 4 vCPUs counts as an additional socket. For example, a VM with six vCPUs in Azure would be considered two sockets (rounded up from 1.5), thus requiring 2 Standard Edition licenses.
Oracle also caps the size of instances on which certain SE versions can run in the cloud. Standard Edition 2 (SE2) can be licensed on instances with up to 8 vCPUs (beyond that, Oracle requires an upgrade to Enterprise Edition), and older Standard Edition can be licensed on instances with up to 16 vCPUs.
These limits mirror on-prem rules that restrict SE deployment on larger hardware. Named User Plus (NUP) licensing, if used in the cloud, follows the same vCPU-to-processor mapping to determine how many NUP licenses are needed (with Oracle’s standard minimums, e.g., 25 NUP per processor for Enterprise Edition, 10 NUP per 8 vCPUs for SE2, etc., still in effect).
“Unauthorized” cloud environments:
Any cloud provider or infrastructure not covered by Oracle’s authorized list (and not Oracle’s cloud) is considered outside these special rules.
In such cases, Oracle’s standard licensing terms apply without cloud-specific concessions.
You may have to license Oracle software as if it were running on physical on-premises hardware.
Every visible processor core (or vCPU) in use must be accounted for under your licenses, and Oracle’s usual policies on virtualization come into play.
Oracle generally does not recognize most third-party virtualization or cloud platform limits as a means to reduce licensing in these environments.
In effect, if Oracle is running on an unauthorized cloud or an unapproved virtualized setup, Oracle can require licensing of the entire underlying physical server or even the whole cluster if there’s a possibility that the Oracle workload could move around.
For example, deploying Oracle on a cloud provider that uses VMware virtualization (common in some private or regional clouds) could obligate you to license all physical host cores in the cluster, since Oracle views VMware (without hard partitioning) as “soft partitioning” that doesn’t restrict potential usage.
This worst-case scenario often means one Oracle Processor license per vCPU, or even needing an Unlimited License Agreement (ULA) if the environment is large and dynamic, making unauthorized clouds significantly more costly and risky for Oracle workloads.
Oracle provides no built-in license relief in these cases; the onus is on the customer to either negotiate special terms with Oracle or avoid such environments for Oracle software, unless necessary.
It’s also worth noting that Oracle’s cloud licensing policy is a public guideline but not explicitly part of your contract unless referenced. Oracle reserves the right to update or withdraw these policies at its discretion.
In recent years, Oracle has indeed updated the authorized cloud list (for instance, adding Google Cloud in 2024).
CIOs should ensure they have the latest policy information and not assume a provider is authorized without confirmation.
When planning a cloud strategy, Oracle’s policy should be treated as the rulebook for compliance in recognized clouds; other environments should be treated with extreme caution or undergo additional legal review.
Recommendations for CIOs:
- Verify Cloud Eligibility: Before deploying Oracle in any cloud, confirm if the provider is on Oracle’s authorized cloud list. Prioritize AWS, Azure, or GCP for Oracle workloads to leverage Oracle’s established cloud licensing rules.
- Apply Official Metrics: Ensure your team understands the vCPU-to-license counting rules for authorized clouds. Incorporate these formulas into architecture decisions (instance sizing, scaling plans) to account for licensing needs from the start.
- Avoid Unapproved Setups: Steer clear of running Oracle on clouds or virtual platforms that Oracle deems “unauthorized” (e.g., unapproved virtualization, such as generic VMware clouds) unless necessary. If it cannot be avoided, engage Oracle or legal counsel to negotiate terms in advance – do not assume you can simply use your licenses there.
- Stay Informed: Treat Oracle’s cloud policy as a living document. Assign someone to monitor Oracle’s licensing updates or partner with a licensing advisor. If Oracle adds or removes authorized providers or changes counting rules, promptly factor these changes into your cloud strategy.
Bring Your Own License (BYOL) and License Portability in the Cloud
One of the primary ways organizations use Oracle software in the cloud is through Bring Your Own License (BYOL).
BYOL means you deploy Oracle products using licenses you’ve already purchased (typically perpetual licenses acquired for on-premises use), rather than buying a new license bundled with a cloud service.
Almost all major cloud providers rely on BYOL for Oracle offerings – with a few exceptions (such as certain Oracle Database services on AWS or Oracle’s cloud service options), there is rarely an “included” Oracle license in cloud subscriptions.
For CIOs, it’s crucial to understand how to effectively leverage existing Oracle entitlements in the cloud and the limits of license portability.
License Portability: In general, Oracle licenses are portable to different environments under the condition that you maintain compliance.
Oracle’s standard license agreement typically ties usage to your organization (legal entity) rather than a specific server or location, allowing deployment on a cloud VM that you control.
No formal “license mobility” program is required (unlike some other vendors) – you simply need to ensure that the cloud deployment does not exceed what you own in licenses and that you abide by any territorial or usage restrictions in your contract.
Moving an Oracle workload from on-premises to cloud (or vice versa) is permitted as long as you don’t use the same license in two places at once.
CIOs should plan a clear transition: e.g., if migrating a database to AWS under BYOL, either decommission the on-prem instance or have sufficient licenses to cover both during any overlap period.
Oracle typically allows licenses to be reassigned to new servers/facilities with minimal formalities. However, some contracts include a clause that licenses can only be reassigned after a certain period (often 30 days) from the last assignment, preventing rapid swapping.
Remember such clauses when automating cloud failovers or multi-cloud mobility for Oracle workloads.
Using BYOL effectively:
When utilizing BYOL in the cloud, you continue to pay Oracle’s annual support fees on those licenses (if you want access to updates and support).
This support cost remains the same, even though the infrastructure has been relocated. The benefit of BYOL is avoiding new license purchases – you maximize the ROI of your existing investments.
For example, suppose you already own 10 Oracle Database Enterprise Edition processor licenses. In that case, you can allocate some or all of them to cloud instances instead of on-prem servers, with no additional license fee to Oracle (beyond support).
Many cloud providers have built-in tooling or guidance for BYOL. AWS, Azure, and GCP all allow customers to indicate they are using existing licenses when deploying Oracle images or services.
Oracle’s cloud (OCI) goes further, providing specific BYOL options at service provisioning time (we’ll discuss OCI separately). It’s important to document which licenses have been moved to which cloud deployments to maintain a clear record for compliance.
License-Included Services vs. BYOL:
Certain cloud services provide Oracle software “license included” as part of the service fee. For instance, Amazon RDS for Oracle offers an option where you pay per hour.
The Oracle Database Standard Edition license is included in that price (AWS has an agreement with Oracle, and you effectively rent the license).
This is convenient if you lack licenses or want to avoid managing them, but the cloud provider’s license surcharge can be high.
Typically, license-included offerings exist only for Oracle Standard Edition (and Oracle Express Edition, free) on third-party clouds—Oracle Enterprise Edition almost always requires BYOL on those platforms.
Microsoft Azure, similarly, has Oracle database images in its marketplace that assume BYOL; there isn’t an Azure-managed Oracle service with an included license (Azure’s approach for managed Oracle databases is via a partnership with Oracle’s cloud, again, BYOL).
ULA and other agreements in the cloud: Many large enterprises operate under an Oracle Unlimited License Agreement (ULA) or other bulk license contracts.
ULAs grant unrestricted use of certain Oracle products for a period (e.g., 3 years), after which you certify your usage, and those deployments become your licensed quantity in the future.
If your organization has a ULA, cloud deployments are generally allowed during the ULA term. Oracle’s policy explicitly states that ULA licenses can be used in authorized clouds.
However, there’s a critical caveat: under standard terms, any Oracle software deployed in a public cloud cannot be counted at the end of the ULA to boost your certification numbers. In other words, you can run Oracle freely on AWS/Azure/GCP under a ULA.
Support and license maintenance: A BYOL strategy only works long-term if you maintain your Oracle support contracts. While technically you could let support lapse and still use the perpetual license in the cloud, you would lose access to updates and security patches. You would be out of compliance with any cloud provider images that require an active support entitlement.
Additionally, running Oracle without production support is risky and often a compliance red flag (Oracle could consider it a breach of license terms depending on the contract).
Therefore, CIOs should budget for ongoing support costs for any licenses they plan to BYOL into the cloud. If cost is a concern, consider reharvesting and retiring unused licenses rather than letting them idle.
For example, if moving off a legacy system frees up some Oracle licenses, those can be reallocated to new cloud projects, thereby avoiding new purchases.
In summary, BYOL in the cloud is a powerful way to optimize costs by leveraging sunk investments, but it requires careful tracking and adherence to Oracle’s rules.
The portability is generally available, but it’s up to the customer to ensure compliance when moving licenses between on-premises and cloud footprints.
Treat your Oracle licenses as a floating pool of assets that need to be consciously assigned to any Oracle deployment, cloud or otherwise, with processes to update those assignments as you spin resources up or down.
Recommendations for CIOs:
- Audit Your License Inventory: Before migrating, take stock of all Oracle licenses your organization owns (by edition, processor count, etc.) and their support status. Determine which ones are available or can be reassigned to cloud projects.
- Maximize BYOL Usage: Use BYOL wherever feasible to avoid new purchases. For instance, prefer deploying Oracle on cloud VMs with your licenses rather than paying extra for license-included cloud database services unless the latter offers clear strategic benefits.
- Track Movements: Implement an internal tracking system for Oracle license allocation. Each time an Oracle workload is moved to the cloud or back on-premises, update the records to reflect where each license is being used. This prevents accidentally “doubling up” usage of a single license in two places.
- Align with Contracts: Review your Oracle license agreements for any clauses related to cloud use or reassignment frequency. If you have a ULA and plan to use the cloud extensively, engage Oracle (or expert advisors) to amend the terms if necessary, so you’re not penalized later.
- Maintain Support: Budget for continued Oracle support on BYOL licenses. Ensure support stays active as long as the software is in the cloud. The support cost is the trade-off for avoiding new license fees, which should be included in cloud vs. on-prem TCO cost projections.
- Evaluate License-Included Options Cautiously: For managed services like AWS RDS, weigh the convenience against the cost. License-included pricing can simplify short-term needs (e.g., development and testing environments or small projects) but is often more expensive over the long term. Use it strategically, not by default, and compare it against the BYOL approach using existing licenses.
Counting Processors and Cores in Cloud Setups
Understanding how Oracle counts processor licenses in various cloud scenarios is crucial for ensuring compliance and optimizing costs.
The cloud introduces virtual CPUs, threads, and instance sizes as factors, which differ from the traditional on-premises counting of physical cores and sockets.
Below, we break down processor/core licensing implications in cloud deployments:
- Enterprise Edition (Processor Licensing): In authorized public clouds (AWS, Azure, GCP), Oracle’s rule of thumb is two vCPUs = 1 license (with hyper-threading on). This aligns with typical Intel x86 infrastructure, where one physical core with hyper-threading appears as two virtual CPUs. For example, a cloud VM with 16 vCPUs (and hyper-threading) would require 8 Oracle processor licenses. If hyper-threading is turned off on a given instance type (or if using a type that doesn’t have it), then the requirement is one license per vCPU. Always round up to the next whole license if the math isn’t an integer. Oracle does not use the core factor reduction in the cloud, so every vCPU is treated uniformly. On-premises, a processor with a 0.5 core factor meant you effectively needed half as many licenses for certain CPUs; in the cloud, Oracle simply gives the flat 2-for-1 deal on vCPUs (which for most modern CPUs is equivalent to the 0.5 factor anyway). If you were benefiting from a more favorable core factor (e.g., some older SPARC CPUs have 0.25), you don’t get that in cloud – virtually all authorized cloud vCPUs are treated like standard x86 cores. In unauthorized clouds or private clouds, if you must count as physical, you would revert to counting physical cores and applying the core factor table from Oracle. However, because you often cannot audit physical cores in someone else’s cloud, Oracle’s likely stance is to demand one license per vCPU in those cases or require dedicated hardware.
- Standard Edition (Socket-based) Licensing: Oracle Standard Edition products (SE, SE1, SE2) utilize a socket-based license metric with specific limitations on the servers they can run on. In a cloud context, Oracle equates several vCPUs to one “socket.” According to the official policy, up to 4 vCPUs correspond to 1 socket. So, an instance with four vCPUs or fewer needs one SE license (covering that single virtual socket). If the instance has 12 vCPUs, that is treated as three sockets (12/4, rounded up), thus 3 SE licenses. However, Oracle enforces an instance size limit for these editions: you cannot license SE2 on an instance larger than eight vCPUs (which would be two sockets) in authorized clouds. If you exceed that (e.g., try to run SE2 on a 16 vCPU VM), you are out of compliance – Oracle expects you to use Enterprise Edition at that scale. Similarly, the older Standard Edition (SE or SE1) was limited to 16 vCPUs in the cloud. Oracle doesn’t want customers circumventing Enterprise Edition licensing by running many Standard Edition instances scaled up beyond those thresholds. For multi-instance architectures, note that the socket count is per instance/VM, not aggregate, but each instance must respect the vCPU cap.
To summarize these nuances, counting Oracle licenses in the cloud revolves around vCPU assignments for authorized clouds, special handling for Standard Edition, and careful consideration of any features or special infrastructure you utilize.
Recommendations for CIOs:
- Bake Licensing into Architecture Decisions: Make Oracle license counting a checkpoint in cloud architecture reviews. For any proposed Oracle deployment, ask “How many licenses will this require under Oracle’s rules?” and consider alternatives (e.g., can we use a smaller instance with fewer vCPUs to stay within a license threshold?).
- Educate Your Cloud Teams: Ensure that cloud engineers understand why launching a 12 vCPU VM for an Oracle database might be significantly more costly (in terms of licensing) than launching an 8 vCPU VM. Little differences (such as hyper-threading settings or instance types) can double license needs. To optimize license usage, provide internal guidelines on which instance types or sizes are preferred for Oracle workloads.
- Leverage Cloud Tools for Right-Sizing: Use cloud provider tools (AWS offers CPU optimization, Azure VM size flexibility, etc.) to match performance needs without overallocation. For example, AWS’s CPU Optimized feature can limit an instance’s vCPUs, but remember Oracle counts the full allocated capacity, not just what you actively use. Thus, choosing an instance type that naturally has the required vCPUs might be better than relying on limiting a larger instance.
- Monitor Feature Usage: Implement checks or regular audits of Oracle feature usage in the cloud. For instance, if someone enables Oracle Advanced Compression or partitioning on a cloud database, flag that and confirm that a license is available. It’s easier to catch and correct such usage early than to explain it in an audit.
- Plan for DR and Testing: If you use cloud for disaster recovery or QA/test clones of production data, incorporate Oracle’s licensing allowances (like the DR 10-day rule or the policy on using Data Guard standby). Ensure these secondary instances are either periodically destroyed or powered off to avoid inadvertently running full-time (which would necessitate licensing). Document the usage pattern to defend it, if needed.
- Consult on Edge Cases: For any atypical deployment (e.g., running Oracle on VMware in a cloud, or using a new cloud service), consult with an independent licensing expert or Oracle itself to clarify how licenses should be counted. Do this before deployment or signing a contract. It’s better to adjust plans than to face a surprise license obligation later because an assumption about “2 vCPUs = one license” did not apply in that scenario.
FAQs
What cloud vendors are covered under Oracle’s cloud licensing policy? The policy covers Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.
How do I count vCPUs for Oracle licensing on AWS, GCP, and Azure? If multi-threading is enabled, count two vCPUs as one Oracle CPU license. If multi-threading is not enabled, count one vCPU as one Oracle Processor license.
Is the Oracle Processor Core Factor Table used in cloud environments? No, it is not used for cloud licensing based on instance size.
What are Oracle DB SE’s limitations in the cloud? It can only be licensed on instances with up to 16 vCPUs on AWS, Azure, or GCP.
What are the licensing limitations for Oracle DB SE1 and SE2? Oracle DB SE1 and SE2 can only be licensed on instances with up to eight vCPUs on AWS, Azure, or GCP. If using the Named User Plus (NUP) metric, you need at least 10 NUP licenses per eight vCPUs.
How do I license Oracle Database Enterprise Edition on Azure with 32 vCPUs? Count each vCPU according to the policy: if multi-threading is enabled, count two vCPUs as one Oracle CPU license. With 32 vCPUs, you need 32 processor licenses.
How do I license Oracle Database Standard Edition 2 on Azure with eight vCPUs? For SE2 on an instance with eight vCPUs, you count four vCPUs as one Oracle CPU license. Thus, you need two processor licenses.
Are Oracle software licensing policies different for Google Cloud? No, the licensing policies for vCPU counting and limitations are the same for Google Cloud as for AWS and Azure.
Can I use the Oracle Processor Core Factor Table for cloud instances? No, the Processor Core Factor Table does not apply to cloud licensing, which depends on the instance size.
What is the vCPU licensing policy for AWS EC2 and RDS? For AWS, if multi-threading is enabled, count two vCPUs as one Oracle CPU license. If not enabled, one vCPU is counted as one Oracle Processor license.
How is vCPU counting handled on Microsoft Azure? For Azure, if multi-threading is enabled, count two vCPUs as one Oracle CPU license. If not enabled, one vCPU is counted as one Oracle Processor license.
Does Google Cloud have specific rules for counting vCPUs? For Google Cloud, the rules are the same: if multi-threading is enabled, count two vCPUs as one Oracle CPU license. If not, count one vCPU as one Oracle Processor license.
What happens if my instance has more than four vCPUs? Instances with more than four vCPUs require one socket for every four vCPUs, rounded up to the nearest multiple of four.
How are instances with fewer than four vCPUs licensed? Instances with four or fewer vCPUs are equivalent to one socket (or Oracle processor license).
What is the minimum NUP requirement for SE2 on AWS and Azure? Using the NUP metric, a minimum of 10 NUP licenses per eight vCPUs is required for Database Standard Edition 2.
