Oracle Dedicated Region (DRCC), Exadata Cloud@Customer (ExaCC), Compute Cloud@Customer and Database@Azure share a commercial pattern: Oracle ships full OCI infrastructure into the customer’s data centre or partner cloud, and the customer commits to multi-year consumption at near-OCI pricing. The architecture is compelling for sovereignty, latency and regulatory use cases — but the commercial structures are weighted heavily toward Oracle. Minimum-capacity commitments, exit penalties, BYOL constraints and refresh obligations create lock-in well beyond standard OCI. This guide explains the architecture, the real pricing anatomy, and the negotiation levers available before signing.
Oracle’s Cloud@Customer family is a portfolio, not a single product. Four distinct offerings share the “Oracle OCI in your data centre” pattern but differ significantly in scope, pricing and use case.
Oracle Dedicated Region Cloud@Customer (DRCC) is the full OCI public-cloud service catalogue delivered in the customer’s data centre. Customer receives Oracle’s complete cloud stack — compute, storage, database, all PaaS services — behind their firewall. Minimum commitment is approximately $1M per month over 36 months, equating to $36M+ in committed contract value. DRCC fits sovereignty-constrained, regulated, ultra-low-latency or full-cloud-control use cases where public OCI is not acceptable.
Exadata Cloud@Customer (ExaCC) is the Exadata Database Service delivered in the customer’s data centre — a subset of DRCC focused on database workloads. Minimum is 8 OCPU/ECPU activation per database node, contracts typically run 36–60 months, and the customer can choose BYOL (existing on-prem Database EE licences applied) or licence-included (Oracle bills licence consumption as part of the OCI consumption rate). Largest commercial fit: enterprises with substantial existing Database EE licence inventory who want to consolidate onto Exadata without going to public OCI.
Compute Cloud@Customer is a lighter-weight subset focused on OCI compute and storage services, without the full PaaS catalogue and at a lower minimum commit. Commercial fit: customers needing on-premise OCI compute and storage but not the full database and analytics services stack.
Oracle Database@Azure is architecturally similar but delivered inside Microsoft Azure data centres rather than the customer’s. Customer accesses Oracle Database services via Azure portal; Oracle operates the underlying Exadata infrastructure. Best for customers committed to Microsoft Azure as primary cloud who require Oracle Database performance characteristics. Same commercial weight applies — minimum commitments, BYOL rules and Oracle-side operational control.
Dedicated Region Cloud@Customer’s pricing is built from three components: (1) a fixed monthly infrastructure fee for the deployed Oracle hardware footprint, (2) consumption charges for OCI services drawn from that footprint, and (3) a one-time installation and refresh-cycle fee.
The infrastructure fee covers Oracle’s hardware deployment — typically multiple racks of Exadata, OCI bare-metal compute, networking and storage. The customer does not own this hardware; Oracle retains ownership and refreshes it under the contract. The monthly fee is approximately $500K–$1.2M depending on configuration.
Consumption charges apply on top of the infrastructure fee. Service consumption is metered identically to public OCI — OCPU-hours, GB-storage-months, request counts — and billed against the customer’s OCI Universal Credit commitment. The published consumption rates are similar to public OCI public list; in practice DRCC customers negotiate 15–30% consumption discounts as part of the multi-year commit.
The refresh cycle: Oracle commits to refreshing the underlying hardware every 4–5 years. Refresh is included in the contract but can trigger contract restructuring — particularly if Oracle’s technology roadmap shifts during the contract term. Negotiate the refresh-cycle terms specifically: who decides timing, what happens if customer needs additional capacity mid-cycle, and what exit options exist around the refresh point.
Total DRCC contract value over 36 months: $36M–$54M typical. Customers signing DRCC contracts should plan for this level of commitment with full procurement, finance, legal and architectural diligence.
Every Cloud@Customer offering has a minimum capacity commitment that becomes the contractual floor for the entire term. Customers can scale up; they cannot scale down below the floor. Understanding the floor mechanics before signing is the single most important pre-contract diligence step.
DRCC minimum: Approximately $1M per month for 36 months. The minimum is fixed regardless of actual consumption — idle capacity is paid for, drawdown gaps generate no relief. Customers must size DRCC to their committed steady-state, not their peak.
ExaCC minimum: 8 OCPU/ECPU per database node activation. The 8-unit minimum applies even if actual database workload requires only 2–4 OCPUs. For customers running small Oracle databases this can mean 50–75% of paid capacity is idle.
Compute Cloud@Customer minimum: Lower than DRCC but still materially fixed — typically $200K–$400K per month equivalent. Always evaluated against actual workload, not against marketing projection.
Database@Azure minimum: Similar 8 ECPU minimum on database nodes. Plus Azure consumption charges on the underlying Azure infrastructure that hosts the Oracle service.
The negotiation lever: minimums are reduced in specific deal structures. Customers committing to longer terms (60 months instead of 36), bundling with additional Oracle products, or committing as part of a Fusion Cloud or ULA deal have negotiated minimum reductions of 20–40%. The published minimums are the opening position, not the floor.
The over-provisioning trap: Oracle’s solution engineers typically size Cloud@Customer deployments for peak workload assumptions. Real workload utilisation is usually 30–50% of peak. Over-sized minimums mean paying for capacity that will never be used. Demand independent capacity analysis before accepting the Oracle-proposed configuration size.
Bring Your Own Licence (BYOL) is one of the most under-used buyer-side levers in Cloud@Customer deals. Customers with substantial existing on-premise Oracle Database licences can apply those licences to Cloud@Customer consumption, dramatically reducing the licence-included component of the monthly bill.
BYOL pricing on ExaCC and Database@Azure reduces consumption rates by approximately 80% versus the licence-included rate. A customer paying $4.50 per OCPU-hour at the licence-included rate pays approximately $0.90 per OCPU-hour at BYOL. Over a typical ExaCC commitment, this can mean $3M–$8M in cost reduction.
The conditions: BYOL requires the customer to hold a valid Database Enterprise Edition perpetual licence with active support, and to deploy the BYOL workload within the contractually permitted territories and entities. Oracle’s standard BYOL terms restrict assignment, sublicensing and migration of the underlying licence — ensure your BYOL contract language preserves the flexibility you need.
BYOL works for database workloads — not for the full OCI service catalogue. Storage, networking, AI services and most PaaS services do not have a BYOL option. Customers heavy in database workloads benefit most.
The negotiation: BYOL terms in Cloud@Customer contracts vary widely. Standard Oracle terms restrict cross-subsidiary BYOL transfer, restrict BYOL to specific Oracle product editions, and exclude BYOL on options (Partitioning, RAC). Each of these can be negotiated. Buyers should expect to invest legal effort in BYOL clause-by-clause review.
The strongest commercial case for Dedicated Region Cloud@Customer is sovereignty — situations where public OCI is not legally, contractually or practically acceptable but where the customer requires Oracle cloud services.
Public sector and defence: Government agencies, defence contractors and intelligence customers often face explicit prohibitions on public cloud deployment for classified or controlled data. DRCC delivers full OCI service catalogue within the agency’s controlled environment. Authority To Operate (ATO) and FedRAMP-equivalent processes apply to the DRCC deployment.
Financial services and regulated industries: Regulatory frameworks (PRA / FCA in UK, BaFin in Germany, MAS in Singapore, OSFI in Canada) increasingly require demonstrable data residency and operational sovereignty for cloud workloads. DRCC satisfies these requirements where public OCI cannot.
Healthcare and life sciences: HIPAA compliance, GxP validation requirements and the need for operational control over patient or trial data create sovereignty pressure. DRCC fits where the patient data must demonstrably remain within the customer’s direct control.
EU and UK data residency: GDPR and post-Brexit UK data protection requirements have driven demand for cloud services with verifiable physical and operational residency in the EU or UK specifically. DRCC and the EU Sovereign Cloud (a specific OCI configuration) both address this; DRCC offers full customer control over the deployment.
Sovereignty is also a negotiation lever in pricing. Customers with credible sovereignty constraints have access to Oracle’s sovereign-cloud pricing, which can differ materially from standard OCI. Engaging Oracle’s public-sector or sovereign-cloud commercial team rather than the general account team is frequently the difference between competitive and uncompetitive DRCC pricing.
Cloud@Customer eligibility is a frequent customer confusion. Not every Oracle product runs on every Cloud@Customer variant. Understanding the eligible product matrix before sizing the commitment is essential.
DRCC: Full OCI service catalogue. Oracle Database, Exadata, Autonomous Database, OCI Compute (all shapes including GPU), OCI Storage (Block, File, Object), OCI Networking, OCI Identity, Fusion Cloud Applications (specific releases), OCI AI services, Integration Cloud, GoldenGate, Analytics Cloud. Effectively the customer’s own private OCI region.
ExaCC: Oracle Database (all editions and options), Autonomous Database on Dedicated Infrastructure, Exadata Storage Server. Does not include the broader OCI compute, AI or PaaS catalogue.
Compute Cloud@Customer: OCI Compute (subset of public shapes), OCI Block Storage, OCI Object Storage, OCI Networking. Does not include database services or PaaS.
Database@Azure: Oracle Database Service on Exadata (with all standard options), Autonomous Database. Accessed through Azure portal; integrated with Azure identity, networking and monitoring. Does not include non-database Oracle Cloud services.
Customers planning to consolidate multiple Oracle workloads onto Cloud@Customer must verify each workload’s eligibility. EBS, PeopleSoft and JD Edwards typically require additional architecture on top of OCI compute — not a native Cloud@Customer service. Hyperion and OBIEE have specific deployment patterns. Fusion Middleware components vary in support level.
Cloud@Customer commercial terms appear standardised but are heavily negotiated in practice. Oracle’s Cloud@Customer commercial team has wide discretion on most non-published terms when the deal value justifies it (typically $5M+ contract value).
The eight highest-value negotiation levers in Cloud@Customer contracts:
Cloud@Customer contracts are some of the highest-stakes commercial agreements Oracle offers. Our team has advised on DRCC, ExaCC and Database@Azure negotiations at contract values from $5M to $80M+. Independent advisory pays for itself many times over on deals at this scale.
Cloud@Customer contracts run 36–60 months and are operationally and commercially difficult to exit early. Standard Oracle terms include exit penalties up to the full remaining contract value plus hardware-removal costs. Planning the exit before signing the contract is the only way to preserve real flexibility.
The three exit scenarios:
End-of-term exit: Customer chooses not to renew at end of contract. Oracle removes hardware; customer extracts all data. Standard exit terms apply: defined notice period (typically 12 months), data extraction format and timeframe commitments, hardware-removal logistics. Negotiated in the original contract.
Mid-term exit: Customer terminates before end of term. Standard Oracle position: full payment of remaining contract value. Negotiated outcomes: cost-recovery only (Oracle’s actual unrecovered hardware and deployment cost), typically 30–50% of remaining term value. Available only if negotiated into the original contract.
Refresh-cycle exit: Customer exits at the natural hardware refresh point (typically 4–5 years). Lower friction than mid-term exit but only available if the contract specifies refresh as an exit point.
Exit planning extends beyond commercial terms. Operationally, the customer must extract or migrate all data, services and configurations off Cloud@Customer to a successor environment. This is a substantial engineering project — typically 9–18 months for a fully utilised DRCC. Plan the exit operationally as part of the original deployment, not as an afterthought.
The strategic question worth asking before signing: what is your Plan B if Oracle Cloud@Customer does not deliver the value it promised, if Oracle’s strategic direction changes, or if the regulatory environment evolves? Customers who can credibly answer this question have stronger negotiation positions and lower exit risk than those who cannot.
A 36-page tactical manual covering Dedicated Region architecture, ExaCC vs public OCI economics, Database@Azure deployment patterns, BYOL optimisation, minimum-commitment sizing methodology and end-of-term exit planning.
Download Free →Weekly briefings on Oracle audit trends, LMS methodology changes, common claim types, and settlement benchmarks. Free. Read by ITAM leads, CIOs, and legal teams at global enterprises.
No spam. Unsubscribe anytime. Not affiliated with Oracle Corporation.
We manage Oracle audits from the first notification letter through final settlement. Former Oracle LMS consultants with insider knowledge of Oracle's claim methodology, working exclusively for the buyer.
✓ Confidential · ✓ Independent · ✓ Not affiliated with Oracle Corporation