Oracle Cloud at Customer Guide: Complete Enterprise Reference

What Is Oracle Cloud at Customer?

Oracle Cloud at Customer is Oracle's product family for deploying cloud infrastructure and services within a customer's own physical facility — a data centre, co-location facility, or regulated on-premises environment. The defining principle is that the hardware, software, and services operate in a location controlled by the customer, while Oracle manages the cloud layer remotely.

Oracle Cloud at Customer exists to address the core tension that many regulated and data-sovereign enterprises face: the requirement to maintain cloud-grade services while being unable or unwilling to move workloads to a public cloud provider's shared facilities. Regulated industries including financial services, healthcare, government, defence, and utilities are the primary adopters. Oracle Cloud at Customer allows these organisations to consume Oracle Cloud services — including Autonomous Database, Exadata, Kubernetes, analytics, and AI services — while keeping all data and processing within their own physical perimeter.

The Oracle Cloud at Customer family currently encompasses three distinct deployment models, each serving different scale, workload, and service breadth requirements: Exadata Cloud@Customer, Compute Cloud@Customer, and the OCI Dedicated Region Cloud@Customer.

The Three Oracle Cloud at Customer Models

Understanding the differences between the three models is essential before evaluating Oracle Cloud at Customer for any workload. Each model has a distinct scope, architecture, pricing structure, and target use case.

Exadata Cloud@Customer

Exadata Cloud@Customer is Oracle's on-premises deployment of Oracle Exadata, delivered as a fully managed cloud service within the customer's data centre. It provides Oracle Database as a Service — including Autonomous Database, the Exadata Database Service, and Oracle Database Base Service — running on Exadata hardware in a customer-managed rack. Oracle owns the hardware, manages the software, delivers patches and updates, and provides SLA-backed availability, all without the customer needing to own, maintain, or operate the Exadata infrastructure.

Exadata Cloud@Customer is purpose-built for database workloads. It does not support general compute, object storage, container orchestration, or platform services. Customers who need Oracle's highest-performance database service on-premises, with Autonomous Database capabilities and Oracle-managed infrastructure, and whose workload profile is database-centric, will find Exadata Cloud@Customer the optimal model.

Pricing for Exadata Cloud@Customer is split into an infrastructure subscription fee charged per system configuration (a Base System in the current X10M generation costs approximately $8,000 per month for the infrastructure layer) and a consumption-based charge for actual database compute used, priced per OCPU-hour at approximately $1.344 per OCPU-hour at list price, or approximately $0.672 on an annual universal credit commitment. Storage capacity is included within the Exadata system configuration. Oracle manages the system remotely, applying updates and patches on a defined maintenance schedule.

Compute Cloud@Customer

Compute Cloud@Customer extends Oracle's OCI compute and storage services to an on-premises rack. It provides OCI virtual machines, bare metal compute, block storage, object storage, container instances, and Kubernetes — the core IaaS and container layer of OCI — within the customer's facility. Unlike Exadata Cloud@Customer, Compute Cloud@Customer supports general-purpose application workloads, not just databases.

Compute Cloud@Customer requires connectivity to Oracle's public cloud for its control plane operations — management, provisioning, and updates are coordinated through Oracle's public cloud region. This connectivity requirement means that Compute Cloud@Customer is not suitable for fully air-gapped environments that must operate without any external network connection. For environments that permit managed outbound connectivity to Oracle while keeping data on-premises, Compute Cloud@Customer provides a compact and cost-effective on-premises cloud infrastructure layer.

The physical footprint of a Compute Cloud@Customer system is a single rack containing approximately 192 OCPUs of compute capacity, expandable through additional rack units. Pricing follows a subscription model with a fixed monthly rack fee plus consumption charges for the OCI services consumed within the rack.

OCI Dedicated Region Cloud@Customer

The OCI Dedicated Region is the most comprehensive Oracle Cloud at Customer offering — a full Oracle Cloud region deployed on-premises. Unlike Exadata and Compute Cloud@Customer, which provide targeted service subsets, the Dedicated Region delivers the complete OCI service catalogue: compute, storage, networking, Oracle Database services, Autonomous Database, Kubernetes, API Gateway, analytics, AI and machine learning services, and Oracle Fusion SaaS applications.

The Dedicated Region is architecturally self-contained. The control plane, management infrastructure, and all service APIs operate entirely within the customer's facility — there is no dependency on Oracle's public cloud for normal operations. Oracle manages the region remotely through a dedicated operations team, delivering a fully managed cloud region experience while all data, control, and operations remain within the customer's physical boundary.

The Dedicated Region's minimum physical footprint has been significantly reduced in recent product generations. The current Dedicated Region 25 offering starts at approximately 3 racks, compared to the earlier requirement for 50 or more racks, making it accessible to a wider range of data centre environments. Scale is flexible, expanding up to 450 racks as requirements grow.

The entry commitment for a Dedicated Region is approximately $5 million over a five-year term, making it a significant investment appropriate for organisations with broad, portfolio-wide cloud service requirements that must remain on-premises.

Architecture and Data Sovereignty

The central architectural distinction of Oracle Cloud at Customer is data localisation: all data, compute, and processing remains within the customer's data centre. For organisations subject to data residency regulations — GDPR, NIS2, DORA, ITAR, FedRAMP equivalents, and national data sovereignty frameworks — this eliminates the core compliance risk associated with public cloud migration.

How Oracle Manages Remote Infrastructure

Oracle's Cloud at Customer infrastructure is managed remotely by Oracle's operations teams using dedicated management networks separate from the customer's data traffic. Oracle engineers can apply updates, patches, and configuration changes without direct physical access to the customer's facility after initial installation. The customer controls the physical security, networking external to the rack, and the facility itself. Oracle controls the cloud software stack.

This division of responsibility is clearly defined in Oracle's Cloud at Customer agreements: Oracle is responsible for hardware maintenance, software currency, security patching, and service availability (governed by Oracle's SLA); the customer is responsible for physical facility standards including power, cooling, physical security, and network connectivity to Oracle's management endpoints.

Connectivity Requirements by Model

Exadata Cloud@Customer and Compute Cloud@Customer both require outbound connectivity to Oracle's public cloud for control plane operations. This connectivity carries management traffic (configuration, updates, monitoring telemetry) but not customer data traffic, which remains entirely within the on-premises environment. Bandwidth requirements are modest — typically a redundant pair of 1Gbps connections is sufficient — but availability and reliability of this connection directly affect Oracle's ability to manage and patch the system.

The Dedicated Region operates with a local control plane and does not require constant connectivity to Oracle's public cloud for its core operations. However, Oracle's remote management team does require network access for operational management and updates. The nature of this access is defined in the service agreement and typically consists of a dedicated, monitored management path separate from the customer's internal network.

Use Cases and Target Environments

Oracle Cloud at Customer is not the right solution for every enterprise considering cloud services. Its value is highest in specific combinations of regulatory environment, workload profile, and existing Oracle investment.

Regulated Industries with Data Sovereignty Requirements

Financial services organisations subject to regulations that prohibit or restrict transferring data to shared public cloud environments are the most common Dedicated Region adopters. Central banks, sovereign wealth funds, tier-1 retail banks, insurance groups, and pension funds that require complete on-premises data residency with cloud-grade managed services and Oracle Fusion Cloud applications represent the core Dedicated Region use case. Oracle explicitly markets the Dedicated Region to meet the requirements of EU financial regulation including DORA (Digital Operational Resilience Act) and EBA outsourcing guidelines.

Government agencies and defence organisations with classified or sensitive workloads have similar requirements. Exadata Cloud@Customer is widely deployed in government data centres for Oracle database consolidation, providing Autonomous Database capabilities within security-classified environments that cannot connect to public cloud services.

Oracle-Heavy Database Consolidation

For organisations with large Oracle Database estates running on ageing Exadata hardware that is approaching end of life or no longer supported, Exadata Cloud@Customer provides a migration path to Oracle-managed infrastructure without moving data off-premises. The transition from customer-managed Exadata to Oracle-managed Exadata Cloud@Customer eliminates the DBA infrastructure management burden while maintaining complete data localisation.

This use case is particularly relevant for organisations with Database Machine hardware generations that are approaching end of hardware support, where the capital expenditure of purchasing new Exadata systems can be converted to a managed service subscription with the Cloud@Customer model.

Latency-Sensitive Hybrid Workloads

Applications that require millisecond-level latency to on-premises data sources or back-end systems cannot tolerate the network round-trip to a public cloud region. Compute Cloud@Customer enables running cloud-native application layers (containers, microservices, API gateways) within the same facility as the data tier, eliminating the latency penalty while maintaining a cloud-native development and operations model.

Real-time trading platforms, industrial control systems, and healthcare clinical systems requiring sub-10ms response times are typical Compute Cloud@Customer workloads in enterprises that also have regulatory or data residency requirements preventing public cloud deployment.

Pricing Structure and Cost Considerations

Oracle Cloud at Customer pricing is structured differently from Oracle's public OCI pricing, and the total cost of ownership calculations require careful analysis before commitment.

Exadata Cloud@Customer Pricing

Exadata Cloud@Customer pricing consists of two components. The infrastructure subscription covers the Exadata hardware maintained by Oracle in the customer's facility. For the current X10M generation, a Base System (two database server nodes, three storage server nodes) is approximately $8,000 per month at list price. Larger configurations scale to a Full Rack at approximately $43,200 per month. These infrastructure subscription fees are fixed regardless of how much database compute is consumed on the system.

Database compute usage is charged separately per OCPU-hour of actual consumption. Standard Oracle Database Service on Exadata Cloud@Customer is approximately $1.344 per OCPU-hour at list price, reducible to approximately $0.672 per OCPU-hour on an annual universal credit commitment. Autonomous Database on Exadata Cloud@Customer charges at different rates depending on the workload type (OLTP versus data warehouse).

Dedicated Region Pricing

The Dedicated Region pricing model requires a minimum annual spending commitment against which OCI service consumption is drawn. All OCI services within the Dedicated Region are priced at Oracle's standard public OCI list prices — there is no premium for on-premises deployment. The entry commitment of approximately $5 million over five years ($1 million per year) was significantly reduced from previous generation requirements of $15 to $20 million over five years, making the Dedicated Region viable for a much broader range of organisations.

The commitment must be fully utilised within the agreed term or it represents sunk cost. CIOs evaluating the Dedicated Region must model actual service consumption — compute hours, database OCPUs, storage terabytes, analytics service usage — against the minimum commitment to ensure the commitment will be absorbed in practice.

Hidden Cost Considerations

Beyond Oracle's contracted fees, Oracle Cloud at Customer deployments carry customer-side costs that must be factored into the total cost of ownership. Facility preparation includes power, cooling, and physical space requirements that must meet Oracle's specifications. Networking infrastructure — redundant connections, switches, and management network paths — carries procurement and installation costs. For Compute and Exadata Cloud@Customer, the ongoing cost of maintaining outbound connectivity to Oracle's cloud management endpoints is a recurring operational cost.

Oracle support fees for any on-premises Oracle software licences that continue to exist alongside the Cloud@Customer deployment increase by 8 percent annually. For hybrid environments where Cloud@Customer is deployed alongside continuing on-premises Oracle Database deployments, managing the total support cost trajectory requires explicit attention in the commercial agreement.

Comparing Cloud at Customer to Oracle Public Cloud

The decision between Cloud at Customer and Oracle's public OCI regions is fundamentally a data sovereignty and compliance decision, with cost as a secondary consideration for most adopters. Enterprises that can move workloads to Oracle's public OCI regions typically benefit from greater service breadth, faster access to new features, lower minimum commitment requirements, and elimination of facility and infrastructure management overhead.

Cloud at Customer is justified when regulatory requirements mandate on-premises data location, when network latency requirements preclude public cloud deployment, or when the organisation has made a strategic decision to operate a private cloud model. It is not justified solely on cost grounds — the facility, networking, and operational overhead typically make Cloud at Customer more expensive per unit of service than equivalent OCI public cloud consumption.

Oracle increasingly positions the Dedicated Region as its sovereignty and regulated-industry cloud offering, competing directly with alternatives such as AWS Outposts, Azure Stack Hub, and Google Distributed Cloud. Oracle's competitive argument is that the Dedicated Region delivers a fuller service catalogue than competing on-premises cloud offerings, including Oracle Fusion SaaS applications that have no equivalent in competing on-premises cloud products.

Contract and Commercial Considerations

Oracle Cloud at Customer contracts are structured as multi-year service agreements, typically three to five years for Exadata and Compute Cloud@Customer and five years for the Dedicated Region. The contract terms are distinct from Oracle's standard OCI public cloud agreements, and several areas require specific attention in negotiation.

The minimum commitment amount must be tied to clearly defined service consumption baselines. CIOs should insist on modelling exercises that demonstrate credible consumption paths to the committed amount before signing. Oracle sales teams are motivated to secure commitment signatures — independent analysis of whether the commitment level is achievable given the organisation's workload and growth plans is essential.

Exit provisions are limited in standard Oracle Cloud at Customer agreements. Because Oracle owns and operates the infrastructure in the customer's facility, removing the service involves Oracle physically retrieving its hardware — a process that requires advance notice periods and data migration planning. CIOs should negotiate explicit data portability provisions, migration assistance obligations, and reasonable notice periods before commitment.

Oracle's fiscal year ends May 31, making March to May the period when Oracle's commercial team is most motivated to close Cloud at Customer deals. Significant pricing concessions, extended commitment terms, and added service commitments are most achievable in this window.