BYOL vs. License-Included on Azure
This article is intended for CIOs and IT procurement leaders who are evaluating how to run Oracle software on Azure. We explain the two primary licensing models available: Bring Your License (BYOL) and License-Included (pay-as-you-go) options.
You’ll learn about the pros, cons, and cost implications of each approach on Azure, including real-world examples (such as comparing the cost of acquiring a $47,500 Oracle Database license versus renting one hourly on Azure).
By the end, you’ll have a clear strategy to minimize costs and maximize flexibility for Oracle on Azure.
Bring Your Own License (BYOL) on Azure
BYOL means you use licenses you already own (or purchase separately from Oracle) and deploy Oracle software on Azure VMs with those licenses. Azure is officially an Oracle-authorized cloud, so Oracle honors BYOL here.
Key points:
- How BYOL Works: You spin up an Azure VM (or use an Oracle-provided image marked “BYOL”) and install Oracle software. When configuring, you indicate you’re using your own license. Microsoft does not charge you for Oracle license fees – you only pay for Azure infrastructure (VM compute, storage, etc.). It’s as if Azure is an extension of your on-prem data center.
- Counting Licenses: Oracle’s cloud licensing policy applies. In Azure, Oracle counts two vCPUs as one processor license (because Azure uses hyperthreaded cores). So a VM with four vCPUs requires 2 Oracle processor licenses (assuming multi-threading is enabled). There’s no core factor in play – it’s a straight 2-for-1 deal. Named User Plus (NUP) licenses can also be used in Azure for eligible products; however, most enterprises typically use processor licensing for servers.
- Support Requirements: When you BYOL, you must continue to pay Oracle Support on those licenses (typically 22% of the license price annually). This provides you with access to patches and support, even when running on Azure. Support costs should be factored into your TCO analysis.
- Flexibility: BYOL is great if you have existing investments. For example, if you own 10 Oracle Database Enterprise Edition licenses on-prem and decommission some servers, you can reassign those licenses to Azure instances. This avoids purchasing new licenses.
- Upfront vs Ongoing Cost: BYOL has a high upfront cost (buying perpetual licenses), but a low ongoing cloud cost (no Oracle rental fees, just support). Over multi-year periods, BYOL typically becomes more cost-effective than paying hourly rates. We’ll illustrate this in the cost comparison section.
When to favor BYOL:
- Long-Term, Steady Workloads: If you plan to run an Oracle workload 24×7 for more than, say, a year, BYOL often wins financially. Buying a license may cost hundreds of thousands initially, but over the years, it’s cheaper than accumulating hourly charges.
- Existing Licenses in Hand: If you already own Oracle licenses (and they’re not fully utilized), it’s almost always best to use them on Azure (assuming your contract allows it, which it should for authorized cloud use). You avoid paying twice for the same software.
- Large-Scale Deployments: For enterprise-wide Oracle deployments on Azure, negotiating an Enterprise License Agreement or ULA (Unlimited License Agreement) and using BYOL can be more cost-effective than metered cloud licensing.
Azure License-Included Options for Oracle
Azure historically had limited license-included options for Oracle, but recent developments expanded this:
- Oracle Database@Azure: Launched in 2023, this joint service by Microsoft and Oracle lets you provision Oracle-managed databases in Azure. You can choose a “license-included” model, where the Oracle Database license cost is bundled into the hourly service price. Essentially, you rent the Oracle license as part of using the database service, without any up-front purchase.
- Marketplace VM Images (legacy): In the past, Azure offered some Oracle Database VM images on a pay-as-you-go basis (especially for Standard Edition). As of now, most official images for Oracle Database or WebLogic on Azure require BYOL. Oracle’s emphasis is on Database@Azure for a license-included experience. Azure does not currently offer license-included Oracle WebLogic; all WebLogic VMs are BYOL.
- Third-Party Offerings: Some Azure third-party services or managed service providers might bundle Oracle licenses in their solution (for example, an MSP might run an Oracle instance for you and charge a monthly fee, including the license). These are less common, and one should ensure Oracle has authorized that model.
Characteristics of License-Included:
- No Upfront License Purchase: You simply provision the service or VM and pay for the Oracle software as part of your Azure bill. This is purely OPEX. It’s ideal for short-term needs or when you lack a capital budget for licenses.
- Higher Hourly Rate: The convenience comes at a price – the hourly cost for Oracle software usage is high. For example, if an Oracle EE license costs ~$47,500, the hourly rate is set so that over a 3-4 year period of constant usage, you’d end up paying more than that. Azure’s model ensures Oracle gets its value; you’re paying for flexibility.
- Scale Up/Down: You can start an Oracle included instance for a few hours or days, and then stop paying when you shut it down. This elasticity is useful for transient workloads (e.g., a 2-month project, seasonal capacity, or development and testing environments that you don’t keep on all the time).
- Support included: When you pay hourly, Oracle’s support fees are inherently included in that price. You won’t separately pay Oracle support – Microsoft and Oracle share the revenue. This means if you have an issue, Oracle will still support the environment (in the case of Database@Azure, Oracle is managing the DB for you, so support is part of the service).
When to consider License-Included:
- Short-Term or Variable Workloads: If you only need an Oracle environment for a few months or have highly variable usage (e.g., you scale up an Oracle database farm at the end of the quarter and shut down later), paying by the hour can be cheaper than a perpetual license.
- No Existing Licenses: If your organization has no Oracle licenses (perhaps a new project requiring Oracle DB), and especially if it’s a one-off need, the license-included model avoids a long-term commitment. You may not want to invest in a perpetual license plus 22% yearly support if you’re unsure of future use.
- Preference for Managed Service: Oracle Database@Azure in license-included mode is not just a license rental; it’s also a managed service (Oracle handles patching, etc.). Some CIOs will pay a premium for a fully managed database service, which provides ease of operation, and the cost is rolled into that service.
Cost Comparison: BYOL vs License-Included
To make this concrete, let’s compare an example scenario on Azure:
Scenario: You need to run an Oracle Database Enterprise Edition on an Azure VM with eight vCPUs for a 3-year period.
Consider BYOL vs license-included.
- BYOL Option:
- Licensing Cost: 8 vCPUs on Azure = 4 Oracle processor licenses (because two vCPUs = 1 license). At a list price of approximately $47,500 each, that’s $190,000 upfront. You might have discounts, but let’s use a list for comparison.
- Support Cost: 22% of $190k = $41,800 per year. Over the past 3 years, support totals approximately $125,400. (If you already owned these licenses, you’re just continuing support).
- Azure VM Cost: (For apples-to-apples, the VM compute cost is the same in both scenarios, so we will focus on license costs mainly. However, assume an Azure VM cost of, say, $ 0.50/hour for an 8 vCPU machine – approximately $3,500/year, which is separate from the Oracle cost.
- Total 3-year Oracle cost (BYOL): $190,000 + $125,400 = $315,400. After year 3, costs drop to just support ($41.8k/year) if you continue.
- License-Included Option:
- Licensing Cost: Let’s assume the Oracle EE license-included rate is approximately $2.00 per vCPU-hour (Note: Actual rates are not publicly published in a simple format, but this is provided for illustration purposes). For 8 vCPUs, that’s $16 per hour. Over one year (8760 hours), that’s ~$140,160 per year. Over 3 years, if run continuously, $420,480. This would be the cost purely for the Oracle software rental. (The Azure VM compute cost ~$3,500/year is separate, same as above).
- Support is included in the above rate.
- Total 3-year Oracle cost (License-Included): $420,480.
In this rough comparison, BYOL costs $ 315,000 versus $ 420,000 for a license, including over 3 years of constant use. BYOL saves money in the long term (approximately 25% savings). If the period extends to 5 years, BYOL’s advantage grows (you’d still be paying support, but no new license fee, whereas rental keeps going).
However, if you only needed the server for 6 months, a license-included option would be far cheaper ($70k for Oracle rent vs. buying a $190k license outright, which would be overkill for 6 months).
Important: Actual break-even will depend on Oracle’s pricing and any discounts. Typically, if you expect to use the software continuously for more than 1-2 years, purchasing (or using existing licenses) is economically smarter.
Also consider:
- Scaling down: License-included allows you to shut down instances at zero cost. BYOL means you’ve sunk the cost; even if you shut down the VM, you’ve paid for the license already (though you could reuse it elsewhere). For dev/test environments that run 8 hours on weekdays (approximately 160 hours per month instead of 730), pay-as-you-go can be an efficient approach.
Compliance and Contract Considerations
- License Mobility: Oracle’s BYOL on Azure is allowed under policy; you don’t typically need to formally notify Oracle, but you should ensure you have enough licenses and they are on active support. Oracle may request evidence of license deployment during audits. Using Azure doesn’t count against you, as long as you apply the vCPU rule correctly.
- Contractual Terms: Some Oracle contracts (especially older ones) didn’t envision the cloud. It’s wise for Oracle to include language recognizing cloud use. Since 2020, Oracle has had public policies stating that Azure is acceptable, but it never hurts to obtain confirmation in writing if you’re making a large investment.
- License-Included Contract: If using Oracle Database@Azure, you essentially have a service agreement through Azure. Ensure you understand the terms – e.g., what happens if you already own licenses? (Database@Azure allows a BYOL mode too, which charges you a lower rate if you bring a license). If you accidentally use a license-included option when you meant to use BYOL, you might be double-paying.
- Switching Models: You may start with license-included options and later decide to purchase licenses (especially if a project transitions from pilot to production over the long term). This is possible: you’d transition by deploying a new BYOL instance and migrating, or, in the case of Database@Azure, switching to a supported pricing model. Plan the transition so you don’t pay for both at once. Similarly, if you have a license and decide to drop support and go purely rental, ensure that you terminate the support to save costs (but be careful, as dropping support has implications if you ever need those licenses again).
Making the Right Choice for Your Organization
There is no one-size-fits-all; many enterprises use a hybrid approach:
- Use BYOL for steady-state production systems that run full time and where you have licenses. This minimizes ongoing cloud costs.
- Use License-Included for transient needs, such as development environments that run only during office hours or for proofs of concept. Also for workloads where you expect to decommission in a year or less.
- Periodically re-evaluate: if you find an Oracle instance has been running on pay-as-you-go for 18+ months, do the math – it might be time to convert that to BYOL by buying a license. Conversely, if you’ve moved to a new application and no longer need an Oracle instance, but you’ve purchased licenses, check if those licenses can be reused elsewhere or if maintaining support is still worthwhile.
Azure’s billing tools and cost management can help you identify how much you are spending on Oracle license-included services vs. infrastructure. Use those to inform decisions:
- If your “Oracle software” line item in Azure bills is high, consider incurring capital expenditures on licenses to reduce that cost.
- If it’s low or occasional, renting might be a suitable option.
Also, involve your software asset management (SAM) team. They should track Oracle licenses as you move to Azure and ensure you’re not under-licensed or overspending.
Sometimes, companies accidentally run an Oracle VM in Azure without realizing they need to BYOL, resulting in compliance risk if they never assign a license to it. Azure won’t enforce Oracle licensing for you; it’s your responsibility.
Recommendations
- Calculate TCO for Both Models: Before deploying Oracle on Azure, run a 3-to 5-year Total Cost of Ownership (TCO) comparison. Include license purchase + support (BYOL) vs. hourly costs (license-included). Use realistic utilization assumptions. This analysis often makes the choice clear for each workload.
- Maximize Existing Investments: If you have underutilized Oracle licenses on-prem, leverage them in Azure. This might require reallocating or re-hosting systems, but it can save significant money by avoiding new purchases.
- Mix and Match Environments: Use license-included options for non-production environments and BYOL for production environments. For example, dev/test Oracle environments can be spun down when not in use – use pay-go there. Production, which runs 24/7, should use BYOL for cost efficiency.
- Monitor Cloud Usage: Continuously monitor your Azure usage of Oracle services. Set alerts for high Oracle Database on Azure consumption. A spike might mean an overlooked VM was started with license-included costs. Early detection can save costs – you could convert that VM to BYOL if it weren’t intended to be pay-go.
- Negotiate with Oracle: If you anticipate significant Oracle deployments on Azure, consider negotiating license agreements directly with Oracle. Sometimes, Oracle will provide additional discounts or flexible terms (such as cloud reassignments or including cloud use in a ULA) if they are aware of your strategy. A well-negotiated contract can grant the freedom to optimize on Azure without ambiguity.
- Stay Compliant: Even when focusing on cost, ensure compliance for BYOL, document which Azure VM consumes which Oracle license. For license-included, keep evidence from Azure billing that those instances were paid for. This helps if Oracle ever questions your usage.
- Utilize Oracle’s License Portability Programs: Oracle offers programs such as Oracle Support Rewards (for OCI usage) – although not directly for Azure. If you use Oracle Cloud in conjunction with Azure, you can potentially offset support costs. Additionally, Oracle’s LMS features cloud-friendly worksheets; utilize Oracle’s provided guidelines for Azure.
- Consider Future Scalability: If you anticipate growth, BYOL may allow you to scale without increasing rental fees. For example, owning an extra set of licenses allows you to spin up another Azure instance without incremental software cost (aside from support). In contrast, each new license-included instance incurs a linear cost. Capacity plan: if a project might double users or data, include that in your model.
- Retire Unused Licenses if Possible: On the flip side, if you move to a SaaS or non-Oracle solution and find Oracle licenses idle, you could drop their support to save money (though you retain the right to use the current version perpetually). Or consider talking to Oracle about converting them to cloud credits or other products – Oracle sometimes offers conversion programs. This is beyond Azure-specific, but overall license portfolio management.
- Leverage Cloud Cost Management Tools: Tools like Azure Cost Management or third-party cloud optimization solutions can identify resources that are running and their associated costs. Tag your Azure resources that are related to Oracle. This will help differentiate infrastructure costs from license costs in reports and make optimization more apparent.
Read Running Oracle Enterprise Applications on Azure: Licensing E-Business Suite, PeopleSoft, and More.
FAQ
Q1: Can I switch an Azure VM from a license-included to a BYOL (or vice versa) configuration without rebuilding it?
A: It depends on the service. If it’s an Oracle Database on an Azure instance, you choose the model at provisioning; converting might require provisioning a new instance under the other model and migrating the data. If it’s an IaaS VM, the VM images are typically BYOL by default. To use a license-included model on IaaS, you’d have to be using a specific image or offer (and Azure currently doesn’t offer many). In practice, if you accidentally deployed a database on an older pay-as-you-go image and now have a license, you’d likely need to switch to a BYOL image or reinstall Oracle with BYOL – essentially reinstall the software with your own key. It’s not a flip of a switch because Azure doesn’t have an in-portal toggle for Oracle licensing mode (unlike Windows, which has a Hybrid Benefit toggle). Plan ahead which model you want to use to avoid reconfiguration.
Q2: What is the Oracle Database@Azure “BYOL” option?
A: Oracle Database on Azure (the managed service) offers two pricing options: BYOL and License-Included. If you select BYOL, it means you’ll use one of your Oracle Database licenses to cover the database running in that service, and Microsoft will charge you a lower rate (covering only the hardware and management, not the Oracle license rental). You must assert you have a license and maintain support. If you choose license-included, you don’t need your own license; the cost you pay covers Oracle’s license. This is similar to how Oracle Cloud Infrastructure works. It gives flexibility if you have some licenses but maybe not enough for all databases – you could BYOL for some instances and pay for others in the same Azure integrated service.
Q3: Does BYOL on Azure require maintaining Oracle support contracts?
A: Yes, if you’re using Oracle licenses on Azure, Oracle requires that those licenses remain under support (to be valid for use and receive updates/support from Oracle). Running Oracle software on an unsupported license is not only risky (no patches) but also a compliance no-no if you’ve dropped support without a valid perpetual right to the version. Always budget the annual support fees in BYOL scenarios. The only time you wouldn’t have a support contract is if you are using fully license-included services (where support is built into the hourly cost), or if you have a term license that expired, but those are rare these days, as Oracle moved away from term licensing.
Q4: Are there any Oracle products that I cannot use my license for on Azure (i.e., not allowed by Oracle)?
A: Oracle’s official policy covers most of its technology products (Database, Middleware, etc.) for authorized cloud usage, including Azure. Oracle Applications (like EBS) are also allowed on Azure. Historically, there was some confusion, but now Oracle’s cloud policy document explicitly lists Microsoft Azure. One thing to note: Oracle Java SE subscriptions – if you have those – have their own terms for cloud use (Oracle treats Java somewhat separately from its database policy). But generally, you can BYOL for Java on Azure too (with the same two vCPU = 1 processor metric if using the legacy Java licensing). Always check Oracle’s most recent “Licensing Oracle Software in Cloud Environments” policy document for any exceptions. Currently, there are no major exclusions for Azure.
Q5: We have an Oracle Unlimited License Agreement (ULA). Should we use that for Azure or opt for a license-included solution?
A: If your ULA allows usage on Azure (most do, but ensure the language doesn’t restrict to on-prem), then by all means use it on Azure – that’s essentially BYOL with unlimited usage during the term. This can be extremely cost-effective, as you can deploy as many Oracle instances on Azure as needed without incurring incremental license costs. One caution: when the ULA ends, if you need to certify your usage, include those Azure deployments in your count (again, assuming contract allowed it – if not, negotiate an amendment). If you plan to certify and exit the ULA, whatever number of processors you’re using in Azure at that time will become your perpetual allotment. Some companies intentionally ramp up usage in Azure under a ULA to maximize their benefits at certification. Conversely, if you intend to move away from Oracle and not renew the ULA, ensure you can reduce or eliminate those Azure instances by then, or be prepared to buy licenses for them after the ULA ends. Do not use license-included options during a ULA for covered products – that would be wasting your unlimited rights (paying extra when you already have rights to use any quantity).
Q6: How does Oracle licensing on Azure compare to AWS in terms of BYOL vs included?
A: They’re similar with slight differences in what’s offered. Both Azure and AWS are “authorized cloud environments” with the same vCPU counting rules for BYOL. AWS has an Oracle RDS service, which offers license-included for Oracle Standard Edition on RDS (but not EE; EE on RDS is BYOL only). Azure’s equivalent managed service is Oracle Database@Azure, which offers both EE and others with license-included or BYOL. Azure doesn’t have an RDS-like service of its own for Oracle aside from the Oracle partnership. The economics are analogous: in any cloud, BYOL saves money in the long term if you have high usage, whereas license-included is about convenience and short-term use. One notable difference: Oracle Cloud (OCI) is Oracle’s platform, where BYOL is even more favorable (1 license covers 2 OCPUs, effectively one license per 2 cores, which is double the benefit of Azure/AWS). But that’s if comparing clouds. Between Azure and AWS, for instance, the decision might come down to other factors since licensing policy is not a big differentiator now that Oracle recognizes both. Azure’s Oracle partnership is unique in that Oracle itself is running services in Azure data centers, which could appeal if you want an Oracle-managed experience without leaving Azure.
Q7: If we use license-included software and then later purchase licenses, can we receive credit for the rental fees we paid?
A: Not from Oracle directly. Oracle won’t say, “You’ve paid us a lot in hourly fees, here’s a discount on a license”. However, you might negotiate with Oracle or Microsoft for some concessions if, for example, you decide to convert a large workload to BYOL. Microsoft might help via Azure credits, or Oracle might be willing to backdate a ULA start. These are case-by-case and not guaranteed. Generally, the money spent on pay-as-you-go is gone as operational expense. It’s another reason to plan: try not to overshoot on rental beyond the break-even point. Keep reviewing and make the switch at a logical time (like the end of the quarter or year, when negotiating licenses is easier, and when you can schedule a cutover).
Q8: Is license-included on Azure more expensive than on Oracle’s own cloud (OCI)?
A: Oracle’s pricing strategy on its own cloud tends to be more advantageous for Oracle products. For example, Oracle offers Oracle Autonomous Database on OCI at certain rates and gives support rewards (crediting a portion of spend back against on-prem support). On Azure, Oracle Database@Azure pricing will likely mirror OCI’s public pricing, but possibly with a premium for the Azure integration – exact details depend on your Azure agreement. Typically, if pure cost is the only factor, running Oracle on OCI (with BYOL or license-included) could be cheaper due to Oracle’s incentives. However, many enterprises choose Azure for strategic reasons (existing Azure spend commitments, integration with Azure services, etc.). It’s worth pricing both if you are cloud-agnostic. Some businesses run primary databases on OCI for cost and DR or apps on Azure; others keep everything in Azure for simplicity, accepting a bit higher cost.
Q9: We have Microsoft SQL Server expertise – should we avoid Oracle licensing altogether by migrating to SQL on Azure?
A: This is a broader strategic question. Suppose the application can run on SQL Server (not all can – custom apps can be rewritten, COTS apps might only support Oracle), and you want to eliminate Oracle licensing. In that case, Azure provides a great platform for SQL Server, offering hybrid benefits, and more. We’ve seen companies migrate smaller Oracle workloads to avoid ongoing Oracle costs. However, for large mission-critical systems that heavily utilize Oracle features, a migration may be costly or risky. A middle ground could be: new applications – consider avoiding Oracle if you want to minimize future licensing headaches on Azure; existing Oracle apps – optimize the licensing via BYOL or ULAs. Over time, some CIOs aim to reduce dependency on Oracle to cut costs, but that’s often a long-term application strategy, not just a licensing switch. From a pure licensing cost perspective on Azure, yes, running on SQL or open-source databases can be significantly cheaper; however, ensure the technology aligns with the need.
Q10: Does Oracle audit cloud usage differently than on-prem?
A: Oracle’s License Management Services (LMS) will audit customers’ overall usage, which includes cloud deployments. In the past, audits were primarily data center-focused, but now Oracle often requests information about any public cloud instances. They may request Azure subscription details or screenshots from Azure that show VM configurations, etc. It’s important to manage tags and records to distinguish Oracle workloads. One advantage is that Azure’s records (like Azure Resource Graph or inventory) can help you precisely show what was deployed and when. Be prepared to demonstrate that each Oracle installation on Azure is either accounted for by a license or was paid via Azure (license-included). Oracle cannot directly “audit” Microsoft’s back-end, but they will audit you, and you must provide evidence. Having clear internal documentation (e.g., an Excel or SAM tool listing all Oracle instances, their license assignment, or noting “paid via Azure service”) will make an audit go much smoother. So, the audit process is similar, but you have more usage flexibility, which means you also need strong internal controls to prevent accidentally spinning up unlicensed Oracle instances in the cloud.
Read more about our Oracle License Management Services.