Oracle Cloud at Customer: What It Is, How It Works, and Whether It Makes Sense

What Oracle Cloud at Customer Is — and Is Not

Oracle Cloud at Customer is not a hosted private cloud. It is not a managed service running in a third-party data centre. It is Oracle's cloud infrastructure — the same hardware, software, and services that power Oracle's public OCI regions — physically deployed within the customer's own data centre, co-location facility, or private environment, and managed by Oracle remotely as a cloud service.

The customer provides the physical space, power, cooling, and networking. Oracle provides everything else: the hardware, the cloud software stack, the security patching, the availability management, the SLA guarantees, and the operational support. From the customer's perspective, the experience is that of consuming Oracle Cloud services — provisioning databases, deploying applications, running Autonomous Database — except that all the underlying infrastructure is physically in their own building.

This matters because it changes the data sovereignty equation entirely. In a public cloud deployment, customer data travels to and resides in Oracle's data centres. In Oracle Cloud at Customer, customer data never leaves the customer's physical facility — not even to Oracle's data centres. The hardware, the data, and the workloads remain within the customer's physical perimeter at all times.

The Three Deployment Models

Oracle Cloud at Customer encompasses three products, each with different scope and target use cases. Understanding which model applies to a given requirement is the starting point for any evaluation.

Exadata Cloud@Customer delivers Oracle Database as a managed cloud service on Exadata hardware in the customer's facility. It supports Autonomous Database, the Exadata Database Service, and Oracle Database Base Service. It is exclusively a database service — no general compute, no containers, no platform services. Target customers are Oracle Database-heavy organisations that need Exadata-class performance and Autonomous Database capabilities on-premises.

Compute Cloud@Customer extends the scope to general OCI compute, storage, and Kubernetes. It supports virtual machines, bare metal compute, block and object storage, and Oracle Container Engine for Kubernetes. It does not include Oracle's PaaS services, analytics, or Oracle Fusion Cloud applications. Target customers are organisations that need OCI-compatible application infrastructure on-premises alongside or separate from their database workloads.

OCI Dedicated Region Cloud@Customer delivers the complete OCI service catalogue — 200 or more services — as a self-contained cloud region in the customer's facility. This includes every IaaS, PaaS, and SaaS service available in Oracle's public cloud, including Oracle Fusion Cloud applications. It requires a minimum five-year commitment of approximately $5 million and a minimum three-rack physical footprint. Target customers are organisations with broad, portfolio-wide cloud service requirements that must remain entirely on-premises due to regulation, data sovereignty obligations, or strategic policy.

How Oracle Manages Cloud at Customer Remotely

One of the most common questions from CIOs evaluating Oracle Cloud at Customer is how Oracle manages infrastructure inside the customer's data centre. The answer is that Oracle engineers access the Cloud at Customer systems through a dedicated, separate management network — distinct from the customer's application and data networks. This management path carries only operational telemetry, configuration, and software updates; it never carries customer data.

Oracle applies security patches, infrastructure updates, and software upgrades on a defined maintenance schedule, coordinated with the customer in advance. The customer controls maintenance windows and can defer non-critical updates within defined limits. Oracle's SLA obligations cover availability of the Cloud at Customer services, and credits apply for availability failures within the contracted SLA terms.

The control plane — the software layer responsible for provisioning, managing, and monitoring cloud services — operates differently across the three models. For Exadata and Compute Cloud@Customer, the control plane runs in Oracle's public cloud, and management traffic passes outbound through the customer's network to Oracle's cloud management endpoints. For the Dedicated Region, the control plane runs entirely within the customer's facility, providing complete operational independence from Oracle's public cloud infrastructure.

Who Oracle Cloud at Customer Is For

Oracle Cloud at Customer is not the right choice for every organisation considering Oracle Cloud services. Its economics and complexity are justified in specific circumstances. The primary target profiles are organisations in heavily regulated industries — financial services, government, defence, healthcare, energy — where data residency regulations or security classifications prevent workloads from moving to a shared public cloud facility. These organisations need the operational model of cloud services (managed infrastructure, elastic scale, Autonomous capabilities) but cannot accept the data location risk of public cloud deployment.

A secondary profile is Oracle-heavy enterprises that want to modernise their database infrastructure — moving from customer-managed Exadata to Oracle-managed Exadata Cloud@Customer — without the organisational, compliance, or network architecture changes required for public cloud migration. These organisations get a fully managed, cloud-native Oracle Database experience while keeping their data on-premises and their network architecture unchanged.

Oracle Cloud at Customer is not well-suited for organisations primarily motivated by cost reduction, or for those with limited Oracle Database investment looking for general cloud infrastructure. For cost reduction and general workloads, Oracle's public OCI regions typically provide better economics. The Cloud at Customer premium — facility requirements, minimum commitments, and operational complexity — is only justified when data sovereignty or regulatory requirements make public cloud deployment genuinely impossible or commercially impractical.

Data Sovereignty Use Cases

The Dedicated Region in particular is purpose-designed for the data sovereignty use case. Financial regulators in the European Union, United Kingdom, Australia, and Singapore have all issued guidance or regulations that restrict or prohibit moving certain categories of data or operational systems to shared public cloud facilities. The EU's DORA (Digital Operational Resilience Act) and the EBA's cloud outsourcing guidelines create compliance requirements that many large financial institutions believe are best addressed by keeping cloud services within their own physical infrastructure. Oracle's Dedicated Region is explicitly positioned and marketed for DORA compliance, offering financial services organisations a path to Oracle Cloud services — including Oracle Fusion Finance and HCM — within their own data centres.

What CIOs Must Evaluate Before Committing

Oracle Cloud at Customer represents a significant and long-term commercial commitment. Before signing, CIOs should conduct thorough evaluation across five dimensions.

Genuine business need: Is data sovereignty or regulatory compliance the actual driver, or is this being positioned by Oracle's sales team as a feature rather than a genuine requirement? Many organisations pursue Cloud at Customer conversations without having confirmed that their regulatory environment actually prohibits public cloud deployment. Regulatory analysis should precede commercial evaluation.

Consumption modelling: For the Dedicated Region, the minimum commitment of approximately $1 million per year must be absorbed by actual service consumption. Detailed modelling of planned workloads, database OCPU requirements, storage consumption, and application usage is essential before committing to a minimum that cannot be refunded.

Licensing position: The BYOL vs Licence Included decision has material multi-year financial implications. BYOL is typically the better economic choice for organisations with existing Oracle Database licences, but requires that support remains active — at the standard 8 percent annual increase — for the duration of the commitment. Independent licensing analysis before commitment is essential.

Facility readiness: Oracle Cloud at Customer requires specific power, cooling, and physical space specifications. Facility readiness assessments — confirming that the customer's data centre can accommodate Oracle's hardware requirements — should occur before contract signing, not after.

Contract terms: Oracle's standard Cloud at Customer contracts are commercially structured to favour Oracle — limited exit rights, support fee increase provisions, and no data portability obligations in standard terms. Negotiating improved contract terms — support fee caps, data portability provisions, exit rights, and meaningful SLA credits — before signing is significantly easier than renegotiating after commitment.

Support Costs and the 8 Percent Annual Increase

For BYOL Cloud at Customer deployments, Oracle support fees are a significant and growing cost over the contract term. Oracle's standard support terms permit an 8 percent annual increase, and Oracle applies the full 8 percent increase unless it is explicitly capped in the contract. Over a five-year Dedicated Region commitment, 8 percent annual compounding on a $1 million support base adds approximately $470,000 in incremental support cost above a flat rate over the term.

CIOs should negotiate a support fee cap as part of the Cloud at Customer commercial agreement. A cap of 0 to 2 percent is achievable for large commitments. Oracle's commercial teams will resist but will agree to caps for strategically important deals. The support cap negotiation is most effective when conducted before contract signature — Oracle's leverage is highest after the commitment is signed.