Oracle Cloud at Customer vs. Dedicated Region
Oracle offers two key ways to bring its cloud services on-premises: Oracle Cloud@Customer and Oracle Dedicated Region Cloud@Customer.
Both solutions allow enterprises to run Oracle’s cloud technologies in their own data centers but differ significantly in scope and scale.
This article compares their architecture, use cases, control models, compliance features, and security implications.
We also outline the technical and business trade-offs CIOs should consider when choosing between Oracle’s Cloud@Customer appliances and a full Dedicated Region deployment.
Architecture Differences
Oracle Cloud@Customer typically refers to Oracle’s pre-packaged on-premises cloud services delivered as single-purpose systems (for example, Exadata Cloud@Customer for databases or Compute Cloud@Customer for general compute). These come as one or a few racks of Oracle-engineered hardware installed in the customer’s data center. They offer a subset of Oracle Cloud Infrastructure (OCI) services:
- Exadata Cloud@Customer focuses on Oracle Database services running on an Exadata platform. It delivers an Oracle Exadata system as a managed cloud service on-premises. This provides high-performance database capabilities (including Autonomous Database or Exadata DB Service) but only for database workloads.
- Compute Cloud@Customer: provides on-premises OCI compute and storage services for running application VMs, containers, and middleware. It includes basic OCI infrastructure components (VM compute shapes, block/object storage, networking, etc.) but not the entire OCI service catalog.
- Exadata and Compute Cloud@Customer usually connect to Oracle’s public cloud for certain control plane functions (management and updates). If the external link is lost, core services continue (databases remain accessible, VMs keep running), but management features may be limited until connectivity is restored.
By contrast, Oracle Dedicated Region Cloud@Customer (Dedicated Region) is a complete, isolated Oracle cloud “region” installed at the customer site.
It consists of multiple racks of servers and networking, a minimum footprint of around three racks (initial deployments often started around 12 racks), scaling up to dozens as needed. Key architectural features include:
- Full OCI Services: The Dedicated Region brings 100+ Oracle Cloud services (IaaS and PaaS, and even Oracle Fusion SaaS applications) into the data center. This means everything available in Oracle’s public cloud – compute, storage, databases, middleware, analytics, AI, etc. – can run locally, just as it would in an Oracle public region.
- Local Control Plane: The control plane and management infrastructure reside on-premises within the Dedicated Region. Unlike smaller Cloud@Customer offerings, a Dedicated Region does not require constant connectivity to Oracle’s public cloud. It’s an independent, self-contained region; Oracle manages it remotely, but all APIs, consoles, and services operate within the on-site region. This isolated control plane ensures the customer’s operations aren’t reliant on an external network and provides full control over updates and data residency.
- Identical Architecture to Public Cloud: Oracle built a Dedicated Region as a “copy-paste” of an Oracle public cloud region behind your firewall. The hardware, software stack, and operating model mirror Oracle’s Gen 2 cloud infrastructure. Oracle delivers the same SLAs, pricing model, and APIs in the Dedicated Region as in Oracle’s public OCI regions, making it a true extension of Oracle Cloud on-prem.
In summary, Cloud@Customer devices provide targeted cloud services on a smaller scale, whereas Dedicated Region is a massive on-premises deployment of Oracle’s entire cloud environment.
The former has a smaller footprint and focuses on specific functions (database or general compute) with some external dependencies; the latter is a full-fledged private cloud region with total functionality and autonomy.
Read How Oracle BYOL Licensing Works on Oracle Cloud@Customer.
Use Cases and Workload Scenarios
Because of these differences in scope, the use cases for Cloud@Customer vs. Dedicated Region diverge:
- Cloud@Customer (Exadata or Compute) is well-suited for organizations that need specific Oracle capabilities on-premises without adopting a whole cloud. For example, if a bank wants to use Oracle’s Autonomous Database but must keep data on-site, an Exadata Cloud@Customer can meet that requirement. Similarly, a company needing local OCI compute for a handful of applications (perhaps to address latency or data residency for those apps) might choose a Compute Cloud@Customer. These offerings are ideal for database consolidation, low-latency apps, or gradually introducing cloud management to a data center. They require a smaller commitment (minimum one rack) and are often used in scenarios like:
- Running mission-critical Oracle databases on Exadata hardware under a cloud subscription model, to achieve cloud automation while meeting data residency needs.
- Hosting specific Oracle enterprise applications (e.g., an ERP or CRM system) on OCI compute in-house, where the application servers run on Compute Cloud@Customer VMs and connect to an on-prem Exadata database service. This provides an end-to-end stack on-prem for a particular workload or two.
- Supporting development and testing of Oracle-based applications in a cloud-like environment on-premises, where developers can provision VMs or databases via OCI interfaces. Still, all resources stay inside the company’s facility.
- Dedicated Region is targeted at organizations that effectively want an entire cloud region for themselves due to large-scale or strict requirements. Its use cases include:
- Regulated industries (finance, government, healthcare) that have broad data sovereignty or compliance requirements across many systems. These customers can move a whole portfolio of applications to a Dedicated Region on-premises – including custom apps, Oracle Databases, and even Oracle’s Fusion SaaS apps – to get cloud benefits while keeping everything in-country and under their control.
- Large enterprises seeking cloud agility for legacy systems: A Dedicated Region can host legacy Oracle applications (PeopleSoft, Siebel, JD Edwards, E-Business Suite, etc.) modernized with cloud services. For example, Oracle reports that customers can run their traditional on-prem ERP or HCM software in an Oracle-Dedicated Region and integrate or replace the back end with Autonomous Database services. This “lift and shift” of legacy environments into a private cloud can streamline operations without moving to a public shared cloud.
- Data center consolidation and cloud repatriation: Companies with large, stable workloads might use a Dedicated Region to consolidate dozens of apps and databases spread across aging on-prem hardware. By having Oracle deploy and manage a region, the enterprise gains cloud-like scalability and managed services across all those workloads simultaneously. This is useful for steady-state, high-volume processing environments (core banking systems, telecom billing platforms, etc.) that want cloud features but cannot go off-premises.
- Hybrid cloud and latency-sensitive applications: Some use cases require certain services on-prem for low latency (for example, real-time trading platforms). Dedicated Region can serve those needs locally while connecting to Oracle’s public cloud or other clouds. It becomes part of a hybrid cloud strategy – the most sensitive or high-performance components run in the on-site region, and other, less sensitive workloads might run in the public cloud. Because the Dedicated Region uses the same APIs and architecture as OCI public, applications can be designed to be seamlessly portable between the on-prem region and Oracle’s public regions.
Cloud@Customer is a targeted hybrid solution (one piece of cloud at your site for a specific need). In contrast, Dedicated Region is a full cloud replacement on-prem (for when you need almost everything the cloud offers, just not in a public data center).
A CIO might opt for Cloud@Customer to solve a narrow problem or comply with one set of requirements, versus choosing a Dedicated Region to fundamentally transform and outsource the operation of an entire on-premises data center to Oracle’s cloud model.
Control and Management Model
With any Oracle on-prem cloud offering, Oracle retains responsibility for managing the infrastructure and cloud services, while the customer maintains control of their data and usage.
However, the degree of control and operational responsibility differs:
- Cloud@Customer (Exadata/Compute): Oracle handles all hardware maintenance, infrastructure patching, and underlying software updates. The customer controls how the service is used for their workloads. For example, on Exadata Cloud@Customer, Oracle manages the Exadata hardware and database software updates, especially if running Autonomous Database. The customer’s DBAs, however, still manage the database schemas, performance tuning (for non-autonomous deployments), and day-to-day use of the database service. On Compute Cloud@Customer, Oracle manages the base hardware and hypervisor, but the customer has full control over their VMs, operating systems, middleware, and applications running on those VMs. In practice, Cloud@Customer users administer their resources via Oracle’s cloud console or APIs (with some functions calling back to Oracle’s public cloud control plane). It’s a shared responsibility: Oracle takes care of “keeping the lights on” for the infrastructure, while the client manages the actual workloads and data.
- Dedicated Region: This is delivered as a fully managed service – Oracle treats it like another region of OCI. Oracle’s team handles end-to-end operations of the region’s infrastructure and services, including updates, scaling (adding new racks when needed), and security patching across all service components. On the other hand, the customer interacts with the region exactly as they would a public cloud region: provisioning compute instances, databases, etc., through self-service tools. In other words, the customer does not manage the underlying hardware or cloud software; they simply consume the cloud services. Oracle even assumes responsibility for the security of the cloud control plane and infrastructure on-site (conducting audits and monitoring within the region). The customer’s responsibility is mainly to provide the data center facilities (power, cooling, physical security) and network connectivity, and use the cloud services securely. Because the control plane is local, the customer has more direct insight and potential control over the timing of updates (Oracle coordinates with them for region upgrades). Still, they generally cannot modify or interfere with the managed environment’s configuration beyond their tenancy settings.
In terms of control over data and configurations, both options let the customer retain data sovereignty:
- In Cloud@Customer solutions, some control plane components run in Oracle Cloud, so certain metadata or management operations transit to Oracle’s cloud. However, data (e.g., database contents) resides on the on-prem hardware. Oracle uses technologies like Oracle Operator Access Control to ensure Oracle staff cannot access customer data without explicit permission. The customer can typically determine when Oracle applies patches (within a window) on Exadata systems, etc., giving them a say in scheduling.
- In a dedicated region, all control planes and data planes are on-site, so the customer has even stronger control from a data residency standpoint. No customer data or configuration leaves the premises; Oracle administrators manage the region remotely but through secure channels and with audit controls. The customer effectively gets an isolated cloud environment dedicated to them, which gives them control over the configuration of policies (IAM, network settings, etc.) just like in public OCI. Still, they cannot control the underlying hardware provisioning beyond requesting expansion.
Summary: Cloud@Customer offers more hands-on control over specific services (like managing your own VMs or databases) but with limited scope. Dedicated Region offers hands-off infrastructure (Oracle-managed everything) with full cloud breadth.
In both cases, CIOs control their applications and data placement, but they cede low-level infrastructure worries to Oracle.
Compliance and Data Residency
A chief motivation for these offerings is to meet compliance, regulatory, and data residency requirements.
Both Cloud@Customer and Dedicated Region keep data on-premises, but there are nuances:
- Data Residency: Both solutions ensure that your sensitive data stays in your own data center. For industries like finance, healthcare, government, etc., this addresses regulations restricting data from being stored in public clouds or outside certain jurisdictions. Dedicated Region, however, can go a step further – since even the control plane and metadata are local, you avoid sending system information or service telemetry to a foreign cloud. This can be critical for agencies that require complete sovereignty over systems. Oracle explicitly designed the Dedicated Region to satisfy strict national security and government criteria by having a fully isolated on-prem region.
- Certifications and Standards: Oracle Cloud@Customer (especially Exadata Cloud@Customer) may inherit many of Oracle Cloud’s security certifications, but a Dedicated Region can be certified to the same breadth of compliance standards as Oracle’s public cloud environment, because it’s essentially the same services deployed in your data center. Oracle indicates that Dedicated Regions support your data center’s extensive industry and regulatory certifications. This means a customer can achieve compliance with frameworks like ISO 27001, SOC 2, PCI-DSS, HIPAA, etc., using the Oracle-managed environment, similar to using Oracle Cloud—Oracle will stand behind the controls for the infrastructure part. With smaller Cloud@Customer deployments, the scope is narrower (for example, just databases), so compliance focus is typically on database security and related controls rather than a full stack certification.
- Isolation and Multi-Tenancy: Both offerings are single-tenant dedicated hardware for that customer (unlike public cloud, where many tenants share systems). This isolation enhances compliance since resources aren’t shared with outsiders. In Cloud@Customer, you get a dedicated Exadata or server rack; in Dedicated Region, the entire region is yours. This helps address data separation requirements and eases auditing, because you can delineate who has access to the hardware (only Oracle personnel under contract, and your own users of the cloud services).
- Connectivity and Data Transfer: By keeping operations on-site, organizations avoid the compliance issues of transferring large volumes of data to a public cloud. For Cloud@Customer, any management data going to Oracle’s network is generally encrypted and limited, but if a policy forbids outside connectivity, that could be a concern. Dedicated Region is the answer in those extreme cases since it can run fully disconnected if needed (by special arrangement, as it normally still receives updates via a secure link). In less extreme cases, both solutions significantly reduce data movement—only updates/patches and support telemetry go out, not your core business data.
In short, both solutions meet compliance needs by bringing the cloud inside your controlled environment. Dedicated Region offers more assurance for comprehensive compliance because it replicates a full cloud under your governance.
Cloud@Customer addresses compliance per system (e.g., “my database is on-prem, therefore compliant with data residency”).
In contrast, a Dedicated Region can make your entire cloud footprint compliant in one go (since everything runs locally under consistent controls).
Security Considerations
Oracle’s on-premises cloud offerings leverage a layered security model combining the customer’s physical security with Oracle’s cloud security controls:
- Physical Security: The customer is responsible for securing the hardware’s location and controlling access to the data center, rack, or cage. Oracle often recommends a dedicated, access-controlled area for the Cloud@Customer equipment. In some cases (especially for Dedicated Region with multiple racks), Oracle may even require a separate secured space where only authorized personnel (potentially including Oracle field engineers if needed) can enter. The customer must ensure proper facilities security and environmental protections as part of their responsibilities.
- Encryption and Data Protection: Cloud@Customer and Dedicated Region have built-in encryption for data at rest and in transit. Oracle’s cloud services typically encrypt data on disk by default and use secure communication for data in motion. Because the systems are the same as Oracle Cloud, customers can use Oracle Cloud Infrastructure’s security features like Vault for key management, Identity and Access Management (IAM) for controlling user access, etc., even in these on-prem deployments. The data never leaves the premises (except backups if you send off-site), so you have full control over encryption keys if desired.
- Operator Access Control: Oracle employs an approach to restricting and logging any access its engineers have to the on-prem environment. For example, Oracle Operator Access Control allows customers to approve or deny Oracle’s support personnel access to the maintenance infrastructure. This assures that Oracle cannot snoop on or alter systems without customer knowledge and consent—an important security feature for sensitive environments.
- Patching and Updates: Oracle handles patching of firmware, hypervisors, and cloud service software in both offerings, which can be a security advantage – you get timely security updates (for OS, database, etc.) applied by experts. In a Dedicated Region, updates to cloud services are delivered on-site as they are in public cloud, meaning you receive new security fixes and features as soon as Oracle releases them to any region. This ensures the on-prem region is not left behind on security hardening. For Cloud@Customer Exadata, Oracle similarly pushes patches to the Exadata infrastructure regularly. Customers should coordinate patch schedules to align with internal change management, but from a security standpoint, continuous updates reduce vulnerabilities.
- Network Security: Inside a Cloud@Customer or Dedicated Region, you can use the same network segmentation and firewall features as OCI. For example, Dedicated Region supports virtual cloud networks (VCNs), security lists, and network security groups to isolate applications. The advantage is that you can integrate this with your existing enterprise network and security monitoring. Low-latency connections to existing systems mean you can enforce enterprise security policies uniformly. Moreover, since the traffic between your internal users and the cloud services doesn’t traverse the internet, it reduces exposure to external threats. The flip side is that you must extend your internal network protection to cover these cloud resources (like monitoring east-west traffic between on-prem apps and the Oracle region).
- Comparison: There is no substantial difference in the security capabilities of the services themselves between Cloud@Customer and Dedicated Region – both benefit from Oracle’s cloud security technologies. The difference is mainly scope: Dedicated Region will include a broader array of security services (like cloud-based web application firewalls, threat detection services, etc.) because it has all of OCI. Cloud@Customer might have more limited security service availability (for example, the Exadata service will have database security features but not things like OCI’s IDS/IPS services, which aren’t deployed in that appliance). From a risk perspective, a Dedicated Region can be seen as a larger target (since it runs many services and holds more data). Still, it’s also more comprehensively protected by Oracle’s full cloud security stack. Cloud@Customer devices have a smaller attack surface but are also somewhat simpler environments.
Both deployments reflect a shared security model: Oracle secures the cloud infrastructure (and is contractually responsible for it), while the customer must secure their data, user access, and integration points.
A CIO should ensure that robust procedures (access control, monitoring, incident response) are in place for the on-prem cloud just as they would for any critical on-site system.
Importantly, they should leverage the security features included (like isolating sensitive workloads in separate compartments, using dedicated encryption keys, and enabling Oracle’s audit/logging services) to maintain visibility and control.
Technical and Business Trade-offs
Choosing between a Cloud@Customer solution and a Dedicated Region involves balancing trade-offs in flexibility, cost, and strategic scope:
- Breadth vs. Specificity: A Dedicated Region gives you everything Oracle offers, which is powerful if you need a wide range of cloud services on-prem. It avoids the risk of “needing something that isn’t available”. For instance, if you decide tomorrow to implement a new analytics platform or AI service, it will be deployable in your dedicated region. With Cloud@Customer, you intentionally choose a narrower service set (say, just database). This can simplify matters if you truly only require that one thing. The trade-off is potential limitations in the future, e.g., if you suddenly need container services or a data lake, a single-purpose appliance won’t provide that, possibly forcing you to consider an upgrade or migration. In short, Cloud@Customer addresses today’s specific need, whereas Dedicated Region is a more future-proof platform for many needs.
- Cost and Commitment: Dedicated Regions demand a much larger financial commitment and a multi-year contract. Oracle initially priced Dedicated Regions around $6 million per year minimum, and while pricing can be negotiated, it’s generally a significant investment reserved for big workloads. While expensive, cloud@Customer units, such as Exadata Cloud@Customer, have a smaller entry point (one rack of Exadata with a 4-year term, for example). The business must weigh if the breadth of services in a Dedicated Region justifies its cost. Many find that the Dedicated Region may be overkill unless they have a very large portfolio to move. On the other hand, if you have a broad need, opting for separate Cloud@Customer appliances for databases, compute, etc., might cost more in aggregate and be less efficient than a unified Dedicated Region. Trade-off: Small scope + lower cost (Cloud@Customer) vs. Full scope + higher cost but potentially better economies of scale (Dedicated Region).
- Control vs. Convenience: With a smaller Cloud@Customer, an organization might feel it has a bit more direct control over that specific environment – for example, DBAs might have full sysadmin control over an Exadata Cloud@Customer machine (for non-autonomous databases) just as they would on a self-managed Exadata, whereas in a Dedicated Region, the paradigm shifts to cloud-style management (DBAs use cloud service interfaces rather than logging into database servers directly). Some companies may prefer the familiar control of a single system. However, that control comes with a responsibility to coordinate with Oracle on patches, etc. A Dedicated Region, by design, outsources much of the control to Oracle, which is convenient (less effort for your staff) but requires trust. For many CIOs, ceding day-to-day infrastructure control is acceptable or even desirable when focusing on higher-level needs. However, if a company has custom infrastructure tweaks or integration needs that don’t fit Oracle’s cloud model, a rigid dedicated region might frustrate those who want low-level tweaks. In short, Cloud@Customer = more custom management of a single service; Dedicated Region = standardized management of everything by Oracle.
- Deployment Time and Complexity: Standing up an Exadata Cloud@Customer is relatively quick (a matter of weeks for Oracle to deliver and configure). A fully dedicated region is a major project that takes months to deploy and test. If time-to-value is critical for one specific project, a Cloud@Customer box could be up and running sooner. Dedicated Region’s complexity means longer planning: your data center must accommodate power, cooling for many racks, networking integration, etc., and Oracle will perform extensive setup. The business trade-off here is speed vs. scale – a smaller scope can be delivered faster and with less organizational disruption, whereas a large region, while slower to implement, could consolidate many projects once live.
- Vendor Lock-In: Both offerings lock you into Oracle’s ecosystem to an extent, but a Dedicated Region represents a deeper lock-in because it could run vast portions of your IT environment. If you only use an Exadata Cloud@Customer for databases, you might still use other vendors for applications or hardware; your diversification remains. If you invest in a Dedicated Region, you entrust one vendor (Oracle) with an entire cloud stack on-prem. Some businesses might see this as too much dependency on one vendor. Others might accept it given Oracle’s accountability for SLAs and the convenience of “one throat to choke.” The mitigating factor is that Oracle’s cloud somewhat adheres to standard cloud APIs and technologies. Theoretically, workloads running on OCI could be moved to other clouds with some effort. Oracle even emphasizes that you can run non-Oracle workloads on Dedicated Region (bring your own VMs, containers, open source tools, etc.), so you’re not strictly limited to Oracle software. Nonetheless, the capital and training invested in Oracle’s platform is substantial. The trade-off is lock-in vs. single-vendor simplicity: Cloud@Customer (small) = easier to unwind if needed; Dedicated Region = harder to exit but provides a one-stop-shop environment.
Business Perspective:
CIOs should evaluate how each model aligns with their cloud strategy. If the goal is to cloud-enable a specific function due to compliance (for example, “we need an on-prem database-as-a-service for our core banking system”), then a targeted Cloud@Customer may suffice with lower risk.
If the strategy is larger, like data center modernization or creating a private cloud for many teams, then a Dedicated Region could provide a more comprehensive solution, potentially with better long-term ROI if it replaces disparate systems and services.
One Gartner analyst famously noted that Oracle Dedicated Region was the first to deliver a “private cloud identical to public cloud” in customers’ data centers, highlighting its value in giving customers everything without compromise. That is attractive, but only if you need everything. Otherwise, paying for a unicorn may not be justified when a single sturdy horse will do.
Read Which Oracle Software Can You Run on Oracle Cloud at Customer?
Conclusion
When comparing Oracle Cloud@Customer appliances to Oracle’s Dedicated Region, the differences come down to scope, scale, and commitment. Cloud@Customer options address specific needs precisely, offering critical cloud capabilities under your roof, one piece at a time.
Dedicated Region offers a holistic cloud on-prem, ideal for those who need the full spectrum of services with cloud consistency and are willing to invest accordingly.
The decision involves trade-offs between breadth and cost, control and convenience, speed and thoroughness. CIOs should carefully assess their organization’s requirements:
- Are your needs limited to databases or a few apps, or do you foresee broad adoption of cloud services on-prem?
- Do you have the budget and long-term vision for a private cloud region, or is it more prudent to start smaller?
- How important is complete autonomy (no external dependencies) versus a hybrid tied to the public cloud for management?
- Will a single-purpose solution solve your problem, or will you just need more pieces later (in which case, a bigger step might be more efficient)?
IT leaders can choose the right path by answering these questions and weighing the above trade-offs. Both paths lead to the same goal: cloud benefits delivered on-premises. It’s about choosing the vehicle that best fits your enterprise’s journey.
