Table of Contents
- What Is Oracle Cloud@Customer? OCI On-Premises Explained
- Oracle Exadata Cloud@Customer (ExaCC): Architecture, Pricing & Licensing
- Oracle Database@Customer: The Dedicated Infrastructure Option
- Cloud@Customer vs Standard OCI: Cost & Compliance Comparison
- Infrastructure Requirements: What Oracle Doesn't Tell You Upfront
- Licensing Rules: How Cloud@Customer Handles BYOL and Processor Counts
- Cloud@Customer Contract Terms: The Commercial Traps
- When Cloud@Customer Makes Sense — and When It Doesn't
What Is Oracle Cloud@Customer? OCI On-Premises Explained
Oracle Cloud@Customer (C@C) is Oracle's on-premises infrastructure solution that brings a managed OCI rack into your data center. Oracle owns the hardware and manages the entire stack—including the physical infrastructure, networking, virtualization, and security updates. You provision and consume OCI services (Compute, Storage, Database, Analytics) just as you would on a public OCI region, but the infrastructure lives behind your firewall.
This matters because Cloud@Customer is designed to address three constraints that standard OCI regions cannot: data sovereignty requirements (data cannot leave a specific geography or country), latency-sensitive workloads (where sub-millisecond latency to Oracle Database is non-negotiable), and regulatory prohibitions on public cloud hosting (financial services, government, healthcare in highly restricted jurisdictions).
Cloud@Customer comes in two primary variants: Exadata Cloud@Customer (ExaCC), which focuses on high-performance database workloads, and Oracle Database@Customer (DB@Customer), which is a larger offering that includes the full OCI stack. Both operate under the Universal Credits model, but with Cloud@Customer-specific pricing uplift and minimum commitment terms.
A critical governance point often overlooked: Oracle retains physical access rights to the rack for management, maintenance, and diagnostics. While data is encrypted and Oracle doesn't have logical access, the physical security implications—Oracle engineers can access the hardware, review logs, and perform diagnostics—are a significant consideration for security-conscious enterprises and require explicit risk acceptance in your governance framework.
Our Oracle Cloud Advisory service models the total cost of Cloud@Customer, Exadata Cloud@Customer, and standard OCI against your specific workloads. See our Energy sector OCI case study: $3.5M saved.
Oracle Exadata Cloud@Customer (ExaCC): Architecture, Pricing & Licensing
Exadata Cloud@Customer is Oracle's database-first Cloud@Customer offering. ExaCC deploys Oracle's Exadata engineered system hardware, the OCI Autonomous Database service, and Oracle's management stack entirely on-premises. This is not a capital purchase—you don't buy the hardware. Instead, you subscribe to ExaCC on a monthly basis, and Oracle retains ownership and all maintenance responsibilities.
ExaCC pricing has two components: (1) infrastructure subscription fee, which covers the Exadata base system, storage capacity, and Oracle management overhead, typically ranging from $200K to $1M+ annually depending on rack size, and (2) Autonomous Database consumption charges in OCPU-months. A quarter rack (the minimum ExaCC deployment) includes starter Autonomous Database capacity, but you pay incremental per-OCPU consumption above that.
The licensing decision on ExaCC is critical and often misunderstood. If you deploy Autonomous Database with Oracle-provided licenses (the default), you pay the per-OCPU rate Oracle quotes. However, if you already own Oracle Database EE licenses, you can apply BYOL (Bring Your Own License) to ExaCC. Under BYOL on ExaCC, 1 OCPU = 1 Oracle Processor license—the same metric as standard OCI. This BYOL route often reduces per-OCPU costs by 30-50%, making it a strong financial lever if you have existing Oracle Database EE licenses in your portfolio.
ExaCC sizing starts at a quarter rack and scales to full racks. A quarter rack delivers approximately 2-4 OCPU capacity for Autonomous Database, making it a genuine option for mid-market deployments, though the $200K+ annual infrastructure subscription means even a quarter rack is a $1M+ 5-year commitment. Full racks (4 per Exadata X9 system) can deliver 400+ OCPU, suitable for very large database consolidations.
Oracle Database@Customer: The Dedicated Infrastructure Option
Database@Customer (DB@Customer) is Oracle's larger Cloud@Customer offering. Unlike ExaCC, which is database-focused, DB@Customer brings the entire OCI region stack on-premises: Compute, Storage, Networking, Database (both Autonomous and traditional), Analytics, AI/ML services, and more. DB@Customer includes a dedicated OCI control plane managed by Oracle remotely—your enterprise has no console access to infrastructure management, only to the OCI service provisioning interfaces.
DB@Customer is designed for the most heavily regulated industries—financial services, government agencies, healthcare systems operating under strict data residency mandates. The typical minimum commitment for DB@Customer is approximately $1M+ annually in OCI Universal Credits, with 3-year terms and the ability to scale to multiple racks if needed.
The infrastructure scale of DB@Customer is substantial. A single DB@Customer instance occupies multiple standard rack units, includes redundant networking, dual-power feeds, and Oracle-managed security patches. The physical footprint, power consumption, and cooling requirements mean that DB@Customer is a strategic infrastructure decision at the data center level, not a tactical software deployment.
A significant distinction from ExaCC: DB@Customer includes Oracle-managed compliance and audit controls. Oracle's security teams conduct regular assessments, and the service includes audit logging at the infrastructure level. For highly regulated industries, this can reduce your audit burden, though it also means your infrastructure audit trail is managed by Oracle—a trade-off that requires explicit risk review.
Cloud@Customer vs Standard OCI: Cost & Compliance Comparison
Cloud@Customer commands a 20-40% price premium over equivalent standard OCI services. This premium covers the infrastructure subscription, Oracle's management overhead, and the on-premises deployment and support model. If you consume $1M in standard OCI services annually, the equivalent workload on Cloud@Customer typically costs $1.2M–$1.4M.
However, the cost comparison is more nuanced than a simple percentage uplift. Data egress costs vanish on Cloud@Customer—if you're sending data between your on-premises systems and OCI regions today, those egress charges disappear. For data-intensive workflows (analytics, data warehousing, machine learning training), this egress elimination can offset 30-50% of the Cloud@Customer premium. Latency benefits are quantifiable too: sub-millisecond latency to ExaCC Autonomous Database is achievable on-premises, while network latency to a public OCI region adds 5-50ms depending on geography.
Support Rewards credits accrue on Cloud@Customer OCI spend at the same rate as standard OCI (1-3% depending on commitment level), so high-volume commitments unlock slightly better economics. The total cost model must integrate infrastructure subscription + OCPU consumption + Oracle management fees + any BYOL license costs—a complex calculation that requires scenario modeling against your actual workload distribution.
Compliance-wise, Cloud@Customer genuinely solves data sovereignty and data residency constraints that standard OCI regions cannot address. If your regulatory framework explicitly prohibits data transmission outside a jurisdiction, Cloud@Customer may be non-negotiable. However, many enterprises cite compliance concerns that standard OCI regions actually satisfy—validating whether your specific regulatory requirement truly mandates Cloud@Customer is the first forensic step before accepting its cost premium.
Our free white paper covers BYOL rules on OCI, Cloud@Customer licensing mechanics, and how to structure the migration to minimize compliance exposure.
Infrastructure Requirements: What Oracle Doesn't Tell You Upfront
Cloud@Customer infrastructure requirements are more stringent than many enterprises initially understand. These aren't theoretical constraints—they are enforceable contract terms, and non-compliance can trigger service suspension or breach scenarios.
Physical space: ExaCC quarter rack = 3 standard 19-inch rack units plus networking equipment (top-of-rack switches, management infrastructure). Most data centers can accommodate this, but the footprint is real and must be planned for. DB@Customer requires substantially more: typically 8-12 rack units plus dedicated power distribution and cooling.
Power and redundancy: ExaCC requires dual-power feeds (N+1 redundancy), each feed capable of delivering the full system power draw. For a quarter rack, this typically means 15-20 kW per feed. Redundant uninterruptible power supplies (UPS) are required. If your data center doesn't have dual-feed infrastructure or UPS capacity, you'll face infrastructure upgrades that can cost $500K–$2M depending on your current setup.
Network connectivity: Oracle requires a minimum of 10GbE connectivity to the ExaCC rack for OCI service traffic, with 25GbE recommended for high-throughput workloads. More critical: Oracle requires permanent outbound network connectivity to Oracle's management infrastructure for patching, monitoring, and diagnostics. This management traffic cannot be proxied, firewalled to specific IPs, or scheduled for specific maintenance windows—it must be always-on and routable to Oracle's infrastructure. For security-conscious enterprises, this is a significant risk point.
Physical security and access: Oracle reserves the right to inspect and maintain the hardware. While Oracle doesn't have logical access to your data (which is encrypted), Oracle engineers can physically access the rack, review system logs, and perform diagnostics. Your physical security policy must accommodate Oracle staff access during business hours and for emergencies.
Environmental controls: Oracle specifies strict temperature (18-27°C) and humidity (20-80% RH) ranges. Exceeding these ranges triggers Oracle diagnostics and can result in service degradation or suspension. If your data center operates outside these ranges for certain areas, you'll need dedicated cooling for the Cloud@Customer rack—another infrastructure cost.
Licensing Rules: How Cloud@Customer Handles BYOL and Processor Counts
BYOL (Bring Your Own License) on ExaCC uses the same licensing metric as standard OCI BYOL: 1 OCPU = 1 Oracle Processor license. This is important because it makes BYOL economics comparable between standard OCI and ExaCC. If you have a pool of Oracle Database EE Processor licenses available, you can deploy them on ExaCC and reduce per-OCPU consumption charges by 30-50%.
However, the nuance is critical: the Processor licenses you deploy on ExaCC must be from the OCI-eligible License Set under your Oracle License Statement Agreement (OLSA). Not all Oracle Database EE licenses qualify for OCI BYOL—licenses purchased under perpetual legacy contracts, grandfathered terms, or older editions may not be eligible. Your OLSA must be reviewed before assuming BYOL on ExaCC is available.
On Autonomous Database deployments (the default ExaCC scenario), Oracle provides the Database license as part of the service—you don't require separate Database EE licenses. However, if you're deploying traditional Oracle Database EE (non-Autonomous) on ExaCC compute, you'll need either BYOL Processor licenses or Oracle-provided Database EE licenses (which increase per-OCPU costs).
Additional licensing trap: Diagnostic Pack and Tuning Pack. On Autonomous Database (which is the common ExaCC deployment pattern), these packs are not applicable because Autonomous Database doesn't require manual tuning. However, if you're deploying traditional EE with BYOL, Diagnostic Pack and Tuning Pack may auto-enable on the database, creating unexpected license obligations. Review your BYOL election carefully and work with Oracle to confirm which packs are required for your specific deployment topology.
Cloud@Customer Contract Terms: The Commercial Traps
Cloud@Customer contracts contain several commercial clauses that often surprise enterprises after signature. Understanding these traps before committing is essential.
Minimum commitment and term length: Cloud@Customer typically requires 3-year minimum commitments, compared to 1-year commitments for standard OCI. For a $1M+ annual service, this is a $3M+ commitment upfront. Oracle rarely negotiates on commitment length—it's a standard contract term.
Early termination fee: If you need to exit Cloud@Customer before the 3-year term ends, Oracle charges a rack removal or early termination fee that often equals 100% of the remaining subscription value. A 2-year early exit on a $1M/year subscription means a $1M+ termination bill. This is non-negotiable in Oracle's standard contract language. We've negotiated this down to 50% of remaining value in rare cases, but Oracle's default posture is the full remaining balance.
Hardware refresh and pricing: Oracle controls the hardware refresh cycle—you don't choose when the Exadata or infrastructure is upgraded. Oracle publishes a refresh schedule (typically every 5-7 years), but the timeline is Oracle's call. When refreshed hardware is deployed, Oracle often reprices the infrastructure subscription. Your contract may include price protection for the initial term, but refreshed hardware could see 10-20% price increases.
Data repatriation terms: If your contract ends or Oracle terminates for cause, you have a limited window (typically 30-90 days) to retrieve your data from the Cloud@Customer rack. After that window, Oracle may delete your data. If you have terabytes of data, a 30-day repatriation window can be physically impossible—this requires explicit negotiation upfront.
Oracle's management access rights: Oracle's contract explicitly reserves the right to access, inspect, and maintain the hardware regardless of your security policies. While data is encrypted, the physical security implications (Oracle staff can access the rack, review logs, perform diagnostics) are enforceable contract rights, not requests. This is a governance and risk acceptance conversation that must happen with your security and legal teams.
When Cloud@Customer Makes Sense — and When It Doesn't
Cloud@Customer genuinely makes sense in these scenarios:
1. Data sovereignty requirements: Your regulatory framework explicitly prohibits data transmission across borders or to public cloud regions. Government contracts, certain financial services regulations, and healthcare data governance in highly restricted jurisdictions legitimately mandate Cloud@Customer. Validate this requirement forensically—many enterprises overstate data sovereignty concerns that standard OCI regions actually satisfy.
2. Latency-critical Oracle Database workloads: If your application requires sub-millisecond latency to Oracle Database and cannot tolerate network latency to a public OCI region, ExaCC is a legitimate technical solution. This applies to real-time trading systems, low-latency analytics, and specialized database workloads. Commodity applications typically don't require this.
3. Highly regulated industries with audit mandates: Financial services, government agencies, and healthcare systems operating under strict audit and compliance requirements may benefit from Cloud@Customer's Oracle-managed compliance controls. The trade-off is that your audit trail is managed by Oracle, not your security team—an acceptable trade-off for some enterprises.
Cloud@Customer does not make sense in these scenarios:
If your regulatory requirement can be satisfied by a standard OCI region (data center in your country, encryption in transit, encryption at rest), standard OCI is always more cost-effective and commercially flexible. Cloud@Customer's 20-40% cost premium, 3-year commitment, and early termination fees are simply not justified by generic compliance or latency concerns that standard OCI addresses.
If you're consolidating commodity workloads (web servers, application servers, non-mission-critical databases) to the cloud, Cloud@Customer's cost and complexity are overkill. Standard OCI, AWS, or Azure is the right choice.
If you're exploring cloud as a stepping stone to eventual public cloud migration, Cloud@Customer's long-term commitment and high switching costs make it a poor staging ground. You'll lock yourself into on-premises infrastructure and face massive exit costs if you decide to migrate elsewhere.
Key Takeaways
- Oracle Cloud@Customer prices at a 20-40% premium over equivalent standard OCI services
- ExaCC minimum commitment is a quarter rack—smaller than enterprises often assume, but still a $1M+ 5-year commitment
- BYOL on ExaCC uses 1 OCPU = 1 Processor license, same as standard OCI BYOL—validate OLSA eligibility before assuming BYOL availability
- Oracle retains physical inspection rights to Cloud@Customer racks—a governance consideration many enterprises overlook
- Early termination fees in Cloud@Customer contracts can equal 100% of remaining subscription value—negotiate aggressively on this term
- Support Rewards credits accrue on Cloud@Customer OCI spend at the same rate as standard OCI (1-3% depending on commitment level)
- Infrastructure requirements (10GbE minimum, dual-power feeds, UPS, always-on management connectivity) must be validated upfront
- Validate whether your regulatory requirements actually prohibit standard OCI before committing to Cloud@Customer's higher cost and long-term lock-in
Is Oracle Cloud@Customer Right for Your Workloads?
Get an independent cost and compliance analysis before you commit to a 3-year Cloud@Customer subscription.