Organizations increasingly want the scalability, automation, and consumption-based economics of public cloud without necessarily moving every workload and dataset to a public cloud region. This is particularly important for organizations dealing with strict data residency requirements, regulatory obligations, sensitive workloads, low-latency requirements, or dependencies on existing on-premises systems.
Oracle Cloud@Customer addresses this requirement by bringing Oracle cloud infrastructure and services into a customer’s own data center. Depending on the Cloud@Customer offering, organizations can run compute, database, or broader OCI workloads on infrastructure deployed at their premises while using Oracle cloud operating models, management capabilities, and services.
This makes Cloud@Customer an important option for organizations pursuing a hybrid, distributed, or sovereign cloud strategy rather than choosing exclusively between traditional on-premises infrastructure and a public cloud.
Key Takeaways
|
Oracle Cloud@Customer is a family of Oracle cloud services that allows organizations to run selected Oracle cloud infrastructure and services in their own data centers. It is designed for organizations that want cloud capabilities while keeping workloads and data close to their users, systems, and physical location.
The specific capabilities depend on the Cloud@Customer offering. For example, Compute Cloud@Customer provides OCI compute, storage, and networking services on-premises, while Oracle Exadata Database Service on Cloud@Customer brings Exadata-based database services into the customer’s data center. Oracle also offers Dedicated Region, which provides an Oracle-operated OCI cloud region in a customer-selected location.
The basic concept is straightforward:
Public cloud model + customer-controlled physical location = Cloud@Customer
Instead of sending every workload to an Oracle data center, organizations can deploy appropriate cloud infrastructure within their own facilities while retaining cloud-based management and operational capabilities.
For organizations with sensitive Oracle workloads, this can provide an alternative to maintaining conventional, manually managed private infrastructure.
The decision to use Cloud@Customer is usually driven by a combination of data location, regulatory, latency, security, operational, and modernization requirements.
Some organizations need to keep certain data within a specific country, region, or physical facility because of regulatory, contractual, or internal governance requirements.
Cloud@Customer can allow eligible workloads to remain in the organization’s data center while still adopting cloud infrastructure and management practices.
Oracle describes Compute Cloud@Customer as an option for organizations that need to address data sovereignty and regulatory requirements while using OCI identity and governance capabilities.
Highly regulated industries may have requirements governing where data is stored, who can access infrastructure, how systems are operated, and how data is protected.
Cloud@Customer can help organizations design cloud environments around these requirements rather than forcing every workload into a public-cloud deployment model.
However, organizations should not assume that deploying a workload on-premises automatically makes it compliant. Compliance depends on the specific service configuration, controls, processes, certifications, and applicable regulations.
Many enterprises still operate mainframes, manufacturing systems, databases, specialized applications, and other infrastructure in their data centers.
Moving an application to a distant public cloud region can introduce additional network dependencies. Cloud@Customer places supported cloud infrastructure closer to these systems, which can help reduce network distance and latency for appropriate workloads.
This can be particularly valuable for applications that require frequent, high-volume interaction with existing on-premises systems.
Some organizations want more control over the physical location of sensitive data and workloads than a conventional public cloud deployment provides.
Cloud@Customer allows the infrastructure to be deployed within the customer’s facility while retaining cloud-oriented management capabilities.
Cloud adoption does not necessarily mean that an organization has to eliminate its data center immediately.
Cloud@Customer provides another modernization path: organizations can introduce cloud operating models into their existing facilities while continuing to run selected workloads locally.
The exact architecture depends on the Cloud@Customer service, but the general model involves Oracle-provided infrastructure deployed at the customer’s location and connected to the customer’s Oracle Cloud environment or tenancy as required by the service.
For example, Compute Cloud@Customer is installed in the customer’s data center and connected to the organization’s OCI tenancy. Oracle manages the infrastructure, while customers can use OCI interfaces and services to manage supported resources.
This creates an operating model that differs from traditional on-premises infrastructure.
Cloud@Customer is easiest to understand when compared with other deployment models.
| Factor | Public Cloud | Traditional Private Cloud | Oracle Cloud@Customer |
|---|---|---|---|
| Physical location | Provider data center | Customer/third-party facility | Customer data center |
| Cloud operating model | Yes | Depends on implementation | Yes, depending on service |
| Data residency control | Depends on selected region | High | High |
| Infrastructure management | Cloud provider | Primarily customer | Oracle/service-specific model |
| Scalability | High | Depends on infrastructure | Depends on service/configuration |
| Low-latency access to local systems | May require connectivity | Strong | Strong |
| Cloud services | Broad | Depends on platform | Depends on Cloud@Customer offering |
| Best suited for | General cloud workloads | Maximum infrastructure control | Regulated, latency-sensitive, or location-sensitive workloads |
Oracle’s Cloud@Customer portfolio has evolved considerably since the original version of this article was published.
The appropriate service depends on whether the organization primarily needs compute infrastructure, database services, or a broader OCI cloud environment.
Compute Cloud@Customer provides OCI infrastructure services within the customer’s data center.
It supports compute, storage, and networking resources and uses OCI identity and governance capabilities. Oracle manages the underlying infrastructure, while customers manage supported cloud resources through OCI interfaces.
It can be appropriate for organizations that want to run a broad range of workloads on OCI infrastructure while keeping the physical infrastructure within their own facilities.
Compute Cloud@Customer Isolated is designed for environments with particularly stringent sovereignty, security, residency, and connectivity requirements.
It can operate with or without internet connectivity, and its isolated architecture is designed for environments where the infrastructure must remain disconnected from OCI. Oracle describes use cases including government, telecommunications, healthcare, sensitive workloads, and other environments requiring stronger operational or data sovereignty.
This makes it particularly relevant where simply keeping infrastructure physically on-premises is not enough and organizations also require greater control over connectivity and operational boundaries.
Oracle Base Database Cloud@Customer enables organizations to run Oracle AI Database workloads in their own data centers while using OCI to provision, manage, and automate database resources.
Oracle manages the underlying infrastructure, while customers manage their database environments through OCI interfaces. The service is designed for workloads that have requirements around reliability, security, compliance, data residency, and proximity to enterprise data.
For organizations with demanding Oracle Database workloads, Oracle Exadata Database Service on Cloud@Customer combines Exadata capabilities with deployment inside the customer’s data center.
The service is managed through OCI and provides cloud-based management interfaces for database and infrastructure operations.
This can be particularly relevant for mission-critical Oracle Database workloads where organizations want the capabilities of Exadata while keeping the database infrastructure within their own facility.
Oracle Dedicated Region takes the Cloud@Customer concept further by providing an Oracle-operated OCI cloud region in a customer-selected data center.
Unlike a more narrowly scoped Cloud@Customer service, Dedicated Region is intended to provide a broad OCI cloud experience in the customer’s location, including OCI services and cloud operating practices. Oracle states that Dedicated Region is designed to address requirements such as data residency, sovereignty, latency, and operational control.
This option is more appropriate for organizations that require a broader cloud region rather than a specific infrastructure or database service.
1. Keep Sensitive Workloads On-Premises
Organizations can keep eligible workloads and data within their own data center while adopting cloud infrastructure and operating models.
2. Address Data Residency Requirements
Cloud@Customer can support scenarios in which workloads need to remain within a specific geographic or organizational boundary.
3. Reduce Latency to Existing Systems
Applications running close to existing databases, mainframes, manufacturing systems, and other on-premises applications can reduce dependency on long network paths.
4. Adopt Cloud Operating Models
Instead of managing every infrastructure component like traditional on-premises hardware, organizations can use cloud-oriented provisioning, management, automation, and consumption models.
5. Modernize Existing Data Centers
Cloud@Customer can provide a path for organizations that are not ready or able to move every workload to a public cloud region.
6. Support Hybrid Cloud Architectures
Organizations can run some workloads in Oracle’s public cloud regions while maintaining other workloads on Cloud@Customer infrastructure.
Oracle’s Cloud@Customer data-region model allows customers to access Cloud@Customer alongside Oracle Cloud regions and use Universal Credits across the relevant environments.
7. Support Mission-Critical Workloads
Cloud@Customer can be particularly relevant to organizations that cannot easily relocate mission-critical workloads because of latency, regulatory, sovereignty, or architectural dependencies.
The right choice depends on the organization’s constraints and priorities.
The decision should be based on workload requirements rather than assuming that one deployment model is universally better.
Cloud@Customer solves several problems associated with public-cloud adoption, but it does not eliminate all cloud infrastructure considerations.
The organization must ensure that its data center can accommodate the required infrastructure, connectivity, power, cooling, security, and physical space.
For example, Oracle’s installation process for Compute Cloud@Customer includes preparing the data center, validating site requirements, and preparing the OCI tenancy.
Not every OCI service is necessarily available in every Cloud@Customer offering.
Organizations should therefore identify the specific cloud services required by each workload and verify that they are supported by the selected Cloud@Customer deployment.
Although Oracle manages the underlying infrastructure for relevant services, customers still have responsibilities for their workloads, applications, databases, identity, security policies, and operations depending on the service.
Unlike a public cloud region where capacity can be expanded through the provider’s broader infrastructure, on-premises cloud infrastructure has physical capacity boundaries.
Organizations should therefore plan capacity and expansion requirements carefully.
A meaningful cost comparison should consider:
The cheapest infrastructure option is not necessarily the option with the lowest total cost of ownership.
1. What is the difference between Cloud@Customer and Compute Cloud@Customer?
Cloud@Customer is the broader family of Oracle offerings. Compute Cloud@Customer is a specific service that provides OCI compute, storage, and networking capabilities in a customer’s data center.
2. What is Exadata Cloud@Customer?
Oracle Exadata Database Service on Cloud@Customer provides Exadata-based Oracle Database services deployed in the customer’s data center and managed through OCI capabilities. It is designed for organizations that want Exadata and cloud-based database operations while keeping the infrastructure on-premises.
3. Can Cloud@Customer be used for regulated workloads?
Yes. Data sovereignty, residency, security, and regulatory requirements are among the primary use cases for Cloud@Customer. However, organizations must still validate the specific service, configuration, controls, and applicable compliance requirements for each workload.
4. Can Oracle Cloud@Customer be used with Oracle EBS?
Cloud@Customer can be considered for EBS environments when deployment location, data residency, latency, regulatory, or integration requirements make an on-premises cloud deployment appropriate. The specific EBS architecture and supported Cloud@Customer service should be assessed before implementation.
