What is Oracle Cloud at Customer?
- Hybrid Cloud Solution: Combines Oracle Exadata’s performance with cloud deployment in your data center.
- Enhanced Performance: High database performance and efficiency.
- Robust Security: Strong data protection features.
- Scalable: Easily scalable for growing business needs.
- Integration: Seamless integration with Oracle Cloud services.
What is Oracle Cloud at Customer
Oracle Cloud@Customer is an on-premises cloud solution that brings Oracle’s public cloud services into a customer’s own data center.
It delivers the benefits of cloud computing – fully managed infrastructure, elastic scaling, and subscription pricing – while allowing organizations to keep data and applications on-site for security, latency, or regulatory reasons.
In essence, Cloud@Customer offers a hybrid cloud approach: customers get Oracle’s cloud technology “at home,” under their control, but operated by Oracle as a service.
Read Oracle Exadata Cloud@Customer: 15 Critical Contract Insights for CIOs.
Understanding Oracle Cloud@Customer
Oracle Cloud@Customer is Oracle’s solution for enterprises that cannot fully migrate to the public cloud due to data residency requirements, network latency needs, or internal compliance regulations.
Instead of forcing these organizations to choose between traditional on-prem IT and the public cloud, Oracle delivers cloud hardware and services behind the customer’s firewall.
Oracle installs its cloud systems in the customer’s data center and remotely manages them, so the customer experiences Oracle Cloud Infrastructure (OCI) as if it were on-premises.
This unique model addresses common barriers to cloud adoption by providing:
- Data residency and security: Sensitive data remains on-premises in your own facilities, helping to meet regulatory or privacy requirements.
- Low latency: Applications can run alongside your data and users, eliminating the network latency associated with remote cloud data centers. This is crucial for mission-critical systems that demand fast, local response times.
- Cloud agility on-prem: You still get the cloud advantages – self-service provisioning, auto-scaling, and rapid deployment of resources – but within your controlled environment. Oracle handles hardware operations, patching, and updates, reducing your administrative burden.
- Consistent OCI experience: Cloud@Customer uses the same OCI services, APIs, and consoles as Oracle’s public cloud. This means developers and IT staff can use familiar cloud tools and easily move workloads between on-prem and Oracle Cloud regions as needed.
Key Offerings in the Cloud@Customer Portfolio
Oracle’s Cloud@Customer isn’t a single product, but rather a family of offerings designed to meet different needs.
The main options include:
- Exadata Cloud@Customer: A managed database cloud platform delivered via an Oracle Exadata system in your data center. This service is specifically designed for Oracle Database workloads. It allows you to run Oracle’s Autonomous Database or Exadata Database Service on-premises. Oracle owns and manages the Exadata hardware and infrastructure, while you consume scalable database services on it. Exadata Cloud@Customer is ideal for consolidating multiple databases onto a single high-performance platform or maintaining databases on-premises for compliance, all while utilizing a cloud consumption model.
- Compute Cloud@Customer: Oracle’s general-purpose cloud infrastructure brought on-premises. Oracle provides a rack of servers and storage that extends OCI compute, storage, and networking services into your data center. You can run virtual machines, containers, and applications on this private cloud just as you would in OCI’s public regions. Oracle manages the hardware and cloud software; you manage the VMs, applications, and any Oracle software you deploy on those instances. This option is suitable for cloud-native apps or legacy applications that require on-site deployment for low latency or data sovereignty. (Note: Database services aren’t automatically included with Compute Cloud@Customer, but you can run databases on VMs or pair it with an Exadata system.)
- OCI Dedicated Region: A full Oracle Cloud region on-premises, delivering the entire portfolio of Oracle cloud services (IaaS, PaaS, and even Oracle SaaS applications) at your site. Oracle installs a mini-region, starting with multiple racks of gear, providing over 100 cloud services (compute, storage, database, analytics, middleware, and more) specifically for you. This is essentially Oracle’s public cloud replicated in your data center, with all the same capabilities and a consistent experience. Dedicated Region is targeted at large enterprises or governments that require a wide range of cloud services on-premises – for example, running Oracle Fusion SaaS applications (ERP, HCM, etc.) in-country for sovereignty, or modernizing an entire data center to cloud technology without using a public region. It requires a significant commitment and is the most comprehensive (and high-end) Cloud@Customer option.
Illustration: Oracle’s Cloud@Customer portfolio bridges on-premises and public cloud. It ranges from a single Exadata Cloud@Customer rack for databases to a multi-rack Dedicated Region that mirrors a full Oracle Cloud region on-site.
Each Cloud@Customer variant addresses specific use cases,but they share common traits: Oracle retains ownership of the infrastructure (hardware remains Oracle’s property), handles all maintenance/patching, and updates the on-premises services in sync with their public cloud equivalents.
The customer, on the other hand, must provide the data center space, power, cooling, and network connectivity for these racks.
You’re essentially hosting Oracle’s equipment in your facility, so you’ll need to plan for the physical and networking requirements (including a connection to Oracle’s cloud network for remote management and updates).
Benefits and Use Cases
Oracle Cloud@Customer offers a compelling proposition for enterprises that balance cloud innovation with strict on-premises requirements.
Key benefits and scenarios include:
- Regulatory Compliance and Data Sovereignty: Industries such as banking, healthcare, and government often have laws requiring sensitive data to remain on domestic soil or within secure facilities. Cloud@Customer enables these organizations to utilize cloud services without transferring data to a public cloud data center. For example, a government agency can run Oracle’s cloud databases and analytics on-prem to satisfy national data sovereignty laws, or a bank can keep customer financial data on-site while leveraging cloud automation.
- Low-Latency, High-Performance Apps: Some applications require extremely low latency or high throughput, which is challenging to guarantee over WAN links to a public cloud. With Cloud@Customer, compute and storage reside in the same building as the application users or connected systems. For instance, a trading firm could deploy an Exadata Cloud@Customer adjacent to its trading engines to ensure millisecond-level response times, or a telecom company could run network functions on a local OCI Compute Cloud@Customer rack to meet its real-time processing needs. High-performance database workloads also benefit – Oracle cites that Exadata Cloud@Customer can run mission-critical databases faster and at lower cost than some on-prem setups, thanks to Exadata’s optimized hardware and Oracle’s automation.
- Cloud Consistency and Modernization: Cloud@Customer is attractive for organizations that want to modernize legacy systems using cloud services but are not yet ready (or not permitted) to move entirely off-premises. Because Oracle’s on-prem cloud services use the same APIs and management tools as OCI, developers can build cloud-native apps on-prem and later move them to Oracle Cloud (or vice versa) with minimal rework. This hybrid flexibility is useful in phased cloud adoption strategies. For example, an enterprise might start by consolidating dozens of old databases onto an Exadata Cloud@Customer (to get immediate cost and management gains), and over time migrate some workloads to Oracle’s public cloud, using the on-prem cloud as a bridge.
- Reduced IT Operations Burden: With Oracle handling routine maintenance (such as hardware replacement, patching, and upgrades), internal IT teams can focus more on higher-level tasks. This is especially beneficial for database environments – running Oracle Autonomous Database on Exadata Cloud@Customer means many DBA tasks (tuning, patching, backups) are automated by Oracle. Customers have reported significant savings in operational effort, as well as faster deployment times for new projects (since provisioning resources is self-service via cloud interfaces rather than manual). Essentially, you get an on-premises “as-a-service” model: no need to procure hardware or perform low-level admin, yet you keep the solution in-house.
- Financial Considerations: Cloud@Customer shifts spending from capital expenditure (CapEx) to operational expenditure (OpEx). There’s no large upfront purchase of hardware; instead, you subscribe to the service. This can be attractive if you prefer predictable monthly costs or need to align with cloud budget models. Oracle’s pricing for these services is consumption-based, so you pay for what you use (subject to certain minimums). In some cases, consolidating workloads on a Cloud@Customer platform can also reduce software licensing costs or overall total cost of ownership, especially if it replaces many under-utilized servers with one optimized system. However, it’s essential to fully utilize the provided capacity, as you’re paying a base fee regardless. Cloud@Customer is most cost-efficient at higher utilization levels (we discuss pricing in the next section).
Pricing and Licensing Model
Subscription Model & Multi-Year Term: Oracle Cloud@Customer is provided as a subscription service with a multi-year commitment.
Typically, Exadata Cloud@Customer and Compute Cloud@Customer require a minimum term of 4 years, while Dedicated Region contracts start at 5 years. You don’t buy the hardware outright; Oracle deploys it and essentially “rents” it to you as part of the service.
Your contract will specify an annual or monthly fee structure that covers the infrastructure plus cloud service usage.
This model means lower upfront costs, but it locks you into Oracle’s services for the duration, so you’ll want to negotiate terms carefully (e.g., pricing protections and the ability to adjust capacity over time).
Pricing Components: The cost of Cloud@Customer consists of two main parts: a fixed base fee for the on-premises infrastructure, and variable charges for cloud service usage (similar to a public cloud bill).
In effect, you commit to a certain capacity and pay usage rates on top.
- Infrastructure Base Fee: This covers the Oracle-supplied hardware, its maintenance, and support. For example, an Exadata Cloud@Customer Base System (a smaller Exadata configuration) typically has a base monthly price of around $8,000. Larger multi-rack Exadata configurations can run tens of thousands of dollars per month for the infrastructure portion. Compute Cloud@Customer has a smaller base (around $5,000/month for a single-rack setup), as it delivers commodity compute/storage hardware. Think of the base fee as the cost to have Oracle park the equipment in your data center and maintain it. You pay this regardless of usage (much like leasing a car, you pay the lease even if the car sits idle).
- Resource Usage Fees: On top of the base, you pay for the actual cloud services consumed (measured in OCPUs, GB of storage, etc.), billed at the same rates as Oracle’s public cloud. This is key: Oracle doesn’t generally mark up the per-unit cloud costs for on-prem; you get standard OCI pricing for vCPU, storage, database hours, etc. For example, if you use 10 OCPUs of compute on a Compute Cloud@Customer for an hour, you pay roughly the same as 10 OCPUs for an hour in OCI (around $0.03 per CPU-hour for a standard VM shape). Similarly, database OCPUs on Exadata Cloud@Customer are billed per hour, and storage is billed per terabyte per month at OCI’s block storage rates (e.g., ~$0.0255 per GB/month for high-performance block storage). The key difference is that on-prem, you also have that base fee running in the background. If your utilization is high, Cloud@Customer can be very cost-effective (you’re consuming a lot of resources for the fixed base cost). If utilization is low, you’ll be paying a premium for underused hardware.
License-Included vs BYOL: For Oracle software (like Oracle Database) running on Cloud@Customer, there are two licensing approaches:
- License-Included: You pay for the Oracle software as part of the service subscription. This means that the hourly rate for a service (such as an Oracle DB OCPU hour) includes the cost of the Oracle license and support. It’s a “rent the license” model – straightforward if you don’t already own licenses. However, it comes at a premium price. For instance, the list price for an Oracle Database Enterprise Edition OCPU on Exadata Cloud@Customer is approximately $1.34 per hour (license-included). This rate covers everything – the database software license, support, and the Exadata infrastructure usage. You simply pay as you go, and Oracle takes care of compliance.
- Bring Your Own License (BYOL): You use your existing Oracle software licenses on the Cloud@Customer platform. In this model, Oracle charges you a much lower rate for the infrastructure service because you’re providing the license entitlement. For example, the BYOL rate for that same Oracle DB OCPU might be around $0.32 per hour, roughly one-quarter the cost, because you aren’t paying Oracle again for a license you already own. BYOL can yield major savings if your organization has already invested in Oracle licenses and is paying support on them. It lets you leverage those sunk costs. However, you must ensure you have the proper license editions and enough license quantities to cover the Cloud@Customer usage (Oracle has rules mapping cloud usage to on-prem licenses; e.g., 1 Oracle processor license covers 2 OCPUs in the cloud for Intel/AMD-based systems). You also continue to pay the annual support for those licenses to keep them valid.
Choosing between BYOL and license-included depends on your situation. Many enterprises use a hybrid approach: for steady workloads where they have spare licenses, they opt for BYOL to save money, but for new or burst workloads, they might use license-included for flexibility.
It’s essential to plan this upfront, as it significantly affects the cost. For instance, consider a small Exadata Cloud@Customer deployment averaging 16 OCPUs of database usage:
- Using BYOL, the monthly cost is approximately $12,000 (plus any additional fees for license support). This includes approximately $8,000 in base infrastructure and approximately $4,000 in OCPU usage fees at the lower BYOL rate.
- Using License-Included, the same usage could cost around $23,000 per month, all-inclusive (approximately $8,000 base + $15,000 usage at the higher rate).
In this example, owning licenses nearly halved the ongoing costs. Over a multi-year term, that difference is enormous. Thus, if you have existing Oracle licenses, it’s usually cost-optimal to apply them in Cloud@Customer.
On the other hand, if you lack certain licenses (or don’t want to manage compliance), the subscription model is simpler – you just pay Oracle’s rates and everything is covered.
Bottom line: carefully evaluate BYOL vs included pricing for each Oracle product you plan to run, and factor in your current support spend and license entitlements before finalizing the contract.
Dedicated Region Pricing:
The Dedicated Region Cloud@Customer features a distinct pricing approach. Instead of charging a specific base per rack plus usage, Oracle requires a minimum annual spend commitment (a dollar figure per year for cloud services).
For example, Oracle initially required at least $6M per year for a Dedicated Region, but it later lowered the entry point – as of recent years, it’s roughly $1M per year with a five-year minimum term (so about $5M total commitment).
In practice, Oracle will deploy a set of racks sized to support that level of usage (perhaps a dozen racks or more), and you can consume any OCI services within that private region, drawing down against your committed credits.
If you exceed your commitment in a given period, you will be charged the overage at regular cloud rates; if you use less, you will still be charged the committed minimum.
The key advantage is that you get a whole cloud on-prem, and Oracle maintains price parity with public cloud rates for all those services. The trade-off is you’re locked into a significant spend.
Dedicated Region only makes financial sense for large-scale cloud usage (think of it as suitable for enterprises that would otherwise spend millions on public cloud, but instead want it on-prem).
Oracle has made it more accessible by allowing a “start small” footprint, but it remains a substantial investment and is thus heavily negotiated on a case-by-case basis.
Contract and Negotiation Considerations
Adopting Oracle Cloud@Customer is not just a technical decision – it’s a major contractual commitment.
As an Oracle licensing and contract negotiation expert, here are some key considerations to keep in mind when structuring your agreement with Oracle:
- Know Your Requirements and Scale: Before entering an agreement, assess the workloads and capacity you need. Oracle will size the Cloud@Customer solution (including the number of racks, etc.) based on your expected usage. Be realistic – overcommitting will result in paying for unused capacity, while underestimating could hinder performance or necessitate an expensive expansion later. Define how many OCPUs, how much storage, and what services you require on day one, and consider growth over the term. This will determine the minimum commitment that Oracle requires.
- Multi-Year Commitment and Spend: Cloud@Customer contracts lock you in for years, so negotiate terms that align with your business plans. For instance, if you commit to a 5-year Dedicated Region, ensure you’re confident in using those resources for that period. Try to include flexibility in the contract: Can you increase capacity later at the same discounted rate? Are you allowed to decrease usage if needs change (usually not, but it’s worth asking if some downward adjustment is possible in later years)? Understand any annual true-up processes for usage overages. Everything in these big deals is negotiable to some degree – including the minimum spend and the discount levels – especially if Oracle is keen to win your business. Don’t accept the list terms without question.
- Pricing and Discounts: Given the high cost of these solutions, push for discounts on both the base fees and the cloud service rates. Enterprise agreements with Oracle often include negotiated universal credit discounts (e.g., a certain percentage off consumption rates or a better price per hour for database usage). Oracle may present a standard price, but treat it as a starting point. It’s helpful to prepare a comparison of alternatives (e.g., what if we stayed on existing infrastructure, or used another vendor’s hybrid offering) to leverage in negotiations. If Oracle knows you have other options, you’re more likely to get a competitive deal. Aim for clear pricing transparency – get a breakdown of what the base fee includes and how usage will be measured and charged. Ensure the contract specifies the rates for any additional services you might enable (for example, if later you activate an Oracle SaaS app in a Dedicated Region, is that covered or extra?).
- Service Level Agreements (SLAs) and Support: Clarify the SLAs Oracle will provide for the on-prem services. Oracle Cloud@Customer is supposed to match public cloud SLAs for availability and performance. Ensure these are written into the contract, including remedies if Oracle fails to meet them. Since Oracle manages the hardware and services, you’ll rely on their support, negotiate support response times, and possibly a designated support team or technical account manager for your deployment. Also, confirm the process for hardware repairs or replacements (Oracle should handle this promptly as part of the service – the contract should outline those support commitments). Knowing that critical systems will be running on this platform, you want confidence in Oracle’s support obligations.
- Operational Responsibilities: The contract should delineate Oracle’s responsibilities versus yours. Generally, Oracle is responsible for the infrastructure up to the cloud service layer, and the customer is responsible for what they do with it (the classic “shared responsibility model”). Ensure it’s clear who is responsible for security at various levels, data backups (if not using an Autonomous service that handles it automatically), and updates. Oracle Cloud@Customer will require connectivity to Oracle’s cloud for management – ensure network requirements and security measures are documented (for example, Oracle often uses a secure connection to perform remote management; you might want assurances on data access and isolation). You will need to provide physical security for the hardware (it resides in your data center, after all), so consider this in your internal planning and have it acknowledged in the agreement.
- Exit Strategy and Lock-In Mitigation: Plan for the end of the contract before you sign. This is critical: what happens when your term is over, or if you choose not to renew? Typically, Oracle will remove its equipment from your premises. You need to ensure that you can retrieve your data and transition smoothly. Negotiate terms for data export and assistance from Oracle to migrate workloads either to Oracle’s public cloud or to an alternative platform if you decide to exit. You may seek an option to extend or renew at predetermined rates, or a clause that allows Oracle to assist in migrating you to public OCI (perhaps even temporarily running in the public cloud at a similar cost if there’s a gap).Additionally, since this is a long-term commitment, consider including termination clauses that protect you in the event of unforeseen circumstances – for example, if Oracle fails to deliver on certain capabilities or if there are persistent SLA breaches. While Oracle Cloud@Customer inherently involves vendor lock-in (the solution is unique to Oracle’s ecosystem), you can mitigate risk by keeping applications as portable as possible and by having a fallback plan for critical workloads. Ensure your team periodically reviews whether the arrangement remains cost-effective, allowing you to initiate renewal negotiations well in advance or plan alternatives.
In summary, treat the Cloud@Customer contract like any large outsourcing or managed service deal. Involve your procurement and legal teams to cover all bases, including costs, performance guarantees, security compliance, and exit terms.
Oracle will handle the technical heavy lifting, but you must protect your organization’s interests through a well-negotiated agreement.
Recommendations
- Evaluate Fit for Purpose: Determine if Oracle Cloud@Customer truly aligns with your needs. It’s best suited for scenarios requiring on-premises data control or extreme low latency. If you have mostly standard workloads without such constraints, a public cloud or simpler solution might suffice. Use Cloud@Customer strategically where it adds clear value (e.g., regulatory compliance, consolidating dozens of Oracle databases, or running Oracle SaaS in-country).
- Perform a Cost-Benefit Analysis: Before committing, crunch the numbers to determine the best course of action. Compare the total 4-5 year cost of Cloud@Customer (including base fees, expected usage, and license costs) against alternatives (staying on existing infrastructure, using public cloud, or other vendors’ hybrid solutions). Ensure that the benefits (improved performance, lower operational overhead, license optimization, etc.) justify the expense. Cloud@Customer can be cost-efficient at scale, but you want to avoid paying for unused capacity.
- Optimize License Usage (BYOL vs. Included): Include a license strategy in your plan to optimize license usage. Inventory your existing Oracle licenses and support contracts. If you have substantial investments, plan to BYOL to Cloud@Customer for those workloads – it will significantly reduce the cloud costs. For any new capabilities (e.g., adding Oracle Autonomous Database or extra features you don’t own), factor in the higher license-included rates. Consider consolidating and reassigning licenses from retired systems to this environment. Also, ensure you remain compliant with Oracle’s licensing rules in the cloud model (understand the OCPU to license core conversions and any minimums).
- Negotiate the Contract Aggressively: Engage Oracle early with a clear understanding that you expect a partnership, not just a standard sale. Push for volume discounts commensurate with your commitment. Everything, from the base fee to the per-hour rates, can be discussed and negotiated. Also negotiate practical terms: the ability to add capacity at locked-in rates, caps on annual price increases (if any), and service credits or penalties if SLAs are missed. Use any leverage you have – such as a pending license renewal or competing cloud proposals – to get the best deal.
- Plan Deployment and Resources: Collaborate with Oracle to develop a detailed deployment plan. Ensure your data center is ready (power, cooling, rack space, network links). Schedule the installation at a time that minimizes disruption. Have your network team coordinate the connectivity setup with Oracle (e.g., VPN or dedicated line to Oracle’s cloud for management). Identify applications and databases to migrate to the new platform and prioritize them. It’s wise to run a pilot or proof-of-concept on the Cloud@Customer environment if possible, to validate performance and processes before full production use.
- Prepare Your Team and Processes: Treat Cloud@Customer adoption as a transformational project for IT operations. Train your DBAs, sysadmins, and developers on OCI’s interfaces and the differences in this model (for example, DBAs will deal with cloud service consoles and automated features rather than installing software on servers). Update your operational procedures for backup, disaster recovery, and monitoring to integrate Oracle’s managed service components. While Oracle takes care of infrastructure, your team will still manage application-level tasks and needs to adapt to a cloud-like operating model on-prem.
- Monitor Usage and Adjust: After deployment, closely monitor your resource consumption against your planned usage. Cloud@Customer provides usage metrics – use them to optimize your cloud environment. For instance, scale down OCPUs on non-production databases during off hours to save on hourly charges, or power off unused VMs. The beauty of this model is that you can dynamically adjust usage to control costs, thereby instilling a cost management discipline. Over the years, if your capacity needs grow, plan expansions proactively and negotiate terms for additional racks or higher commitment well in advance.
Checklist (5 Key Actions)
- Identify Candidate Workloads: List the databases and applications that require on-premises cloud deployment (due to data sensitivity or latency). Ensure they are suitable and supported on Oracle Cloud@Customer.
- Assess License Inventory: Document all relevant Oracle licenses your organization owns. Decide which ones can be allocated to Cloud@Customer (BYOL) and identify any gaps where you’ll need Oracle to provide licenses in the subscription.
- Infrastructure Readiness: Verify that your data center can accommodate the Oracle-supplied racks (including space, power, and cooling). Set up the necessary network connectivity (low-latency link to Oracle Cloud for control plane, plus any integration to your internal network).
- Engage Stakeholders for Negotiation: Assemble a negotiation team including IT, procurement, finance, and legal. Develop a negotiation plan that covers desired discounts, contract terms (including SLAs and exit clauses), and an internal budget threshold. Engage with Oracle through an RFP or workshop to receive a detailed proposal, and then negotiate to align it with your specific requirements.
- Plan Migration and Go-Live: Develop a migration plan to move workloads to Cloud@Customer. This should include timelines for installation, testing, data migration, and cutover for each workload. Also, outline a governance process for ongoing management (who in your team will interface with Oracle support, how you’ll monitor usage and performance, etc.). With a clear plan, you can smoothly transition to the new platform and begin to realize its benefits.
FAQ
Q1: How is Oracle Cloud@Customer different from Oracle’s public cloud?
A: Oracle Cloud@Customer is essentially the same technology and services as Oracle’s public cloud (OCI), but deployed on-premises at the customer’s site. The key difference is location and control – with Cloud@Customer, all the hardware resides in your data center, and data remains on your premises. You get the same APIs, cloud services, and updates as OCI, but in a dedicated environment just for you. Oracle’s public cloud, by contrast, is in Oracle’s data centers and is a shared environment for many customers. Cloud@Customer provides cloud benefits under your direct governance, making it ideal for cases where using the public cloud is not feasible or desirable.
Q2: What are typical use cases for Oracle Cloud@Customer?
A: The most common use cases involve requirements for data residency, strict security, or ultra-low latency that prevent using a remote public cloud. For example, banks and healthcare institutions utilize Cloud@Customer to run databases and applications on-site, thereby complying with local privacy laws. Governments leverage it to keep sensitive systems on sovereign soil. It’s also used when an application demands very fast response times (like factory floor systems or high-frequency trading) – hosting the compute and data locally avoids internet latency. Additionally, organizations with heavy Oracle Database usage use Exadata Cloud@Customer to consolidate databases onto a managed platform without migrating to the cloud. In short, if you need cloud capabilities but must keep it on-premises, Cloud@Customer is Oracle’s solution.
Q3: How does pricing work for Cloud@Customer – is it cheaper or more expensive than regular cloud?
A: Cloud@Customer uses a subscription pricing model similar to cloud, but with some fixed costs. You pay a monthly base fee for the dedicated on-prem hardware, then pay for your resource consumption (CPU hours, storage, etc.) just like in Oracle’s cloud. The per-unit rates for usage are the same as Oracle’s public cloud list prices. Whether it ends up being cheaper or more expensive depends on your usage: if you utilize the on-premises equipment fully, the costs per resource can be on par or even better than those of the public cloud (since Oracle often offers discounts for commitment). However, if you only use a small fraction of the capacity, Cloud@Customer may appear expensive because you’re paying for a lot of hardware, regardless. Compared to a DIY on-premises environment, Cloud@Customer may reduce some costs (such as hardware management and potentially software licenses if you consolidate systems). Still, you should expect it to be a premium service. It provides value through agility and managed support, rather than solely focusing on raw cost savings for every scenario. In any case, a careful cost analysis is needed – Oracle will typically work with you to develop a cost model that illustrates the economics.
Q4: What are my responsibilities with Oracle Cloud@Customer versus Oracle’s responsibilities?
A: Oracle Cloud@Customer is a fully managed service, but it’s a partnership. Oracle takes care of anything related to infrastructure: they deliver and install the hardware, monitor and maintain it, apply patches and updates to the underlying software, and ensure the cloud services are running (much like they do in their public cloud). Oracle is also responsible for troubleshooting hardware issues and will replace components or even entire racks if needed. Your organization is responsible for using the services: that means managing your applications, VMs, and databases running on the platform (unless you’re using an Autonomous Database, in which case Oracle manages much of the database operation as well). You also handle your data – Oracle doesn’t access customer data; that remains under your control. Additionally, you provide the physical environment (including floor space, power, and cooling) and network connectivity for the equipment. Think of it as Oracle providing a cloud-as-a-service on-premises solution, with a clear line: Oracle manages the cloud infrastructure, and you manage what you deploy on it. Both sides work together on security (Oracle secures the infrastructure; you must secure your accounts, users, and any data encryption you want on top). It’s essential to review Oracle’s shared responsibility documentation to understand exactly who is responsible for what.
Q5: What should we negotiate or look out for in an Oracle Cloud@Customer contract?
A: When negotiating, focus on commitment terms, cost protections, and exit strategy. Key items: (1) Commitment size and term: Ensure the required minimum spend or capacity aligns with your needs; negotiate it down if it’s more than you require, and confirm the term (years) is acceptable. (2) Discounts and pricing: Push for better rates on the base fee and usage. With a large commitment, you have leverage to get substantial discounts. Additionally, clarify how pricing might change over time (ideally by locking in rates or capping increases). (3) Service Levels: Get uptime and performance SLAs in writing, with credits or remedies if they’re not met – you need Oracle to be accountable since your critical systems will rely on this. (4) Support and updates: Outline Oracle’s support response obligations and how updates/upgrades will occur (schedule, notifications, etc.) to avoid surprises. (5) Exit terms: This is crucial – have clauses for how you can exit or transition after the term. For example, ensure you can renew at a reasonable rate or that Oracle will assist in migrating workloads to another environment if you choose not to continue. You don’t want to be stuck with an unusable setup or pressured into a costly renewal. Lastly, involve legal to cover data security and compliance requirements – because the service touches sensitive data on your premises, you may need specific terms for liability or data handling. All these factors will ensure that you receive a fair deal and achieve a successful long-term outcome.
