Oracle Cloud@Customer Licensing: Metering and Risk

What Cloud@Customer is

Oracle Cloud@Customer places OCI managed hardware, most often an Exadata rack, inside your own data centre while Oracle continues to operate the control plane remotely. It exists to satisfy data residency, latency, and regulatory constraints that prevent a workload moving to a public region, yet it is licensed as a cloud service rather than as on premise kit. That dual nature, physical machine on your floor but cloud metering on the meter, is the single fact that drives every licensing decision in this article and is the most common source of confusion among buyers approaching the Oracle OCI licensing model for the first time.

The practical consequence is that the on premise rulebook does not apply. There is no core factor table to reduce the licence count, no soft partitioning argument to bound it, and no perpetual entitlement implied by the hardware. What governs the bill is the number of OCPUs you activate on the rack and the model you elect to pay for them. Treating the machine as if it were a server you bought outright is the error that turns a clean deployment into an exposure.

Cloud@Customer is sold against a Universal Credits commitment, the same currency that funds public OCI consumption. The rack is delivered with a maximum core capacity, and you draw down credits as you activate OCPUs against database and infrastructure services on it. Understanding that the rack capacity is a ceiling, not an entitlement, is the starting point for sizing the commitment correctly.

How Cloud@Customer is metered

Metering follows the OCI rule precisely: each activated OCPU of an Oracle Database service requires one Enterprise Edition processor licence under BYOL, or is bundled into the per OCPU rate under License Included, with no core factor applied. The Exadata rack arrives with a fixed number of physical cores, but you activate them in increments, and you are metered on the activated count rather than the installed count. A quarter rack with 100 usable OCPUs that runs 40 active OCPUs is metered on 40.

Because activation is online and elastic, the same scaling discipline that governs public OCI applies here. Activating OCPUs to meet a quarter end peak raises the metered count immediately, and under BYOL it raises the entitlement you must hold at that instant. The governance control is to treat every activation as a licence event checked against held entitlement before it is actioned, exactly as set out for public compute in the cloud and OCI licensing practice.

BYOL or License Included on the rack

The model election is identical to public OCI. Under BYOL you supply owned, supported Enterprise Edition licences and pay a reduced per OCPU infrastructure rate; under License Included Oracle bundles the database licence into a higher per OCPU rate. The hardware on your premises does not change the calculation, because you are paying for the metered service either way.

For most Cloud@Customer buyers the workload is a migration of an existing on premise Exadata or Database estate, which means owned licences are usually already in hand. That tilts the economics toward BYOL, provided the licences are on active support and genuinely free for redeployment. Where the deployment is net new capacity with no spare entitlement, License Included avoids a fresh perpetual purchase and is often cheaper over a three year horizon. Price both against the activated OCPU plan before committing.

Database options on the rack

Database options and management packs ride on the activated OCPU count just as they do on public OCI, so they multiply the per OCPU cost. Under BYOL, every option enabled across the active OCPUs needs its own per OCPU entitlement; under License Included, options arrive bundled in the higher service tiers that carry a higher per OCPU rate. Exadata Cloud@Customer also bundles several options that would be separately licensable on generic infrastructure, which is part of its value, but the bundle still scales with activated OCPUs. The full option mechanics carry over from Exadata Cloud Service, where the same engineered system logic applies.

The buyer discipline is to confirm exactly which options the chosen service tier includes and to avoid enabling options outside the bundle without a matching BYOL entitlement. An option switched on for a single tuning exercise and left enabled is the classic finding, and on a rack metered by activated OCPUs the exposure compounds across every active core.

The on premise audit risk

The defining risk of Cloud@Customer is that the rack lives in your data centre, where your own teams can reach it, while the licensing model assumes cloud discipline. Local administrators accustomed to on premise freedom may activate OCPUs, enable options, or stand up additional databases without recording the licence consequence. Because Oracle operates the control plane, the activation telemetry exists, and a review can reconcile what was activated against what was entitled. That combination, local human behaviour against cloud grade metering, is precisely where exposure accrues.

The defence is a dated reconciliation of activated OCPUs, enabled options, and database count against held entitlement, maintained as actively as you would for any audited estate. Cloud@Customer does not reduce audit risk simply because Oracle manages the hardware; it relocates the risk to activation governance. Practices that run a disciplined database licensing baseline find the rack easy to defend, while those that treat it as managed and therefore unmonitored find the opposite.

Cloud@Customer versus ExaCS

Exadata Cloud Service in a public region and Exadata Cloud@Customer share metering and model rules; the difference is location and the constraints that drive it. ExaCS sits in an Oracle region with no residency control; Cloud@Customer sits on your floor and answers data sovereignty, latency, and air gap requirements. The licensing is the same per activated OCPU, so the choice is an infrastructure and compliance decision, not a licensing one, beyond the fact that on premise location reintroduces local administrative access and the governance burden that comes with it.

Where a workload has no residency constraint, the public ExaCS option removes the local access risk entirely and is usually simpler to govern. Reserve Cloud@Customer for the workloads whose constraints genuinely require the rack to be on your premises, and apply public OCI governance to it regardless.

How to govern the estate

Governance for Cloud@Customer is a short, repeatable list. Size the Universal Credits commitment to the realistic activated OCPU plan, not the installed ceiling. Elect BYOL or License Included per workload after pricing both. Confirm the option bundle for the chosen tier and block out of bundle options without entitlement. Treat every OCPU activation as a licence event checked before action. And reconcile activated OCPUs, options, and database count against entitlement on a dated schedule. Each control is small; together they keep a rack defensible.

The reconciliation is the load bearing control, because the rack's on premise location is what makes silent drift possible. A dated record of activation against entitlement is what an audit reads as governance, and building it is the practical work the cloud desk performs alongside any Cloud@Customer migration. For estates moving from on premise Exadata, that same record also supports the eventual model re election as workloads stabilise.

The buyer side view

Cloud@Customer is a cloud service that happens to live in your data centre, and it must be governed as one. Meter on activated OCPUs, not installed cores; elect BYOL or License Included per workload after pricing both; confirm the option bundle and block out of bundle enablement; and keep a dated reconciliation of activation against entitlement, because local access makes drift easy. The rack's location buys residency and latency, not relief from licensing discipline. To size a Cloud@Customer commitment or reconcile an existing rack, request a consultation.