Exadata Cloud Service Licensing: ExaCS and ExaCC

What is Exadata Cloud Service?

Exadata Cloud Service, or ExaCS, runs the Oracle Exadata engineered system as a managed OCI service, giving the performance of Exadata hardware without owning it. Its sibling, Exadata Cloud at Customer, or ExaCC, places the same Exadata infrastructure inside the customer's own data centre while Oracle operates it as a cloud service. Both are licensed on the same principle, which is what makes them worth treating together within the Oracle OCI licensing model.

The licensing feature that defines Exadata Cloud Service is OCPU scaling. The Exadata infrastructure has a large fixed number of physical cores, but you do not licence all of them. You enable a subset of OCPUs, licence only those, and scale the enabled count up or down as demand changes. This separates the hardware footprint from the licence requirement in a way that a bare metal compute shape does not, and it is the single most important thing for a buyer to understand.

Licensing the enabled OCPUs

On Exadata Cloud Service you provision an infrastructure shape, then enable database OCPUs against it, and the licence requirement tracks the enabled OCPUs only. An infrastructure rack might contain hundreds of physical cores, but if you enable thirty two OCPUs, you licence thirty two, whether by owning thirty two Enterprise Edition processor licences under BYOL or by paying the License Included rate on thirty two. The dormant cores carry no licence cost until you enable them.

This elasticity is a real advantage. A workload with a quarter end peak can scale enabled OCPUs up for the peak and down afterwards, paying licence cost only for the period the cores are active under License Included. Under BYOL the entitlement must cover the peak enabled count, so the same scaling discipline that governs OCI compute applies: licence the ceiling, not the average.

The scaling granularity differs by generation of Exadata infrastructure, so a buyer should confirm the minimum enable increment for the specific rack they provision. Some configurations enable cores in fixed steps rather than singly, which means the practical floor for a small workload may be higher than expected. Knowing the increment before committing the infrastructure avoids the surprise of being unable to scale down below a level that still carries meaningful licence cost.

BYOL or License Included on Exadata

Both models apply to Exadata Cloud Service. Under BYOL, you cover the enabled OCPUs with owned Enterprise Edition licences and the options you own, paying the reduced infrastructure and compute rate. Under License Included, the rate bundles Enterprise Edition and the complete set of database options, which on Exadata is significant because Exadata workloads typically use Real Application Clusters, Partitioning, and several other options as a matter of course.

The option density tilts the decision toward License Included more often on Exadata than elsewhere. A typical Exadata database running RAC, Partitioning, Advanced Compression, the management packs, and Active Data Guard would, under BYOL, require owned licences for each of those across the enabled OCPUs. License Included folds them all into one rate. Only a customer who already owns a deep stack of option licences finds BYOL clearly cheaper, which is why the option position drives the Exadata model choice.

There is a hybrid pattern worth naming: running the base, always on databases under BYOL with owned licences and options, while using License Included for the bursty or newer databases on the same infrastructure. Exadata does not force a single model across the whole rack, so an estate can place each database on the model that suits it. This mixed approach captures the BYOL saving on stable workloads and the option bundling on the rest, and it is frequently the cost optimal answer for a large Exadata consolidation.

How is Exadata Cloud at Customer licensed?

Exadata Cloud at Customer applies the same OCPU based, enable what you use model, but the infrastructure sits in the customer's data centre. The database licensing is identical: you licence the enabled OCPUs under BYOL or License Included, and options follow the same bundling. The difference is location and the data residency and latency benefits it brings, not the licensing mechanics. For a buyer, this means the BYOL versus License Included analysis carries straight across from ExaCS to ExaCC.

The subtlety with ExaCC is that, because the hardware is on premises, customers sometimes assume traditional on premise licensing rules apply, including the core factor table. They do not. ExaCC is a cloud service governed by the cloud policy, so OCPUs are counted under cloud rules with no core factor, exactly as on ExaCS. Misapplying the on premise core factor to ExaCC is a recurring error, and it understates the requirement by half in the same way described in OCPU versus vCPU.

Exadata and Autonomous dedicated

Exadata infrastructure also underpins Autonomous Database dedicated, where Autonomous runs on Exadata reserved for one customer. In that configuration the Exadata infrastructure is licensed as infrastructure and the Autonomous software is metered in ECPUs on top, blending the Exadata model with the Autonomous Database metric. A buyer running many databases on dedicated Exadata gets the management automation of Autonomous with the consolidation economics of a shared engineered system.

The decision between running classic database services on ExaCS and running Autonomous dedicated on the same hardware comes down to how much management you want Oracle to own. Autonomous dedicated automates more and bills in ECPUs; classic ExaCS gives more control and bills in OCPUs. Both sit on the same infrastructure, so the choice is operational, with a metric consequence that should be modelled rather than assumed.

The audit considerations on Exadata

Exadata audit risk concentrates in two places: enabled OCPUs that exceed entitlement under BYOL, and options used beyond what is owned. Because Exadata makes scaling enabled OCPUs trivial, a BYOL deployment can scale past its entitlement during a peak and stay there, accruing a gap. And because Exadata workloads lean heavily on options, an option enabled without a matching owned licence under BYOL is both likely and expensive, given Exadata's typical core counts.

The defence is the same standing reconciliation used across OCI: record the peak enabled OCPU count and every option in use per database, convert to processor licences under the cloud policy, and confirm entitlement covers the peak. Where the option stack is deep, License Included usually removes the risk entirely by bundling, which is often the cleanest audit posture for an Exadata estate. The reconciliation and the model recommendation are the work of the audit defence practice on Exadata accounts.

How to optimise Exadata cost

Optimising Exadata cost rests on the enable what you use principle. Right size the enabled OCPU count to real demand and scale it with the workload rather than enabling the whole rack. Choose License Included where the option stack is deep, BYOL where you own a broad option estate already. Leave dormant cores disabled so they carry no database licence. And size the infrastructure rack to the realistic peak, not the theoretical maximum, since infrastructure is a fixed cost regardless of enabled cores.

The largest single saving usually comes from the option model decision, because Exadata workloads use so many options that bundling versus owning swings the total materially. Getting that decision right, per database, is where the cloud and OCI practice and the database licensing practice add the most value on an Exadata estate.

Infrastructure sizing deserves equal attention to OCPU sizing, because the infrastructure fee is fixed and recurs whether or not cores are enabled. A rack provisioned two sizes larger than the realistic peak carries that excess every month regardless of how carefully the enabled OCPUs are managed. Right sizing the infrastructure to a credible peak, with headroom for genuine growth rather than for a hypothetical maximum, protects the largest fixed line on the Exadata bill.

The buyer side view

Exadata Cloud Service is licensed on enabled OCPUs, not the full rack, so the buyer lever is the enabled count: right size it, scale it with demand, and leave dormant cores disabled. Because Exadata workloads use options heavily, License Included often beats BYOL once every bundled option is priced in. ExaCC follows the same cloud rules despite being on premises, so never apply the core factor. To model the Exadata option and OCPU decision per database, request a consultation.