Licensing Oracle Cloud at Customer vs Oracle OCI

Licensing Oracle Cloud at Customer vs Oracle OCI

Oracle’s Cloud@Customer and public Oracle Cloud (OCI) share the same technology stack. Still, there are important differences in software licensing policies and pricing between running workloads on Cloud@Customer vs in Oracle’s public cloud.

This article compares how licensing works in each model, including BYOL (Bring Your Own License) and license-included options, support implications, and any restrictions, to help IT decision makers choose the best approach. We will also present a clear comparison table of major differences and discuss which model fits different enterprise scenarios.

Overview: Cloud@Customer vs OCI Licensing

Oracle Cloud at Customer is essentially an extension of OCI into the customer’s data center. As such, Oracle tries to keep the licensing model consistent with OCI public cloud to make migrations and hybrid deployments easier. In both environments, you have two main licensing approaches for Oracle software:

• Bring Your Own License (BYOL): You use your existing Oracle software licenses (e.g., Database, WebLogic, etc.) on the cloud infrastructure. Oracle then only charges for the cloud resources (compute, storage) at a reduced rate because you’re covering the software license yourself.
• License-Included (Subscription): You pay for Oracle software as part of the cloud service on a subscription basis. Oracle provides the licenses on demand, and the cost of those licenses (and support) is included in the hourly rate for that service.

Both Cloud@Customer and OCI support these models, but there are some policy nuances to be aware of:

• License Portability: In OCI (public cloud), Oracle explicitly allows customers to apply their on-prem licenses to equivalent cloud services (BYOL), often with specific core-to-OCPU conversion ratios. The same BYOL rules apply to Cloud@Customer – Oracle considers Cloud@Customer an extension of OCI, so your Oracle licenses can be used under the same terms. For instance, an Oracle Database Enterprise Edition processor license can cover two OCPUs in the cloud (because Oracle counts an Intel core with hyper-threading as two virtual CPUs). This 2:1 licensing conversion applies in both environments.
• Included Licensing Availability: In OCI public cloud, many services offer a license-included option (for example, you can launch an Oracle Database instance “license-included” and pay per hour, even if you own no Oracle licenses). In Cloud@Customer, license-included options exist, particularly for database services (Exadata Cloud@Customer can be subscribed to with licenses included in the rate). However, some Cloud@Customer deployments tend to use BYOL by default (for example, Compute Cloud@Customer mainly provides IaaS where you deploy software; Oracle isn’t automatically licensing things like WebLogic for you unless you explicitly use an OCI PaaS service on it). Initially, Exadata Cloud@Customer was offered primarily as BYOL (requiring customers to bring DB licenses), but now Oracle gives the choice of license-included for database and other software on Cloud@Customer.
• Contract Commitments: A key difference is that Cloud@Customer requires a term commitment (e.g., four or 5-year subscription for the infrastructure) and often a minimum spend commitment. OCI public can be used on a pay-as-you-go basis or with shorter-term commitments. This doesn’t directly change license rules, but it means in Cloud@Customer, you’re planning license usage over a longer term on fixed capacity. In OCI, you could spin up a licensed service for an hour and shut it down. For example, with Cloud@Customer, if you subscribe to an Exadata system license, you’re effectively committing to those licenses included for the subscription term.

Read Oracle Exadata Cloud at Customer Optimization.

BYOL in Cloud@Customer vs OCI

Bring Your Own License works similarly in both environments, allowing you to leverage existing investments in Oracle software:

• In either case, you must maintain active support contracts for any licenses you bring to the cloud. Oracle’s policy requires that BYOL users certify they have sufficient licenses with active cloud usage support. If you stop paying support on an on-prem license, you technically lose the right to use it for BYOL in the cloud.
• Counting Cores/OCPUs: Oracle uses the same core factors and OCPU definitions in Cloud@Customer as in OCI. For x86 CPUs, 1 Oracle Processor license covers 2 OCPU cores in the cloud. So if you deploy a VM with 4 OCPUs on either OCI or Cloud@Customer, you need two processor licenses (assuming a core factor of 0.5 for Intel). This parity means your compliance calculations are the same in both models.
• License Certification: In OCI, when using BYOL for a service like Autonomous Database, Oracle typically asks you to confirm you have the required licenses. Cloud@Customer is no different – you will attest that you own the licenses for running Oracle Database on a Cloud@Customer VM. Oracle trusts the customer to comply, but in the event of an audit, they could check your Cloud@Customer usage against your entitlements.
• Supported Products for BYOL: In public OCI, databases and many products (WebLogic, Oracle Analytics Server, etc.) have BYOL programs. On Cloud@Customer, you can BYOL for any Oracle software you run on the infrastructure. For example, if you run Oracle Database on Exadata Cloud@Customer VMs, you can choose a BYOL deployment (and get charged the lower BYOL rate per OCPU). If you run WebLogic Server on a Compute Cloud@Customer VM, you must apply your WebLogic licenses to those cores (Oracle doesn’t “meter” WebLogic usage, but you must remain compliant). The key point is that Cloud@Customer gives you a controlled environment, but it’s still your responsibility to track BYOL usage, just as it does in OCI.
• Edition and Option Restrictions: BYOL only covers what you’re entitled to. In OCI, if you deploy an Autonomous Database with BYOL, you must own Oracle Database Enterprise Edition plus any options that Autonomous includes (or at least equivalent to the “High Performance” package). Similarly, on Cloud@Customer, if you BYOL to Exadata, your licenses must include the options you intend to use (e.g., Partitioning, Advanced Security, etc.). If not, you either disable those features or use the license-included features. Standard Edition: Notably, Oracle Exadata Cloud@Customer supports Enterprise Edition only. You cannot use Oracle Database Standard Edition licenses on Exadata Cloud@Customer because Exadata hardware doesn’t meet Standard Edition’s restrictions (SE2 is limited to smaller server sizes). In OCI public, you could use Standard Edition on a small VM DB instance. So, one difference: Cloud@Customer (Exadata flavor) effectively requires Enterprise Edition licenses, whereas OCI gives you more freedom to deploy Standard Edition on suitable shapes. For other products, the rules are similar across environments.

License-Included (Subscription) Differences

You pay a higher rate with Oracle’s license-included model, but Oracle provides the license and support.

Key comparisons:

• Pricing Differences: Oracle uses the same list prices per OCPU or hour for license-included services in both Cloud@Customer and OCI. For example, an Oracle Database Enterprise Edition license included in OCI might be ~$0.672 per OCPU-hour (annual rate), and on Exadata Cloud@Customer, it’s the same order of magnitude. The difference is that on Cloud@Customer, you’re also paying for the hardware subscription. But the software surcharge (the portion of the fee attributable to the Oracle license) is essentially equal. There is no “on-prem penalty” for license-included cloud usage; Oracle wants the pricing to be predictable. However, Cloud@Customer may require a minimum license-included usage commitment depending on your contract (since you sized a machine for it).
• Flexibility: In OCI, you can start or stop a license-included instance at will. In Cloud@Customer, you can similarly scale the usage up or down (even to zero, as Oracle now allows pausing services), which stops incurring license charges. But if you have a long-term Cloud@Customer contract with a license included, you’ve likely committed to some baseline usage. For instance, if you subscribed to an Autonomous Database on Cloud@Customer with a 16 OCPUs license included, you might be paying for those whether you use them or not (depending on the contract). Ensure your Cloud@Customer agreement allows elasticity; newer contracts tie license-included billing purely to actual usage, just like OCI, but an older arrangement might have had a fixed monthly license bundle.
• Support Coverage: In license-included, Oracle Cloud covers support. This is a big benefit if you didn’t already own licenses. In OCI, if you spin up a license-included DB, Oracle handles support for that service as part of cloud support. The same applies to Cloud@Customer – Oracle’s Cloud Ops and support teams handle the software support (patches, troubleshooting) up to a certain level. You do not need a separate support contract for licenses you don’t own. One difference: on Cloud@Customer, support may involve Oracle remotely managing/patching the system via secure tunnels since it’s your data center. Oracle treats it as if it’s their cloud region in terms of support responsibility. As a customer, you call Oracle support for issues just like with OCI. BYOL, on the other hand, requires you to maintain your support contract, and you may need to apply patches or updates in coordination with Oracle (for example, Oracle manages the infrastructure, but you are responsible for staying within compliance for database versions that your support covers, etc.).
• License Scope: License-included offerings in OCI are well-defined: e.g., “ATP Database – includes all relevant DB options” or “Oracle Integration Cloud – license included for the integration platform”. On Cloud@Customer, almost all the same services are available (especially if you have a Dedicated Region, all OCI services are available with license-included options). But if you have only a subset like Exadata Cloud@Customer or Compute Cloud@Customer, the license-included choices are naturally limited to what those platforms offer (Exadata C@C offers DB license-included; Compute C@C itself doesn’t provide an Oracle software service, except you could use Autonomous Database on it if Oracle enables that). In summary, OCI public has the full gamut of services/license-included options at your fingertips; Cloud@Customer will match that if you have a Dedicated Region, but if you only have a specific service on-prem, your license-included scope is that service.

Other Considerations

• License Mobility (90-day Rule): Oracle’s standard license agreement states that licenses can’t be reassigned more often than every 90 days. In a strict sense, if you move a license from on-prem to OCI, you should keep it there for at least 90 days. However, using BYOL in Oracle’s cloud is generally considered an extension of your environment. Oracle has not rigidly enforced the 90-day transfer rule for moving into Oracle Cloud, especially for Cloud@Customer, which is on-prem hardware. Cloud@Customer is in your data center, so one could argue that you aren’t “transferring” the license to a third-party environment. However, Oracle contracts treat Cloud@Customer the same way OCI (a cloud service) does. The practical upshot: you can fairly fluidly allocate licenses to cloud instances as needed, but you shouldn’t frequently flip licenses back and forth between on-premises and cloud to avoid compliance issues in both OCI and Cloud@Customer, plan license assignments in alignment with the 90-day guideline to be safe.
• Unlimited License Agreements (ULA): If your company has an Oracle ULA (unlimited license agreement) or other enterprise license, how it applies can differ. Usually, ULAs cover on-prem use and can be certified and counted towards cloud usage if allowed. OCI public usage typically does not count against a ULA unless the ULA explicitly includes cloud use. Cloud@Customer is a gray area – since hardware is on-prem, one might think a ULA covers it, but because it’s an Oracle-managed cloud service, Oracle’s contract might exclude Cloud@Customer from ULA use by default. Many enterprises negotiate ULA amendments to allow Cloud@Customer consumption. In short, verify your ULA terms: you might need to add Cloud@Customer as an included environment. This is a contractual distinction, not a technical one, and it’s the same conversation whether you want to use a ULA on OCI or Cloud@Customer.
• Third-Party Licensing: This article focuses on Oracle licenses, but note that on Compute Cloud@Customer, you might run non-Oracle software (Microsoft, IBM, etc.). Those licenses follow their rules (e.g., Microsoft typically treats Cloud@Customer as on-prem hardware from a licensing perspective, which can be an advantage over public cloud). So Cloud@Customer can help with other licensing, too, but that’s beyond our scope.

Now, let’s summarize the key differences in a table and discuss which model suits which scenarios.

Comparison Table: Cloud@Customer vs OCI Licensing

Which Model is Better for You?

Choosing between Cloud@Customer and OCI (and BYOL vs included) depends on your enterprise’s needs:

• Data Residency and Latency: If your organization has strict data residency requirements, latency-sensitive workloads, or cannot use public cloud due to regulatory reasons, Oracle Cloud@Customer is the clear choice. It allows you to keep data on-premises while still using cloud services. OCI public would not meet these needs unless a specific Oracle region is certified for your data (and even then, some regulators prefer on-prem). For example, a government agency or a bank might choose Cloud@Customer to run databases on-prem for compliance, even if it’s slightly more complex to manage licensing.
• Existing Oracle Investment (BYOL Heavy): If you already own a large number of Oracle licenses (database, etc.) and have an established on-prem environment, you might lean towards Cloud@Customer so you can redeploy those licenses in a cloud model on hardware dedicated to you. Cloud@Customer essentially “monetizes” your existing support fees by lowering the cloud cost (BYOL rates are much cheaper). In OCI public, you can also BYOL, but you might be concerned about moving critical systems off-premises. With Cloud@Customer, you get cloud automation but can confidently apply all your licenses in an isolated environment. Companies with ULAs or lots of spare licenses often find Cloud@Customer appealing to avoid wasting those entitlements. That said, if you have a lot of licenses and no strict residency requirement, OCI public might be simpler (no hardware overhead).
• Cost and Scale Flexibility: OCI public cloud is more cost-effective and flexible for small-scale needs or highly variable workloads. Cloud@Customer has a higher entry cost (you’re paying for an entire rack regardless of whether you use it fully or not) and a long-term commitment. If your needs are modest – e.g., a handful of VMs or one Oracle database – the public cloud on a pay-as-you-go basis will almost always be cheaper and easier. OCI also shines for elastic scale: if you suddenly need to double capacity for a week, it’s trivial in the public cloud. On Cloud@Customer, scaling beyond your on-prem hardware’s capacity could take weeks (Oracle would have to add hardware). So, for dynamic workloads or unpredictable growth, OCI is preferable. Example: A startup or a dev/test environment that you spin up and down – OCI wins. Cloud@Customer is aimed at steady, mission-critical production loads that justify a fixed capacity on-premises.
• Performance and Control: Some customers want the highest performance (Exadata, bare metal, etc.) with full data control and integration into on-prem networks—Cloud@Customer provides that. OCI can also provide Exadata service, but it’s unavailable in your data center. If you have heavy data interchange between an existing data center and Oracle databases, having the database on Cloud@Customer (local network) avoids the WAN latency. This technical requirement often drives the decision more than licensing differences.
• Multi-cloud and Third-Party Apps: If you have a strategy to run various vendors’ software and maybe mix with other clouds, Cloud@Customer gives you an isolated environment where you can even run non-Oracle workloads on the Compute C@C. OCI public can also run non-Oracle stuff (it’s a general-purpose cloud), but Cloud@Customer might integrate better with your internal security, IAM, and network, which could simplify third-party licensing (like Microsoft Windows licenses on Cloud@Customer might be treated like on-prem usage, which can be advantageous). Enterprises pursuing a hybrid cloud with consistency might choose Cloud@Customer for Oracle workloads and to host some non-Oracle VMs, while also using other clouds, as opposed to pushing everything to Oracle’s public cloud.
• Support and Skills: If your team is already managing on-prem Oracle systems and licenses, Cloud@Customer will feel like an extension – you continue to deal with Oracle support and license compliance in similar ways, just with cloud automation. OCI requires learning Oracle’s cloud management (very similar, but operationally, you relinquish some control to Oracle completely). Some conservative companies feel more comfortable when they can see and physically secure the hardware, even though Oracle manages it – it’s a mindset advantage of Cloud@Customer.

In terms of BYOL vs License-Included:

• If you have the licenses, BYOL is almost always cheaper. Use BYOL in either OCI or Cloud@Customer to reduce costs, but ensure you remain compliant (track usage!).
• Use License-Included when you lack certain licenses or need a quick way to start a new workload without procurement. For example, if you want to test an Oracle Database feature and don’t have that option licensed on-prem, spinning it up license-included in OCI or Cloud@Customer (if available) might be easier than buying a new license.
• Cloud@Customer users often mix models, e.g., using BYOL for their main databases, but they might spin up an Autonomous Database instance license included in an experiment. This hybrid approach is supported.

Case-by-Case:

• Short-term Projects: OCI (no long commitment, use license-included if needed, then shut down).
• Steady long-term Workloads with a large Oracle footprint: Cloud@Customer (especially if data needs to be on-prem), BYOL model to leverage investments.
• Global Company with mixed needs: Possibly both—e.g., keep sensitive core systems on Cloud@Customer in your main data centers, and use OCI public for burst, less sensitive, or global reach services. Oracle offers integration to manage hybrid deployments seamlessly.
• Cost-sensitive, no on-prem necessity: OCI public, possibly with a reserved commitment for lower rates, and maximize BYOL usage to reduce spend.

Read Oracle Dedicated Region Cost Optimization.

In summary, Oracle Cloud@Customer vs. OCI is not an either/or for licensing—they share the same rules largely. The decision comes down to the operational model: on-premises vs. cloud data center, and the scale/commitment. Licensing differences are few: Cloud@Customer essentially mirrors OCI’s licensing flexibility but imposes a committed model and some edition limitations (like no SE on Exadata). OCI public gives ultimate flexibility in scaling and pay-per-use.

Finally, ensure your enterprise has a solid license management process, whichever model you choose. Track what licenses you’ve allocated to cloud instances, keep proofs of entitlement, and educate your teams on not enabling Oracle options/features you haven’t licensed (Oracle will bill license-included usage if you do, or flag compliance issues in BYOL scenarios).

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

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit