Oracle Cloud at Customer gives enterprises the operational model of a managed cloud service with the hardware physically located in their own data centre. But the licensing framework governing what runs on that hardware is anything but straightforward. The difference between a well-structured licence position and a poorly structured one can easily reach seven figures over the life of a contract.

The Fundamental Licensing Decision: BYOL or Licence-Included?

Every Oracle Cloud@Customer deployment begins with a binary choice: Bring Your Own Licence (BYOL) or adopt Licence-Included pricing. This decision has the largest single impact on total cost of ownership of any choice made during Cloud@Customer procurement.

Under BYOL, you apply existing Oracle Database licences — purchased on-premises — to your Cloud@Customer environment. The OCPU hourly rate drops by up to 80% compared to licence-included pricing, because Oracle is no longer bundling software cost into the subscription. For organisations with substantial Oracle Database licence estates and active support contracts, BYOL will almost always deliver lower costs.

Under licence-included, Oracle bundles the database software licence into the subscription fee. This simplifies cost modelling and eliminates the need to track licence utilisation separately, but the per-OCPU cost is significantly higher. Licence-included is the correct model for net-new Oracle workloads where no existing licences exist, or for organisations whose existing licence estate is insufficient to cover Cloud@Customer demand.

BYOL Eligibility and Common Mistakes

Not all Oracle Database licences can be used in a Cloud@Customer BYOL deployment. Oracle's rules are specific, and violations are a primary audit finding in engineered systems environments.

  • Active support required — Only licences with current, paid Oracle support contracts are eligible for BYOL deployment. Licences on third-party support from providers like Rimini Street cannot be used for BYOL on Cloud@Customer without separate negotiation
  • Edition matching — The Oracle Database edition deployed must match the edition of the licence being applied. Deploying Enterprise Edition workloads against Standard Edition licences is a common compliance error
  • Option and pack licences — Oracle Database options such as Advanced Compression, Diagnostics Pack, and Real Application Clusters require separate licences. Many Cloud@Customer customers inadvertently enable these through default configuration settings
  • Processor metric — BYOL in Cloud@Customer uses an OCPU metric that maps to processor licences, but the mapping is not always one-to-one depending on the Oracle processor core factor table. Always verify the conversion before committing OCPUs
"Oracle LMS frequently targets engineered systems customers for audits precisely because the complexity of the environment leads to honest mistakes. A fully populated Exadata environment slightly out of compliance can generate audit findings that reach seven figures."

Compliance Obligations After Go-Live

Cloud@Customer customers face ongoing compliance obligations that differ from traditional on-premises licensing. Oracle retains the right to audit Cloud@Customer environments as part of standard licence agreements, and the telemetry capabilities of the managed service mean Oracle has visibility into usage patterns that it did not have in purely on-premises deployments.

Key compliance disciplines for Cloud@Customer environments include: maintaining accurate OCPU allocation records aligned to active licences; auditing database options enabled by default during provisioning; tracking users and module access for Oracle application workloads; and ensuring that development, test, and production environments are correctly licensed under separate provisions where applicable.

Cost Reduction Strategies for Existing Cloud@Customer Customers

If you are already committed to Cloud@Customer contracts, several optimisation levers remain available. OCPU right-sizing — reducing over-allocated compute resources — can generate immediate monthly savings. Audit of licence-included services that could be converted to BYOL using existing licence capacity often reveals further reductions. Unused Oracle Database options enabled at provisioning time that carry separate licence costs should be disabled if not actively required.

For customers approaching contract renewal, Cloud@Customer renewals are a stronger negotiating position than initial purchases, as Oracle wants to retain the subscription revenue and the account team has a strong incentive to avoid competitive comparison exercises.

Concerned about Cloud@Customer licence compliance?

Redress Compliance provides independent BYOL eligibility assessments and compliance reviews for Oracle engineered systems customers.
Get a Compliance Review →

Get the Full Licensing Guide

The complete Oracle Cloud at Customer Licensing guide includes BYOL eligibility decision trees, the OCPU-to-processor licence conversion framework, compliance checklist, and a worked TCO comparison between BYOL and licence-included scenarios. Download it free using the form on this page.