Oracle Cloud at Customer: Licensing Considerations for New Deployments

Oracle Cloud at Customer: Licensing Considerations for New Deployments

Oracle Cloud at Customer brings Oracle’s cloud infrastructure and services into your own data center, offering cloud benefits with on-premises control.

However, licensing in this model can be complex.

This advisory outlines how Oracle Cloud at Customer licensing works, comparing the two primary models (bring your own license vs. license-included), examining the cost implications, and highlighting key considerations for CIOs, CFOs, and procurement leaders.

The goal is to help enterprises make informed decisions, avoid common pitfalls, and negotiate optimal terms when adopting Oracle Cloud at Customer.

Understanding Oracle Cloud at Customer

Oracle Cloud at Customer is essentially an Oracle-managed cloud environment installed at the customer’s site. It allows organizations to run Oracle Cloud services (including databases, middleware, and entire cloud regions) behind their firewall.

This hybrid approach delivers cloud advantages – like elastic scaling, automation, and subscription pricing – while keeping data on-premises for security or regulatory reasons.

From a licensing perspective, Cloud at Customer is unique because it blends traditional on-premise license use with cloud subscription models.

Key points:

• Hybrid Cloud, On-Prem Hardware: Oracle supplies and manages the hardware in your data center. You subscribe to it similarly to a cloud service, rather than purchasing the equipment.
• Regulatory and Latency Benefits: Enterprises use Cloud at Customer to meet data sovereignty requirements or low-latency needs by keeping systems local.
• Subscription Economics: You pay a subscription fee (usually annual or multi-year) for the Cloud at Customer infrastructure and services, and you have choices in how software licenses are handled within that subscription.
• Licensing Models Matter: The way you license Oracle software running on Cloud at Customer (e.g., databases or applications) will significantly impact your costs and compliance obligations. The two main models are Bring Your Own License (BYOL) and Oracle’s License-Included option.

Licensing Models: BYOL vs. License-Included

When using Oracle Cloud at Customer, you must decide how to license the Oracle software running on that platform.

Oracle offers two primary licensing models:

• License-Included (Subscription Licensing): In this model, the cloud subscription fee includes the Oracle software license and support for the product. You essentially “rent” the license as part of the service. For example, suppose you deploy an Oracle Database on Exadata Cloud@Customer under a license-included plan. In that case, your subscription rate for that database covers the right to use the Oracle Database software (and includes support services). This option is straightforward — you don’t need any existing licenses. However, the hourly or monthly rate for license-included services is higher than BYOL rates, because Oracle is charging for the software license within the service. License-included makes sense if you do not already own the necessary Oracle licenses or if you prefer Oracle to handle all support and licensing as part of the subscription.
• Bring Your Own License (BYOL): In this model, you provide your own Oracle software licenses to cover the Cloud at Customer usage. You must already possess the appropriate Oracle licenses (e.g., Database Enterprise Edition, WebLogic), and these licenses must have active support contracts. With BYOL, Oracle charges you only for the cloud infrastructure or platform usage at a lower rate, since you are supplying the software license from your existing investment. BYOL is popular for organizations that have significant sunk costs in Oracle licenses – it prevents “double paying” for licenses you already own. For instance, you can deploy an Oracle database on Cloud at Customer and apply your existing Database licenses to that deployment, paying Oracle only for the hardware/cloud resources. BYOL requires you to certify that you have sufficient licenses and remain compliant, but it can dramatically reduce ongoing subscription fees.

Both models utilize Oracle’s Universal Cloud Credits or similar consumption metrics; the difference lies in the rate and what’s included.

• A BYOL service rate might be only, say, 25% (or less) of the full license-included service rate, reflecting that the license cost is removed. In other words, license-included pricing could be 3-4 times higher per unit of compute than BYOL pricing, because BYOL gives a discount for bringing your perpetual license.
• With license-included, you don’t worry about how many licenses you own – you pay for usage and Oracle ensures the software is properly licensed as part of the deal. With BYOL, you pay lower cloud fees but must track and maintain the proper entitlements yourself.

Choosing a model:

This decision should be made upfront for each workload on Cloud at Customer, as it affects how you configure and how Oracle bills you.

In some cases, you can mix models across different services on the same Cloud at Customer environment (for example, use BYOL for a standard Oracle Database deployment where you have spare licenses, but use license-included for an Autonomous Database service if you don’t own the required licenses or options for that).

However, you cannot mix BYOL and license-included licensing on the same individual instance of a service – each database or cloud service instance has to be one or the other.

Many enterprises perform a cost analysis to compare BYOL (Bring Your Own License) vs. license-included options over the expected usage period of the system, as the economics can be significantly different.

Cost Implications and Pricing Factors

Licensing choice has a major impact on cost. Cloud at Customer generally involves two cost components:

1. Infrastructure Subscription: the base cost for the Cloud at Customer hardware and cloud infrastructure services (this is typically a fixed annual or monthly fee based on the capacity of the machine or consumption of cloud credits).
2. Software License Cost: either included in the subscription (license-included model) or covered by your existing licenses (BYOL model).

With BYOL, your cloud subscription fees are lower because you’re not paying Oracle for the software license rental. You are, however, still paying annual support on your licenses to Oracle (outside of the cloud subscription).

With license-included, you pay higher cloud fees, but that includes Oracle’s ongoing support and the right to use the software, with no separate support bill for those licenses.

Below is a comparison of the two models in terms of cost and responsibility:

Example scenario: A large financial company evaluated an Exadata Cloud@Customer deployment with 100 OCPUs of database capacity. They had a pool of Oracle Database Enterprise Edition licenses from a prior project.

Using BYOL, their Oracle cloud service costs for the databases were roughly 75% lower than they would have been under license-included rates. Over a 3-year term, BYOL saved them several million dollars.

However, they also recognized that they must continue to pay annual support on those licenses (approximately 22% of the license list price per year), which was a significant ongoing expense. In their case, the math still favored BYOL – even after accounting for support costs, the total 3-year cost was approximately 30% less than the license-included option.

On the other hand, a second project in the same company needed Oracle Analytics Cloud on Cloud@Customer, but they had no existing licenses for the Oracle Analytics Server. For that project, they chose the license-included model for simplicity, accepting the higher subscription fee rather than buying a new perpetual license just for BYOL.

This mix-and-match approach enabled them to optimize costs by leveraging their owned licenses where possible and paying Oracle for licenses where they had gaps.

Additional cost considerations:

• Universal Credits: Oracle Cloud at Customer uses Oracle’s cloud credit system (Universal Credits). Whether BYOL or included, you consume credits based on usage (e.g., OCPUs, storage). BYOL simply consumes credits at a lower rate. Ensure your contract specifies how credits can be used in a Cloud@Customer context and if there are any minimum spend commitments.
• Support Rewards: Oracle’s Support Rewards program (for OCI) can potentially offset some costs. For example, Oracle gives credits toward on-prem support bills (up to 25¢ or more per $1 spent on Oracle Cloud). If your Cloud at Customer spend qualifies, those rewards can effectively reduce your Oracle support costs – a bonus if you are doing BYOL (since you’re paying support). It’s worth discussing with Oracle if Cloud@Customer subscriptions earn support reward credits.
• Long-Term vs Short-Term Use: If you expect to use the Oracle software continuously for many years and have stable workloads, purchasing a perpetual license (or using existing ones) plus BYOL often yields a lower Total Cost of Ownership (TCO) over the long run. Conversely, for short-term projects or variable workloads, the license-included model’s flexibility might justify the higher unit cost because you can scale down without owning idle licenses.

Compliance Risks and Common Pitfalls

Oracle’s licensing is notoriously complex, and Cloud at Customer introduces new wrinkles.

Enterprises must remain vigilant to avoid compliance issues or unexpected costs.

Below are common pitfalls and risks to watch for:

• Counting Cores vs Licenses: Cloud at Customer resources are measured in OCPUs (Oracle CPU units). One OCPU generally equals one physical CPU core (which corresponds to two vCPUs with hyper-threading). Oracle’s standard policy is that 1 Oracle processor license covers 2 OCPUs for Intel/AMD-based systems. A common mistake is miscounting licenses – e.g., seeing 8 OCPUs and assuming you need 8 licenses (in reality, that would typically require 4 processor licenses if using Bring Your License, or BYOL). Always apply Oracle’s official conversion rules when calculating how many licenses you need for a given OCPU allocation. Miscounting can lead to under-licensing (a compliance breach) or over-licensing (unnecessary cost).
• 90-Day/100-Day License Mobility Rule: Oracle generally allows you to move licenses between on-premises and cloud environments, but there is a rule (often 90 days for standard contracts) against frequently moving licenses back and forth. In practice, Oracle has a “100-day rule” for cloud migrations: you can use a license in both on-prem and Cloud at Customer simultaneously for up to 100 days (to facilitate a migration). After that, you must retire one of the instances or have additional licenses. If you leave on-prem systems running longer than the grace period while also using those licenses in the cloud, you could be out of compliance. This often catches companies off guard during audits. Plan migrations carefully and document when licenses are reassigned to the cloud, so you don’t unintentionally double-dip beyond the allowed period.
• Unlimited License Agreement (ULA) Considerations: If your enterprise is operating under an Oracle ULA (a contract that allows unlimited use of certain products for a specified period), exercise caution when considering Cloud at Customer. Oracle’s policy is that usage in authorized cloud environments (including Cloud at Customer) does not count toward ULA certification quantities. In other words, you usually cannot use a ULA to cover Cloud at Customer deployments in a way that increases your entitlement count when the ULA ends. Some companies tried to deploy massive cloud instances under a ULA, expecting to “inflate” their usage count, only to find those deployments aren’t counted, leaving them under-licensed when certifying out of the ULA. Always review your ULA terms and consult with Oracle or a licensing expert to determine how cloud usage is treated before assuming it’s covered.
• BYOL Requires Active Support: Only licenses with current, active Oracle support can be used for BYOL in the cloud. Attempting to use old licenses with lapsed support is not permitted (unless you pay hefty reinstatement fees). An often overlooked scenario is when companies have shelfware licenses they stopped updating – those can’t be brought to Cloud at Customer without re-subscribing to support. Ensure that any license you plan to BYOL is fully paid up for support and that the product edition/version is the correct one. (For example, you cannot use a Standard Edition database license to cover an Enterprise Edition cloud instance, and you cannot use a license that’s restricted to a specific application or an ISV/OEM license for BYOL.)
• Over-Provisioning and “Bursting” Risk: One attractive aspect of cloud is the ability to scale up resources on demand. However, suppose you’re in a BYOL model. In that case, scaling up a service (adding more OCPUs or spinning up extra VMs) can immediately put you out of compliance if you don’t have enough licenses to cover the increased usage. Oracle’s cloud systems won’t automatically prevent you from doing this. For example, if you suddenly double the OCPUs for a database during a peak period, you need to have double the licenses available. Even if the high usage is temporary, Oracle does not allow “bursting” beyond your licensed rights unless you switch those extra resources to a license-included billing. To avoid this trap, establish internal policies: before increasing the capacity of any BYOL-based deployment, verify that you have spare licenses or plan to acquire additional licenses (or toggle that instance to license-included for overflow). Some companies maintain a buffer of extra licenses for such needs, or utilize Oracle’s autoscaling with license-included options for short bursts, ensuring they remain compliant.
• Audit and Visibility: Do not assume that because Cloud at Customer runs in your data center, Oracle cannot see your usage. Oracle manages the infrastructure remotely and has telemetry on resource usage. They might not see actual data, but they know how many OCPUs you’re consuming on each service. In a license-included scenario, any overuse just results in higher fees (since you pay per OCPU/hour). In BYOL, overuse might not immediately alert Oracle, but if an audit happens, Oracle can compare your reported usage with the licenses you’ve certified. Cloud environments at customer sites should be treated as if they are continually monitored for compliance. Always be audit-ready: document which licenses (by license number or entitlement) cover which cloud deployments, and keep proof of entitlement and support handy. Oracle retains the right to audit BYOL usage. Being proactive in tracking will help avoid surprises.
• Assuming “Included” Covers Everything: License-included services simplify a lot, but they only cover the specific Oracle product in question. If you start using additional Oracle products in that environment, those might require separate licensing. For example, if you have a license-included Autonomous Database on Cloud at Customer, that covers your Oracle Database and many of its options. However, suppose you decide to install Oracle GoldenGate or a third-party application on the same Cloud at Customer infrastructure (outside the scope of the Autonomous DB service). In that case, your database’s license-included subscription doesn’t magically cover additional software. You would need to either BYOL a license for GoldenGate or subscribe to a GoldenGate cloud service if available. The pitfall is forgetting that Cloud at Customer can run many types of workloads – not every component is automatically included. Always clarify which Oracle products and features are included under your contract. If you plan to use, say, Oracle WebLogic on a Compute Cloud@Customer instance, you either need a license-included PaaS service for WebLogic or to BYOL your WebLogic licenses, since Compute by itself (IaaS) doesn’t include application licenses.
• Contractual Commitments: Be aware of any minimum usage commitments in your Cloud at Customer agreement. Some older Cloud at Customer contracts required a fixed amount of license-included capacity to be subscribed (because the hardware was sized for a certain workload). Newer agreements may be more flexible, allowing pure pay-as-you-go. If you sign up for a certain number of OCPUs of a database service as a baseline, you may be billed for that regardless of actual usage (especially under a license-included plan). Ensure any commitments align with your actual needs. Also negotiate terms around scaling down or suspending services – Oracle Cloud at Customer now supports capacity on demand (you can turn off OCPUs and stop billing for them, in some cases), but make sure your contract explicitly allows that level of elasticity; otherwise, you could be paying for idle resources (and idle licenses).

In summary, licensing on Oracle Cloud at Customer requires the same diligence as traditional on-prem licensing, plus cloud-specific nuances.

Involve your software asset management team or licensing specialists in planning Cloud at Customer usage to avoid these pitfalls.

Strategic Considerations for New Cloud@Customer Deployments

For CIOs, CFOs, and procurement leaders evaluating Oracle Cloud at Customer, it’s critical to approach the deal strategically.

Unlike a generic public cloud, Oracle Cloud at Customer is often a bespoke engagement (involving hardware delivery, multi-year terms, and significant spending), so you have an opportunity – and a necessity – to negotiate and plan carefully.

Key strategic considerations include:

• Inventory and Assess Your Licenses: Before choosing BYOL or license-included, take stock of your existing Oracle license inventory. Do you have underutilized licenses (from previous purchases or decommissioned systems) that could be repurposed in Cloud at Customer? If yes, BYOL can yield immediate savings. If not, factor in the cost of acquiring new licenses versus paying the premium for a license-included option. In some cases, if you’re a new Oracle customer or expanding into a new product, buying a perpetual license just to use BYOL might not be worthwhile unless you’ll use it heavily for many years.
• Run a Cost Comparison Scenario: Calculate the 5-year or 3-year TCO under both models. Include all components: cloud subscription fees, support costs, potential Oracle Support Rewards credits, and other relevant expenses. Often, BYOL has lower ongoing costs but may require a higher upfront investment (if purchasing new licenses). License-included is pure OPEX. Your finance team should also consider the accounting preferences (CapEx vs. OpEx). Some companies prefer subscription-only costs, while others are willing to capitalize a license purchase if it saves money in the long term.
• Mix and Match Strategically: You don’t have to choose one model for everything. Many enterprises use a hybrid licensing strategy on Cloud at Customer.
  • Use BYOL for steady-state workloads that run 24/7 and where you have sufficient licenses. This maximizes the value of licenses you own.
  • Use license-included for bursty or new workloads where you lack licenses or need flexibility. For example, a test environment you only run occasionally might be better as license-included, so you’re not tying up a license that you paid for outright.
  • Also, consider license-included for any Oracle Cloud services that bundle valuable features you don’t have on-premises. Sometimes Oracle’s license-included cloud services (like Autonomous Database) include high-end options (tuning, security packs, etc.). If you BYOL a standard license to Autonomous Database, Oracle does grant rights to certain packs during cloud use, but make sure you understand what’s included.
• Negotiation with Oracle: Treat the Cloud at Customer contract like any large enterprise software negotiation. Key items to negotiate:
  • Pricing and Discounts: Oracle typically offers custom pricing based on your committed capacity and term. Ensure you get competitive discounts on both the infrastructure and any license-included rates, especially if you’re a significant Oracle customer.
  • Flexibility Clauses: Negotiate the ability to adjust your usage downward or upward. For example, can you reduce the number of OCPUs if your needs drop? Can you burst above your committed level at a certain cost? Clarify how overage will be charged and whether it can be handled as a license-included ad-hoc service.
  • Conversion and Exit Options: If you start with BYOL but later decide you want to convert to a license-included model (or vice versa), can this be done? Additionally, what happens at the end of term – do you have the option to buy the hardware or extend the term, and how will licenses be handled if you don’t renew? Ensure there’s no “stranded” license situation (for instance, if you purchased licenses for BYOL and then Oracle discontinues that service, ensure you can use those licenses elsewhere or in Oracle’s public cloud).
  • Support and Maintenance: Since Oracle will be managing the on-prem equipment, clarify the support processes. For license-included parts, Oracle’s support is built-in; for BYOL parts, you maintain support, but Oracle still might handle infrastructure support. Ensure there are no gaps (e.g., who applies patches to software – often Oracle does as part of a cloud service, but you must ensure it aligns with your license usage).
  • Audit Relief: While Oracle typically doesn’t waive audit rights, you can attempt to negotiate contractual language that provides some assurance or process for audits related to Cloud at Customer. For example, if you are committing to a significant expenditure, consider asking Oracle to agree to an annual license review process rather than surprise audits, or at least define cure periods for any compliance issues that may be identified.
• Leverage Oracle Programs: Oracle sometimes offers programs to sweeten a Cloud at Customer deal – for instance, the Oracle Support Rewards (to offset support costs) or allowing credits for unused on-premises support if you shift workloads to the cloud. Additionally, if you have a large number of on-premises licenses that you may drop after migrating to the cloud, consider options such as license exchanges or cloud credits for licenses. Oracle has in the past done deals where customers terminate some on-prem licenses/support in exchange for cloud service credits. Negotiating such a swap can reduce duplicate costs (paying support and cloud fees at the same time).
• Plan for Compliance and Monitoring: Establish governance from day one. Include clauses about how usage will be tracked and reported. Internally, set up a team or use tools to monitor OCPU usage against your entitlements. Treat your Cloud at Customer environment as a critical asset that requires license management oversight just like your on-prem estate. This will also give executives visibility into consumption vs. commitments (avoiding surprise bills or compliance gaps).

By taking a strategic approach and baking these considerations into your plan and contract, you can maximize the value of Oracle Cloud at Customer while minimizing financial and legal risks.

Recommendations

Practical Tips for Optimizing Oracle Cloud at Customer Licensing:

• Evaluate BYOL First: If you have existing Oracle licenses, always evaluate the BYOL option. Calculate how much you’d save on cloud fees and ensure those licenses are eligible (and supported). BYOL can often save 30-50% or more on service costs, making it a strong starting point for cost optimization.
• Don’t Double-Pay for Capacity: Avoid paying for Oracle licenses twice. If you move a workload to Cloud at Customer and use license-included, consider whether you can re-harvest or terminate the on-prem licenses/support for that product (to save cost) – or vice versa. Align your on-prem license maintenance with your cloud usage to prevent waste.
• Negotiate Elastic Terms: Push Oracle for flexibility in your contract. For example, include the right to scale down services or switch licensing models for certain instances if needed. The more elasticity and options you have, the better you can respond to changing business needs without incurring penalties or excess costs.
• Leverage Oracle Support Rewards: When doing BYOL, sign up for Oracle’s Support Rewards (or ensure your spend is eligible). This can effectively provide you with a rebate on your support bills (e.g., 25% of your cloud spend is credited against support). It’s a useful way to offset the cost of those support renewals you must keep paying for BYOL.
• Document Everything: Keep detailed records of what licenses are allocated to which Cloud at Customer resources. This includes dates when licenses were migrated to the cloud, the number of OCPUs each license covers, and any communication with Oracle regarding special terms (such as a granted exception). In the event of any dispute or audit, this documentation serves as your evidence of compliance.
• Train Your Teams: Ensure that your cloud admins and project teams understand the licensing implications. They should know, for instance, that spinning up a new VM or adding OCPUs in a BYOL deployment isn’t free – it draws from a finite license pool. Establish an approval process for any changes that could affect license usage.
• Regularly Review Usage vs. Entitlements: Schedule a quarterly or semi-annual internal audit of your Cloud at Customer usage. Compare the peak OCPUs used with the licenses you have on record. This proactive review can catch any usage creep early, allowing you to address it (by reducing usage, reallocating licenses, or purchasing additional rights) before Oracle’s auditors come knocking or before a true-up bill arrives.
• Plan for the Future: Technology and license needs will evolve. Build a roadmap that considers how your Oracle environment might change – e.g., adopting new Oracle Cloud services, expanding capacity, or possibly exiting Cloud at Customer in favor of public cloud or another solution. Include in your plan how licenses will be handled in those scenarios. For instance, if after a few years you decide to move to Oracle’s public cloud or another platform, know which licenses you can take with you and which subscriptions can be terminated.
• Consult Experts if Needed: Oracle licensing and contracts are specialized areas. Don’t hesitate to involve a licensing advisor or legal counsel, especially for negotiations. They can often identify unfavorable terms or find opportunities for cost savings that busy IT and procurement teams might miss. Given the high stakes of enterprise contracts, expert input can pay for itself many times over.

Checklist: 5 Actions to Take

If you are about to adopt Oracle Cloud at Customer, here’s a simple step-by-step checklist to guide your licensing approach:

1. Assess Your License Inventory and Needs: Gather all existing Oracle licenses and usage data. Identify which workloads you plan to run on Cloud at Customer and determine the required licenses (and editions) for those workloads. Determine if you have sufficient licenses for BYOL or if you’ll need to go license-included for each component.
2. Perform Cost Analysis: For each workload or service, model the costs of BYOL vs. license-included. Include cloud subscription fees, support costs (for BYOL), and any one-time license purchase needed. Identify the breakeven point and which model offers the better value over your expected timeframe. This analysis will inform your decisions and negotiation strategy.
3. Review and Negotiate Contract Terms: Before signing with Oracle, scrutinize the Cloud at Customer contract. Ensure that key terms (pricing, minimum commitments, the ability to scale up/down, BYOL usage rights, etc.) align with your expectations. Negotiate adjustments as needed – for example, request the flexibility to reduce capacity after year 1 if usage is lower, or to temporarily convert a BYOL instance to a license-included one if needed for bursts. Get any special agreements in writing.
4. Implement Governance and Monitoring: Set up processes or tools to monitor cloud usage (OCPUs, active services) on the Cloud at Customer environment. Establish an internal policy that requires any change in cloud resource allocation to consider licensing implications. Assign an owner (or team) for license compliance in the cloud. This governance step ensures that operations remain in sync with licensing.
5. Educate Stakeholders and Execute: Inform your IT ops teams, finance, and project managers about the chosen licensing model for each Cloud at Customer service. Ensure everyone is aware of the dos and don’ts (for example, not exceeding the licensed capacity without approval). As you deploy Cloud at Customer, follow the plan: attach the proper licenses to each BYOL deployment in Oracle’s system, and ensure Oracle is aware which instances are BYOL vs included. Finally, schedule periodic business reviews with Oracle to discuss usage, ensuring there are no surprises and maintaining a good working relationship while keeping costs in check.

FAQ

Q: What exactly is Oracle Cloud at Customer, in simple terms?
A: Oracle Cloud at Customer is essentially Oracle’s public cloud delivered within your data center. Oracle installs its cloud hardware on your premises, and you consume Oracle Cloud services (like databases, applications, etc.) as a subscription, much like you would in the public cloud – but the systems are physically on-site under your control. It’s designed for enterprises that want cloud capabilities but cannot migrate to Oracle’s public cloud data centers due to data residency, latency, or compliance requirements.

Q: How does Bring Your Own License (BYOL) work for Cloud at Customer?
A: With BYOL, you use your existing Oracle software licenses to cover the Oracle products running on Cloud at Customer. Practically, this means if you have, say, 10 Oracle Database processor licenses on-premises, you can allocate those to 20 OCPUs of database service in Cloud at Customer (since one processor license covers two OCPUs for most Oracle products). Oracle will charge you a reduced rate for that database service because you are not consuming a new license from them – you’ve “brought your own.” You must maintain support on those licenses and comply with Oracle’s rules (e.g., not using more OCPUs than your licenses allow). BYOL lets you avoid paying the license fee again in the cloud. It’s ideal if you already invested in Oracle licenses and want to maximize that investment in a cloud model.

Q: When should we choose the License-Included model instead of BYOL?
A: The license-included model is generally chosen when you either lack the required licenses or you want the simplicity of one all-inclusive subscription. Suppose you are a new Oracle customer or expanding into a product where you have no spare licenses (for example, adopting a new Oracle technology). In that case, license-included is straightforward – you just pay Oracle for what you use, and all licensing and support are bundled. It’s also useful for short-term needs or unpredictable workloads: you can start and stop services without having to buy perpetual licenses that might sit idle. However, you pay a premium for this convenience. We recommend license-included for cases where the cost difference is small or the flexibility is critical, and BYOL for stable, long-term workloads where you have already paid for licenses. Some companies initially use licenses included with the service (to test it or start quickly) and later purchase or free them up – though switching models may require re-provisioning the instance, so plan accordingly.

Q: Can we mix BYOL and license-included in the same Cloud at Customer environment?
A: Yes, you can mix models in the same overall environment, but not on the same instance of a service. For example, on an Exadata Cloud at Customer machine, you could have one database deployed as BYOL and another database deployed as license-included. Or you might run your base workload on BYOL and spin up an extra database on the side with license-included licensing for a special project. Oracle’s systems will bill the BYOL instance at the lower rate and the license-included one at the higher rate accordingly. What you cannot do is split a single database or single VM’s licensing – each instance must be entirely one model or the other. Many enterprises find a hybrid approach effective: it allows them to utilize owned licenses while still having the flexibility to use license-included for new or temporary needs on the same Cloud at Customer infrastructure.

Q: What are the top licensing pitfalls to avoid with Oracle Cloud at Customer?
A: Key pitfalls include: (1) Under-counting licenses – misunderstanding Oracle’s core-to-license conversion (OCPUs vs. processors) and ending up out of compliance. Always remember that most x86 cores are counted as half a license (2 OCPUs = 1 license) in Oracle’s world. (2) Assuming you’re on-prem agreements cover cloud – for instance, not realizing that an Unlimited License Agreement won’t let you infinitely expand in Cloud at Customer. (3) Using BYOL without active support – a license without support is not valid for cloud use; Oracle can and will enforce that. (4) Overcommitting in contracts – locking yourself into more capacity or a longer term than needed can waste money if your cloud usage is less than anticipated. And (5) Neglecting governance – treating Cloud at Customer like a black box can lead to overuse or unintended software deployments. Always enforce the same level of software asset management in Cloud at Customer as you do on traditional infrastructure. By being mindful of these issues and following best practices (like those in this guide), you can avoid most common mistakes.

Further Reading

• Oracle Cloud at Customer Licensing Best Practices: Compliance and Cost Optimization
• Oracle Dedicated Region Cost Optimization (Cost and Licensing)
• Licensing Oracle Cloud at Customer vs Oracle OCI
• Oracle Exadata Cloud at Customer Optimization (Cost and Licensing)
• Which Oracle Software Can You Run on Oracle Cloud at Customer
• Oracle Cloud at Customer vs. Dedicated Region
• Oracle Cloud at Customer Cost Optimization: Reducing Support Costs and Maximizing Value

Read more about our Oracle Advisory Services.

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

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit