Oracle Cloud at Customer Licensing Best Practices
Executive Summary:
This article serves as a guide for CIOs, IT Asset Managers, and compliance officers on effectively managing Oracle Cloud at Customer licenses.
It covers best practices for choosing between BYOL and license-included models, mapping on-premises licenses to Oracle’s cloud metrics, and maintaining compliance to avoid costly pitfalls.
Readers will learn how to optimize license usage for cost efficiency while ensuring compliance with Oracle’s licensing rules in a Cloud@Customer environment, thereby protecting their organization from compliance risks and unforeseen expenses.
Read Read Oracle Cloud at Customer Cost Optimization: Reducing Support Costs and Maximizing Value.
BYOL vs. License-Included: Choosing the Right Model
Oracle Cloud at Customer offers two licensing approaches for software running on the platform:
- Bring Your Own License (BYOL): You use existing Oracle software licenses (Database, Middleware, etc.) on the Cloud@Customer infrastructure. In this model, the cloud service charges are lower because you’re only paying for infrastructure and support (since you “bring” the license). BYOL is ideal if your organization has already invested in Oracle licenses and is paying annual support. It maximizes the value of those sunk costs.
- License-Included (Subscription): Oracle includes the software licenses as part of the Cloud@Customer subscription. You pay a higher rate for compute/database usage, but you don’t need any separate on-prem licenses. This model suits organizations that lack the required licenses or prefer Oracle to handle all licensing and support within the cloud fee.
Key Best Practice: Evaluate each workload to determine which model best fits. Mixing models is possible – for example, use BYOL for an Oracle database if you have spare licenses, but use license-included for a new Autonomous Database deployment where you have no existing license.
This approach minimizes costs by leveraging BYOL where possible and using license-included options only when necessary. Always factor in that BYOL requires you to continue paying support on those licenses (typically ~22% of the license price annually), whereas license-included has that cost built in.
Read Negotiating Oracle Cloud at Customer Contracts: Strategies for CIOs and Procurement.
Mapping On-Premises Licenses to Cloud@Customer Resources
One of the biggest compliance challenges is understanding how traditional Oracle licenses translate to Cloud@Customer usage. Oracle uses cloud-specific units, such as OCPUs (Oracle CPU cores), for billing purposes.
Here’s how to map and manage licenses:
- OCPU to Processor License: Oracle defines 1 OCPU as one physical core with hyper-threading (equivalent to 2 vCPUs). For enterprise products on x86 hardware, one Oracle Processor license covers 2 OCPUs in Cloud@Customer. This mirrors Oracle’s standard policy for cloud (including OCI). For example, if you deploy a database VM using 4 OCPUs, you need two processor licenses of Oracle Database Enterprise Edition to cover it under BYOL.
- Named User Plus (NUP) Licensing: If you use NUP licenses instead of processor licenses, the same minimum user counts apply in the cloud. Typically, Oracle requires 25 Named Users per processor for the Enterprise Edition Database. In Cloud@Customer terms, that means 25 Named Users can cover 2 OCPUs (since 2 OCPUs = 1 processor license worth of entitlement). Ensure you meet minimum NUP counts; if you spin up a small database with, say, 1 OCPU, Oracle still expects at least 25 named user licenses to cover that deployment.
- Standard Edition Databases: Oracle Database Standard Edition 2 (SE2) has different rules. On-prem, SE2 is limited to servers with a maximum of 2 sockets (and 16 total threads). In Cloud@Customer, Oracle treats 1 SE2 processor license as covering up to 4 OCPUs. However, Exadata Cloud@Customer cannot use SE2 because Exadata’s multi-node architecture exceeds the limits of SE2. If you plan to BYOL Standard Edition, you’d need to deploy on a smaller Cloud@Customer configuration (like a single-node Compute Cloud@Customer VM) that meets SE2 restrictions. This is a crucial pitfall: deploying SE2 on an unsupported configuration would break license compliance. Always verify that your cloud setup aligns with the product’s licensing rules.
- Oracle Middleware and Other Products: For middleware like WebLogic Server, the concept is similar. A WebLogic Server Enterprise Edition processor license would cover two OCPUs of WebLogic running on Cloud@Customer. Oracle typically doesn’t meter these at a granular level in your cloud bill (for BYOL, they assume you handle compliance), but you must not exceed your entitlements. Track the number of cores of WebLogic and Oracle DB options (such as Partitioning and Diagnostics Pack usage), etc., that are deployed. All Oracle software features used on Cloud@Customer must be licensed just as if they were on-prem.
A practical approach is to maintain a license mapping document or spreadsheet. List each Cloud@Customer resource (databases, apps) you run, note the peak OCPUs used, and map that to the required licenses. This helps demonstrate compliance at any point in time.
Ensuring Compliance in Cloud@Customer
Cloud@Customer does not eliminate the need for license compliance discipline; in fact, it’s partly on the customer to ensure they’re compliant:
- Active Support Requirement: If you BYOL, Oracle requires that those licenses have active support subscriptions. Using a license in the cloud for which support has lapsed is not allowed. Keep proof of support contracts and stay current on support renewals for any licenses allocated to Cloud@Customer. If you plan to drop support on certain licenses (for cost reasons), you cannot use them in Cloud@Customer – you’d have to switch those workloads to the license-included model instead.
- License Attestation: When configuring services (like an Autonomous Database BYOL) on Cloud@Customer, Oracle may require you to attest that you have sufficient licenses. Be honest and accurate – attestations are subject to verification. Select BYOL only in the cloud portal if you know you have the matching licenses available.
- Internal Audits and Monitoring: Implement internal monitoring of your Cloud@Customer usage. Oracle provides usage metrics (OCPU hours consumed by each service, etc.). Regularly compare these to your entitlements. For example, if a database was scaled from 4 to 8 OCPUs, update your compliance tracking to ensure you now allocate twice the number of processor licenses to that deployment. Periodically (e.g., quarterly) run an internal true-up: reconcile actual usage vs. licenses owned. This practice can catch any drift and let you correct course (by either reducing usage or acquiring additional licenses) before it becomes an issue.
- Stay Informed on Oracle Policy: Oracle’s cloud licensing policies are updated from time to time. Review Oracle’s official Cloud Licensing policy document and Cloud@Customer guidelines annually. For instance, Oracle’s policy notes how many OCPUs a license covers, or any changes for new processor types (if Oracle introduces ARM-based Cloud@Customer, the ratio might differ – e.g., 1 license per 4 OCPUs for Oracle’s ARM chips as in OCI). Staying current ensures your compliance model remains accurate.
Importantly, Oracle can audit Cloud@Customer usage in much the same way as on-premises. While the hardware sits in your data center, Oracle has visibility into what services you have activated (through the cloud control plane).
They might not see your license documents, but they can see OCPU usage and may ask you to demonstrate that you have licenses for BYOL usage. Always be prepared to show that evidence.
Optimizing License Usage and Costs
Good license management not only avoids compliance issues but can save money. Here are the best practices to optimize usage:
- Allocate Licenses to Steady Workloads: Use BYOL for workloads that run 24/7 or are predictable, because you’re already paying support on those licenses—get the most value out of them. For example, if you have an Oracle Database that will run continuously, BYOL allows you to use your perpetual licenses and pay the lower OCPU cloud rate. The support cost remains the same whether you fully utilize the license or not, so maximizing its use yields better ROI.
- Use License-Included for Burst or New Services: For temporary, burst, or experimental workloads, you might consider license-included even if you own some licenses. Example: a 1-month project requiring an extra database – spinning it up with a license-included license (and then shutting it down) might be simpler than reallocating a license for just a month. You’ll pay more per hour, but only for that short period. Conversely, avoid using license-included resources for long-running production if you have spare licenses; that would be a waste of money.
- Rightsize and Reassign Licenses: If a Cloud@Customer database was sized for 8 OCPUs but analysis shows it only uses ~4 regularly, consider scaling it down to 4 OCPUs. Free up those extra licenses to use elsewhere (or reduce your future support spend). Cloud@Customer enables dynamic scaling of resources – utilize this feature to prevent over-licensing. You can always scale up temporarily if needed (ensuring you have licenses ready to allocate).
- Consolidate Workloads to Use Licenses Efficiently: Because the Cloud@Customer environment is under your control, you can consolidate multiple small databases onto one larger Cloud@Customer Exadata system, for instance. This can reduce the total number of OCPUs needed by eliminating redundancies, thereby lowering license requirements. Oracle’s cloud automation (especially on Exadata) can handle many databases on one platform, so take advantage of that to get more mileage from each Processor license.
- Monitor Optional Features: Oracle databases and middleware come with optional packs or features (such as Advanced Security and WebLogic Management Pack). In on-prem environments, it’s easy to accidentally use a feature that wasn’t licensed. On Cloud@Customer, be equally vigilant. If you enable an extra cost feature on an Oracle database cloud service while in BYOL mode, you must have that option licensed on-premises. For cost optimization, disable or avoid features you haven’t licensed. Oracle’s cloud interface might not stop you from using a feature under BYOL – it’s your responsibility.
Each of these strategies aims to strike a balance: you want to fully utilize what you’ve paid for (licenses and support) while avoiding paying for things you don’t need (like unnecessary license-included hours or unused entitlements). The result is a lower effective cost per workload and no compliance surprises.
Common Pitfalls and How to Avoid Them
Even seasoned IT teams can stumble on Oracle’s licensing nuances. Watch out for these common Cloud@Customer pitfalls:
- Deploying Unlicensed Products: Cloud@Customer can run many Oracle products (database, middleware, applications). Ensure you have licenses for everything you deploy. For instance, installing Oracle Middleware or an Oracle analytics product on the Cloud@Customer’s compute nodes without proper licenses would be a compliance violation. Have a process to approve new deployments by the license management team.
- Mixing Metric Mistakes: Perhaps you licensed a database by NUP on-premises and then scaled it up dramatically in Cloud@Customer (where a processor metric might be more appropriate). If user counts don’t scale with usage, you might violate the 25 Named Users per processor rule. Solution: if a system grows, consider converting NUP licenses to processor licenses for simplicity, or ensure you add enough NUP licenses to cover growth. Oracle allows converting metrics (NUP to processor) by purchasing additional licenses to meet the minimum requirements – plan for this if needed.
- Standard Edition on Exadata: As mentioned, using Standard Edition database licenses on an Exadata Cloud@Customer is not recommended. This has tripped up some companies who assumed they could BYOL their cheaper SE2 licenses. Avoid this by planning: if you intend to use Exadata Cloud@Customer, budget for Enterprise Edition licenses or utilize Oracle’s license-included option for the databases.
- Lapsed Support on BYOL: It can be tempting to drop support maintenance to save money once you’re on a cloud subscription. However, remember that BYOL usage requires active support. If you stop paying support on a license, you’ve also lost the legal right to use it in Cloud@Customer. Oracle could audit and back-charge you for those as if they were unlicensed. The better approach if budgets are tight: consider moving that workload to a license-included option (so you can drop the license and support), or negotiate with Oracle as part of a contract (sometimes Oracle will allow a support holiday if you’re moving quickly to the cloud – but get that in writing).
- Assuming Oracle Will “Auto-Fix” Compliance: In Cloud@Customer, Oracle manages infrastructure but not your license compliance (unless it’s license-included, in which case, compliance is built-in). Don’t assume that just because it’s a cloud service, you cannot be out of compliance. Oracle’s automation won’t prevent you from, say, creating ten databases under BYOL with not enough licenses – it’s on you to stay compliant. Always treat cloud deployments with the same level of compliance scrutiny as on-prem.
- Ignoring Changes in Usage: Cloud makes it easy to spin up new instances or add more CPUs. One extra click in the console could double your OCPU usage. It’s a great cloud benefit, but from a licensing perspective, it’s risky if done casually. Mitigate this by setting up governance: require approval for increases in OCPU count or enabling new services. This can be achieved through internal policy or by utilizing Oracle’s cloud administration tools, which restrict access to create specific resources.
Avoiding these pitfalls requires a mix of technical controls, process discipline, and awareness. The cost of a mistake can be high – either a licensing true-up bill or being forced to quickly purchase licenses you didn’t budget for.
Recommendations
- Maintain a License Inventory: Keep a detailed inventory of all Oracle licenses and what Cloud@Customer resources they cover. Update it with every change in deployment.
- Choose the Right Licensing Model per Workload: Analyze each system to determine whether to use BYOL or license-included. Default to BYOL if you have licenses, but don’t force BYOL if it risks compliance or if the workload is truly transient.
- Monitor Cloud Usage Continuously: Use Oracle’s cloud monitoring tools or third-party solutions to track OCPU hours, user counts, and feature usage. Set alerts for unusual spikes that could signal a licensing issue.
- Educate Your Teams: Train your cloud engineers and administrators on the basics of Oracle licensing. If they are familiar with the rules (such as OCPU conversions and feature licensing), they’ll make informed decisions when deploying services.
- Regular Compliance Audits: Conduct internal audits at least annually (if not quarterly). Simulate an Oracle audit by checking usage vs entitlements. It’s better to find and fix an issue yourself than have Oracle find it.
- Leverage Oracle License Management Services (if needed): Oracle offers (and so do third parties) services to help assess compliance in cloud environments. If you’re unsure, consider a compliance health check to validate that you’re on the right track.
- Align with Oracle’s Cloud Policy Document: Always refer to the latest Oracle Cloud Hosting and Delivery Policies or similar documents for exact licensing rules. These are the authoritative sources for how licenses apply in Cloud@Customer.
- Optimize Named User Licensing: If you are using NUP licenses, ensure that your user counts are accurately monitored. If a system’s user base grows, proactively buy additional NUP or convert to processors before falling out of compliance.
- Disable Unused Features: Turn off or do not install Oracle options/packs you haven’t licensed. Many Oracle products allow you to selectively enable features – keep them off by default in your cloud templates.
- Plan for Audits: Even in Cloud@Customer, have an audit response plan in place. Keep documentation of your licenses, support contracts, and cloud usage readily available. If Oracle initiates an audit or license review, you’ll be able to respond confidently and swiftly.
FAQ
Q1: If we use Oracle’s license-included option on Cloud@Customer, do we need to worry about compliance?
A1: Using license-included shifts the compliance burden for those specific services to Oracle (since Oracle is providing the licenses as part of the service). You won’t need to show proof of licenses for license-included usage. However, you should still ensure you only use the services you’re paying for. For example, if you subscribed to 16 OCPUs of Autonomous Database (license-included), you can’t secretly use 32 OCPUs without Oracle knowing – the cloud system will meter that and charge you. Compliance in this case primarily involves not exceeding the contracted amounts. However, you don’t face a traditional compliance audit for license-included parts because it’s essentially a cloud rental model.
Q2: How does Oracle verify BYOL compliance on Cloud@Customer?
A2: Oracle can’t automatically scan your internal license documents, but they have ways to verify. During an audit or contract review, Oracle might request evidence of licenses for the workloads you ran under BYOL. The Cloud@Customer infrastructure reports usage data back to Oracle (like how many OCPUs of each service were used). Oracle can compare that against the licenses you certify to own. They might also audit your support contracts to ensure support was active during usage. Essentially, they trust but verify – trust you to select BYOL honestly, but they retain the right to audit and require proof. Always maintain records (proof of license purchase and support status) for any software you run under BYOL in the cloud.
Q3: We have an Oracle Unlimited License Agreement (ULA). How does Cloud@Customer licensing work in that case?
A3: If you have an active ULA, you are entitled to unlimited use of certain Oracle products (as specified in your ULA), typically in your on-prem environment. The good news: Oracle allows ULA customers to deploy on Oracle Cloud (including Cloud@Customer) under the ULA terms (this should be confirmed in your ULA contract’s cloud clause). This means you can treat Cloud@Customer like an extension of your data center during the ULA period. However, be cautious – when the ULA ends and you have to certify usage, the cloud deployments count towards the limit. You’ll need to declare how many processors/NUPs are being used on Cloud@Customer as part of certification. If you plan to move to Cloud@Customer on a long-term basis, consider renewing or extending the ULA, or converting to regular licenses at the end of the ULA term. In summary, ULAs can be highly cost-effective for Cloud@Customer if implemented at the right time, but careful management of the certification is necessary to avoid shortfalls after it expires.
Q4: Can we switch a workload from BYOL to license-included (or vice versa) after deployment has occurred?
A4: Technically, yes. You could start a database instance as BYOL and later decide you’d rather have Oracle include the license (or if you drop support on that license, you’d need to switch it to license-included to stay compliant). This typically involves some downtime or redeployment because the billing setting for the service needs to change. In practical terms, you’d provision a new instance with the desired model and migrate the data, or work with Oracle support to adjust the instance’s licensing model. It’s not something you’d want to do frequently. From a contract standpoint, ensure your agreement doesn’t forbid switching models. It usually doesn’t, but the cost implications are your responsibility (once you switch to license-included, you’ll start incurring the higher rate). Some customers utilize this flexibility if they decide to discontinue paying for support – they then convert those workloads to license-included workloads in the future.
Q5: What happens if we stop paying support on a license that we were using in Cloud@Customer (BYOL)?
A5: If you stop paying support, you lose the rights associated with support, including the right to update to new versions – and, per Oracle’s policies, the right to use that license in authorized cloud environments like Cloud@Customer. Essentially, that license would revert to on-premises-only rights (and even on-premises, you’re technically out of compliance if you use software updates released after your support lapse). In Cloud@Customer, Oracle could require you to either remove that workload or convert it to license-included billing. It’s a compliance violation to use a BYOL license without active support in the cloud. The safer route if you must end support: either retire that instance from Cloud@Customer or switch it to Oracle’s license-included model (and factor the higher cost into your budget).
Q6: Are Oracle’s Core Factor table and processor definitions still relevant for Cloud@Customer?
A6: Oracle’s core factor table (which assigns a multiplier to different CPU types for on-prem license counting) is effectively baked into the OCPU definitions for cloud. On Cloud@Customer (which utilizes Oracle’s hardware based on x86 or sometimes SPARC), Oracle simplifies things: for x86 systems, one processor license covers two OCPUs. This is consistent with an Intel Core having a 0.5 factor on-prem (2 cores per license). If Oracle introduces different hardware, it will document the ratio. For example, in OCI public cloud, if you use an ARM-based Ampere instance, Oracle’s policy allows one license per 4 OCPUs (because there is no hyper-threading and a core factor of 0.25 for ARM). Currently, Cloud@Customer offerings are x86-based, so the core factor table’s effect is limited to the 2-for-1 rule. Always verify the exact terms for any new hardware Oracle might deploy on your premises, but Oracle intends to mirror OCI’s licensing rules for Cloud@Customer.
Q7: How do Named User Plus licenses apply if we have hundreds of users on a Cloud@Customer service?
A7: The Named User Plus (NUP) metric is based on named individuals (or devices) accessing the Oracle software, with a minimum per processor. In a Cloud@Customer scenario, the number of end users may be large (consider an ERP system on Cloud@Customer accessed by 500 employees). If you license it through NUP, you need a NUP for each user, so 500 NUP licenses are required, and you must meet the minimum per processor. If 500 users are using a system that needs four processor licenses by hardware count, and 500 is greater than 4*25 (100) minimum, you’re fine. The challenge is if user counts are low relative to processors, then you must at least meet the minimum 25 per proc (as noted earlier). In many enterprise cases with lots of users, NUP can be cost-effective. Just remember to count all human and non-human accesses that qualify (batch processes, integrations can sometimes need licensing too if they operate separately from named users). It may be simpler to use processor licensing for server-side software in Cloud@Customer, unless you have a very controlled and small user base.
Q8: We plan to use Oracle Cloud@Customer for development and testing. Are there any relaxed rules for non-production usage?
A8: Oracle’s licensing rules generally do not distinguish between production and non-production when it comes to requiring a license – a core running Oracle Database needs to be licensed, whether it’s dev, test, or prod. However, you can optimize costs in non-production by using smaller instances or shutting them down when not in use. Since Cloud@Customer allows you to spin down OCPUs to zero when a system is idle, you can effectively not consume license (or cloud credits) during off-hours. Additionally, suppose you have Developer licenses or other limited-use licenses on-premises. In that case, those typically cannot be used on Cloud@Customer (they are usually restricted to on-premises use only and sometimes have user limits). Therefore, assume that the same standard licenses are required in development and testing on Cloud@Customer as in production. The bright side is that you can utilize the flexibility of the cloud to minimize the number of OCPUs running in dev/test at any given time, thereby reducing the required licenses if you use BYOL (or reducing cloud usage costs if licenses are included).
Q9: Do we need to license the Oracle Cloud@Customer infrastructure itself (the hardware)?
A9: No, the infrastructure is part of the subscription cost. You don’t need to license the Oracle engineered system or any Oracle software that is purely part of the infrastructure management. Oracle provides and manages the base system – you only license the Oracle software workloads you run (databases, middleware, etc.). Think of the Cloud@Customer hardware as analogous to Oracle’s data center in the public cloud. You’re not buying it, you’re renting it via the subscription. The only licensing considerations are for the software you deploy on that hardware. Oracle’s Cloud@Customer service includes features such as the cloud control plane and monitoring software, and you are not required to separately license these components – the subscription covers them. Focus your license compliance on the databases, applications, or any Oracle product you actively run for your business purposes on Cloud@Customer.
Q10: What is the best way to keep up with changes in Oracle licensing (for Cloud@Customer or in general)?
A10: Oracle licensing can evolve, especially as new services or hardware options come out. The best ways to stay updated include: subscribing to Oracle’s official communications (Oracle frequently updates its “Licensing Oracle Software in Cloud Environments” policy document – keep an eye on that), participating in user groups or forums where licensing is discussed, and consulting with Oracle licensing experts or firms. Oracle’s own sales or support channels can sometimes clarify questions, but it’s wise to double-check with independent expertise, as sales representatives may not always possess nuanced knowledge. Additionally, periodically have your team attend training or webinars on Oracle licensing (Oracle and third-party licensing advisors often host such sessions). A proactive approach ensures that when Oracle makes a policy tweak, your organization catches it early and adapts your compliance processes accordingly.
Read more about our Oracle Advisory Services.
