Oracle Cloud@Customer and OCI public cloud share the same technology stack — but there are important licensing differences. This guide compares BYOL and licence-included models, core counting rules, pricing nuances, ULA implications, edition restrictions, and which model fits different enterprise scenarios.
Oracle Cloud@Customer is essentially an extension of OCI into your data centre. Oracle keeps the licensing model consistent with OCI public cloud to simplify migrations and hybrid deployments. Both environments support BYOL and Licence-Included models.
Oracle explicitly allows on-prem licences to apply to equivalent cloud services (BYOL) with specific core-to-OCPU conversion ratios. The same BYOL rules apply to Cloud@Customer — Oracle considers it an extension of OCI. For example, one Oracle Database EE processor licence covers 2 OCPUs in both environments (Intel with hyper-threading = 2 vCPUs per core).
OCI public offers licence-included for most services. Cloud@Customer also supports licence-included — particularly for Exadata Cloud@Customer database services. However, Compute Cloud@Customer mainly provides IaaS where you deploy your own software, so licence-included only applies to specific managed services (e.g., Autonomous Database). A Dedicated Region offers the full range of licence-included services.
Cloud@Customer requires a multi-year term (typically 4-5 years) with minimum spend commitment. OCI public supports pay-as-you-go or shorter-term commitments (Universal Credits). This doesn't change licence rules, but Cloud@Customer means planning licence usage over fixed capacity for a longer term, whereas OCI lets you spin up a licensed service for an hour and shut it down.
Bring Your Own Licence works similarly in both environments, allowing you to leverage existing Oracle software investments.
In both environments, you must maintain active support contracts for any BYOL licences. If you stop paying support, you technically lose the right to use that licence in the cloud. Oracle requires BYOL users to certify they have sufficient licences with active support.
Oracle uses the same core factors and OCPU definitions in Cloud@Customer as in OCI. For x86 CPUs: 1 Oracle Processor licence covers 2 OCPUs. Deploy a VM with 4 OCPUs on either environment → need 2 processor licences (core factor 0.5 for Intel). Compliance calculations are identical.
In OCI, BYOL for services like Autonomous Database requires confirmation of required licences. Cloud@Customer is identical — you attest to owning licences for running Oracle Database on Cloud@Customer VMs. Oracle trusts customer compliance but can check Cloud@Customer usage against entitlements during audit.
OCI supports BYOL for databases, WebLogic, Oracle Analytics Server, and many other products. Cloud@Customer supports BYOL for any Oracle software you run on the infrastructure. Oracle Database on Exadata Cloud@Customer gets the lower BYOL rate; WebLogic on Compute Cloud@Customer requires your own WebLogic licences applied to those cores.
Exadata Cloud@Customer supports Enterprise Edition only — you cannot use Standard Edition DB licences on Exadata hardware (SE2 is limited to smaller server sizes). In OCI public, you can run Standard Edition on a small VM. Compute Cloud@Customer can run SE databases on VMs as a custom setup, but it's not a managed service. This is one of the few genuine licensing differences between environments.
With the licence-included model, you pay a higher rate but Oracle provides the licence and support. Key comparisons:
Oracle uses the same list prices per OCPU/hour for licence-included services in both environments. There is no "on-prem penalty." However, Cloud@Customer has an additional hardware subscription fee on top of usage costs. Total cost = hardware fee + per-OCPU rate. OCI public bakes infrastructure cost into service pricing with no separate hardware fee.
OCI allows starting/stopping licence-included instances at will — truly pay-as-you-go. Cloud@Customer also allows scaling (even pausing services to stop licence charges), but your long-term contract may include a minimum usage commitment. Newer contracts tie billing to actual usage; older arrangements may have fixed monthly licence bundles regardless of consumption.
In both environments, licence-included means Oracle handles all support — no separate support contract needed. On Cloud@Customer, Oracle's Cloud Ops team manages patching/troubleshooting via secure tunnels since hardware is in your data centre. BYOL requires maintaining your own support contracts and coordinating patches with Oracle's infrastructure management.
OCI public offers the full range of licence-included services. Cloud@Customer scope depends on your configuration: Exadata C@C offers DB licence-included; Compute C@C itself doesn't provide Oracle software services automatically. A Dedicated Region matches OCI's full service catalogue. If you only have a specific C@C service, your licence-included choices are limited to that platform.
Need help choosing between BYOL and Licence-Included for your Cloud@Customer or OCI deployment?
Oracle Licence Management →Oracle's standard agreement says licences can't be reassigned more often than every 90 days. In practice, Oracle hasn't rigidly enforced this for moves into Oracle Cloud — and Cloud@Customer is in your data centre so the argument for "transfer" is weaker. However, Oracle contracts treat Cloud@Customer as a cloud service. Plan licence assignments in alignment with the 90-day guideline to be safe; don't frequently flip licences between on-prem and cloud.
ULAs typically cover on-prem use. OCI public usage usually does not count against a ULA unless explicitly included. Cloud@Customer is a grey area — hardware is on-prem, but it's an Oracle-managed cloud service. Oracle's contract may exclude Cloud@Customer from ULA coverage by default. Many enterprises negotiate ULA amendments to allow Cloud@Customer consumption. Verify your ULA terms and add Cloud@Customer as an included environment if needed.
On Compute Cloud@Customer, you may run non-Oracle software (Microsoft, IBM, etc.). Those licences follow their own rules — but Cloud@Customer can be advantageous: Microsoft typically treats Cloud@Customer as on-prem hardware from a licensing perspective, which can be cheaper than licensing Windows in a public cloud. This is a significant benefit for mixed-stack environments.
| Aspect | Oracle Cloud@Customer | Oracle OCI (Public Cloud) |
|---|---|---|
| Deployment | On-premises (your data centre), hardware managed by Oracle. You "rent" equipment + cloud services. | Off-premises in Oracle's cloud data centres. Multi-tenant environment. |
| Available Services | Depends on offering: Exadata C@C = DB services; Compute C@C = core IaaS; Dedicated Region = all OCI services on-prem. | Full range of OCI services (DB, compute, middleware, SaaS, etc.) available in all public regions. |
| Term Commitment | Multi-year subscription (typically 4-5 years) with minimum spend commitment. | No required term for pay-as-you-go. Discounts for 1-3 year Universal Credits commitments. |
| Infrastructure Cost | Monthly hardware fee (Exadata base system, compute rack) in addition to usage costs. Not paid via Universal Credits. | No separate hardware fee — usage costs cover infrastructure. Infra cost baked into service pricing. |
| BYOL | Fully supported. Same core counting (1 licence = 2 OCPUs on x86). Must maintain support. Common choice to maximise existing investments. | Fully supported. Same core counting and support requirements. Often used to reduce cloud costs with surplus licences. |
| Licence-Included | Available for most Oracle services deployed (Autonomous DB, Exadata DB). Adds to per-hour cost. May require minimum usage commitment in contract. | Available for most OCI services. Truly pay-as-you-go — no long-term commitment required by default. |
| LI Pricing | Same per-OCPU list price as OCI. But total cost includes hardware fee. Typically requires committing to some OCPU/usage level. | Standard OCI pricing. Pay only per-hour rate. Scale to zero with no charges. |
| Scaling | Scale within on-prem hardware capacity. OCPUs can be turned off (zero billing). Cannot exceed physical capacity — adding more requires Oracle hardware installation. | Highly elastic — virtually unlimited capacity. No on-prem constraint. Trivial to double capacity for a week. |
| Edition Support | Exadata C@C: Enterprise Edition only. No Standard Edition on Exadata hardware. Compute C@C can run SE on VMs (custom setup, not managed). | Supports all editions. Standard Edition databases on small VMs. More flexibility for smaller configurations. |
| Support Model | BYOL: maintain your support contracts. LI: Oracle handles everything via Cloud Ops (remote management via secure tunnels). No separate support fee for LI. | BYOL: pay Oracle support as usual. LI: Oracle supports everything. Support baked into service cost. |
| Compliance | Oracle can monitor via cloud control plane. Manage compliance like on-prem — track deployments against licences. Oracle may audit via certification process. | Oracle has full visibility of what you run. Honour system for BYOL with potential audit. Same licence counting rules apply. |
| ULA Coverage | Grey area — may be excluded by default. Negotiate ULA amendments to include Cloud@Customer explicitly. | Typically not counted against ULA unless ULA explicitly includes cloud use. |
For detailed pricing breakdowns, see Exadata Cloud@Customer Optimisation and Dedicated Region Cost Optimisation.
If you have strict data residency, latency-sensitive workloads, or regulatory constraints preventing public cloud use → Cloud@Customer is the clear choice. Government agencies, banks, and healthcare organisations often choose Cloud@Customer for on-premises compliance. OCI public won't meet these needs unless a specific Oracle region is certified for your data.
If you own extensive Oracle licences (database, middleware) with an established on-prem environment → Cloud@Customer lets you redeploy those licences in a cloud model on dedicated hardware. BYOL rates are much cheaper, effectively "monetising" your existing support fees. Companies with ULAs or surplus licences find Cloud@Customer particularly appealing. If you have surplus licences but no residency requirement, OCI public may be simpler (no hardware overhead).
OCI public is more cost-effective for small-scale or variable workloads. Cloud@Customer has higher entry cost (paying for an entire rack regardless of utilisation) and long-term commitment. For modest needs — a handful of VMs or one database — pay-as-you-go OCI is almost always cheaper. OCI also excels for elastic scale: doubling capacity for a week is trivial in public cloud but could take weeks on Cloud@Customer.
For highest performance (Exadata, bare metal) with full data control and integration into on-prem networks → Cloud@Customer provides local-network latency that OCI can't match. Heavy data interchange between existing data centre and Oracle databases benefits enormously from Cloud@Customer proximity.
Cloud@Customer provides an isolated environment for non-Oracle workloads with better integration into your internal security, IAM, and network. Third-party licensing (like Microsoft Windows) may be treated as on-prem usage — potentially cheaper than public cloud licensing. Enterprises pursuing hybrid strategies may use Cloud@Customer for Oracle workloads while mixing other clouds.
You already own Oracle licences. Almost always cheaper — reduced cloud rates since you supply the licensing. Works in both Cloud@Customer and OCI. Ensure you track usage and maintain support compliance. Companies with ULAs or spare licences should default to BYOL.
You lack certain licences or need a quick way to start a new workload without procurement. Testing a feature not licensed on-prem? Spin it up licence-included. Cloud@Customer users often mix models — BYOL for main databases, licence-included for experiments or new services.
| Scenario | Recommended Model | Licensing Approach |
|---|---|---|
| Short-term projects / dev-test | OCI public | Licence-included (no long commitment, shut down when done) |
| Steady long-term workloads, large Oracle footprint | Cloud@Customer | BYOL to leverage existing investments |
| Global company with mixed needs | Both — hybrid | Sensitive systems on Cloud@Customer (BYOL); burst/global on OCI |
| Cost-sensitive, no on-prem necessity | OCI public | Reserved commitment + maximise BYOL to reduce spend |
| Regulated industry (government, banking, healthcare) | Cloud@Customer / Dedicated Region | BYOL or licence-included depending on existing estate |
Need a detailed cost model comparing Cloud@Customer BYOL vs OCI licence-included for your workloads?
Oracle Contract Negotiation →Whether you're evaluating Cloud@Customer vs OCI, transitioning BYOL to the cloud, or negotiating a new Oracle cloud contract, Redress Compliance delivers vendor-independent advisory that saves Fortune 500 enterprises millions.
Also managing Java, middleware, ULA, or support contracts? We cover the full Oracle stack.
All Oracle Advisory Services →