Oracle Cloud at Customer: the rack sits in your building, the control plane does not.

Oracle Cloud at Customer puts Oracle owned, Oracle operated racks in your data center and bills them as a cloud service. The decisions that matter are the service boundary, what still leaves the building, and who is accountable at 3am.

What is Oracle Cloud at Customer, and which product are you buying?

Oracle Cloud at Customer is a family of Oracle owned, Oracle operated racks installed in your own data center and billed as a cloud service. It is four products under one brand. They share a delivery model, with Oracle owning the hardware and running it remotely, and very little else.

There is no common service catalog, control plane design, minimum commitment or operating model across the four. Buyers who evaluate the brand as one decision tend to get sized for the wrong product, so start by naming which one is on the table.

Exadata Cloud at Customer gives you Oracle Database services and nothing else, so your application servers still need a home. Compute Cloud at Customer fills that gap with general purpose OCI compute. A Dedicated Region brings the wide OCI catalog, against a proportionally wider commitment, and our platform comparison runs the two side by side.

Which Oracle offers are not Cloud at Customer?

Three adjacent offers regularly end up in the same evaluation and waste weeks of it. None of them puts an Oracle operated rack in your building.

• Oracle Database@Azure, @Google Cloud and @AWS. Oracle owned Exadata in a hyperscaler's data hall, bought through that cloud's marketplace. We cover the commercial side in multicloud Universal Credits.
• Oracle Alloy. A cloud platform that a partner runs and resells under its own brand. It is a licensing model for service providers, and a typical enterprise does not buy it.
• Roving Edge. Ruggedized field hardware for remote and mobile sites.

One newer product deserves a separate note. Compute Cloud@Customer Isolated, announced in June 2025, is an air gapped variant for classified and sovereign workloads that runs disconnected from public OCI on a 48 month minimum lease. The control plane points below apply to the connected products, which is what nearly every commercial buyer is offered.

Why do companies choose Cloud at Customer in the first place?

The driver is almost never cost. In the engagements behind this page, the trigger was a regulator, a latency constraint, or an Exadata refresh that arrived at the same time as a cloud mandate. Cost cases do exist, but they are usually built after the decision, to justify it.

Treat that sequence as a warning sign. Test the residency claim with your legal team before you test the spreadsheet, because a residency case that fails review takes the cost case down with it.

What still leaves your building with Oracle Cloud at Customer?

Your data stays on the rack unless you send it somewhere, but the service that operates the rack runs elsewhere. Every connected Cloud at Customer product calls back to a linked OCI region for provisioning, scaling, patching orchestration and console visibility. Operational metadata, diagnostics, performance telemetry and support artifacts travel to Oracle by design.

When the link to the region drops, running databases keep serving and everything else stops. You cannot provision, scale or see the system in the OCI Console until the connection returns. Oracle's data sheet states that interruptions to the control plane link do not affect database availability, which is accurate and says nothing about operations.

Where residency business cases fail at the second legal review

The rack is local and the control plane is not. That gap has sunk residency cases when counsel read the service description a second time. If a regulator is the driver, write these points into the order before you sign.

• Telemetry scope. A description of the metadata, diagnostics and support artifacts that leave the site, and where Oracle processes them.
• Backup targets. Exadata Cloud at Customer can back up to local Exadata storage, a Zero Data Loss Recovery Appliance, an NFS target, or Object Storage in the linked region. The last option relocates copies of your data off site, so decide it explicitly per database.
• Operator access. Oracle Operator Access Control gives you approval over when Oracle staff reach the infrastructure and records their commands and keystrokes. It costs nothing extra, and it needs a named approver who will answer at 2am.
• Network resilience. Redundant paths to the region, and a written runbook for what your team does while the console is unreachable.

Who patches and secures what on Exadata Cloud at Customer?

Oracle patches the physical infrastructure, and you patch everything from the guest operating system up. You get root on the guest virtual machines and nothing below them. That split lands on your security team at least as hard as on your database team.

What your security team has to approve before the rack ships

The hypervisor on the database servers, the storage servers, the flash tier and the internal fabric are Oracle managed and not reachable by you. Endpoint agents, configuration management, vulnerability scanners and log shippers only reach the guest VMs.

If your security standard says every host runs the agent, you now need a documented exception covering roughly two thirds of the physical stack. Get it approved before delivery and cite the Operator Access Control logs as compensating evidence. Otherwise your first internal audit finds the gap and asks for remediation of a control you cannot implement.

How does infrastructure maintenance work day to day?

Managed cloud does not mean managed database patching. Oracle updates the infrastructure every quarter and applies security fixes monthly, online, on a calendar you influence but do not own. Your own quarterly database patches still sit on top of that.

• Set the window before go live. Configure maintenance preferences during onboarding, before the first notification arrives.
• Choose rolling or non rolling on purpose. Rolling is the default and takes one database server offline at a time. Non rolling finishes faster and takes the whole system down.
• Name a deferral owner. Quarterly maintenance can be moved to no more than 180 days after the previous one. Deferrals that no one owns run into that limit and turn into forced windows.

What changes with Autonomous Database on the same rack?

Autonomous is the one variant where Oracle also takes over database operations. You give up control in return, because your DBAs lose direct access to configuration they are used to owning. Pilot one real workload before you commit the rest, and read the Autonomous Database licensing guide for how it is metered.

How is Oracle Cloud at Customer billed?

You pay two charges, and conflating them is the most common modeling error we see. A fixed infrastructure subscription pays for the installed rack every month of the term, whether a workload touches it or not. A variable service charge pays for the compute you enable, so scaling database compute to zero leaves the fixed charge intact.

Both run through Oracle Universal Credits. You commit to a spend over a term and draw it down, and unused commitment expires without rolling forward. Our guide to Oracle cloud contracts and credits covers the credit mechanics in detail.

What Oracle's published terms set for Exadata Cloud at Customer

• Term. The infrastructure has to be subscribed for a 4 year term, which is 48 months of the fixed charge.
• Compute metric. Exadata database services historically billed per OCPU per hour, one OCPU being one physical core with hyperthreading enabled. Autonomous services moved to the abstracted ECPU, and the current X11M generation licenses Exadata Database Service by ECPUs allocated to a VM cluster.
• Minimum compute. The published minimum is 8 ECPUs per database node.
• Late expansion. Expansion servers and racks end on the same date as the primary rack. Oracle's pricing page multiplies their monthly price by a rack term factor of 48 divided by the remaining months, so a server added with 24 months left costs double the monthly rate.

The metric change matters beyond billing, because it also changes how BYOL entitlements are consumed. Check the current service description for your exact service and generation, and see the OCI cost optimization page for how we work the conversion.

A worked example of the two bills

Say a company is offered Exadata Cloud at Customer with a hypothetical infrastructure subscription of $50,000 a month. Its measured steady state database compute is worth $800,000 a year in Universal Credits. Both figures are invented for illustration. The 30 and 22 percent figures in the table are the medians from our own deals.

Read the three commitment rows as options. Even after a typical negotiated cut, Oracle's number still sits above measured demand, so any slack in a given year is simply lost.

At 75 percent of measured demand, the remaining $200,000 of use is paid as it happens, and demand would have to fall by a quarter before any committed credit went unused.

The fixed subscription runs to $2,400,000 over the 48 months, and it earns no Support Rewards, because Oracle excludes the base rack subscription from accrual. If 35 percent of that installed capacity sits unused, $210,000 a year pays for nothing, which is $840,000 over the term.

The rack is installed once, and the subscription is paid every month.

Should you bring your own license or pay license included on Cloud at Customer?

Make the choice workload by workload. Bring your own license (BYOL) buys a lower service rate, while license included costs more and contains your audit exposure. The right answer often differs between a production cluster and a test cluster on the same rack.

• BYOL. Requires an entitlement baseline you can prove and active support on every license you count. A wrong baseline carries forward onto a platform that Oracle now meters directly.
• License included. A higher rate that buys containment of exactly that audit exposure. It suits workloads whose licenses came through acquisitions or have gaps in their paper trail.

How to run the four number comparison

Price both paths with Oracle Support Rewards applied and both without, then put the four numbers side by side. It takes about 15 minutes, and it has moved seven figure decisions in our work. Rewards accrue at 25 percent of eligible consumption, or 33 percent with a current ULA, and expire 12 months after deposit.

Rewards can only be spent on technology license support renewals. That makes them worth most to a BYOL buyer who keeps paying support on the licenses it brings across. The Support Rewards guide covers the redemption rules, and the bring your own license guide covers the conversion mechanics.

What have we seen in recent Cloud at Customer negotiations?

Across 2024 and 2025 I built roughly 18 to 24 Cloud at Customer cost models and advised on 15 to 25 Oracle hybrid and Cloud at Customer engagements. Another 10 to 15 infrastructure negotiations touched the platform. These counts describe the same accounts from different angles, so we do not add them together, and each finding below measures something different.

• Oversized at signing. Oracle's initial OCPU commitment sat a median 30 percent above measured steady state demand. The median reduction we negotiated was 22 percent.
• Idle minimums. Capacity sized to peak projections left 25 to 45 percent of the committed footprint idle. Minimums signed at full forecast left 25 to 35 percent idle by year two in half the deals.
• Scaling drift. In roughly half the accounts, unreviewed online scaling pushed spend 20 to 40 percent over forecast. Each increase was justified when it was made, and none was ever reversed.
• Entitlement mapping errors. Mistakes on option packs and processor conversions inflated Oracle's first proposed sizing by 20 to 40 percent. BYOL eligibility was overstated in half the deals, where legacy licenses did not map cleanly to the conversion ratio.
• The operating model gap. In 2 of every 3 engagements, the customer had not staffed or trained for split responsibility before go live. The first quarterly maintenance window was where they found out.

Day two is a shared operations model most teams have never run. You keep a database team, lose control of the infrastructure, and gain a scheduling dependency on a vendor.

Why buying headroom up front is the wrong instinct

The usual advice is to commit to peak plus growth, because capacity expansion is a procurement and logistics event with a lead time in months. We disagree. Idle capacity is paid in full every month and never appears on an invoice as idle, so the headroom costs you from day one whether or not the growth arrives.

Size the floor to steady state instead, and buy the headroom through negotiated expansion at locked signature rates. Then deal with the lead time by planning expansion one or two quarters ahead of need, which is a procurement discipline your team can own.

How do you keep scaling and idle capacity under control after go live?

Treat every scaling action as a spending decision with an approver. Compute scales up without downtime from a single console call by anyone with permission, and that ease is what drives the drift. Put these controls in place in the first month.

1. Restrict who can scale. In OCI IAM, the use verb on vmclusters, together with use on the Exadata infrastructure resource, allows a user to update a VM cluster, including its compute count. Grant that pair to one named group only.
2. Require a ticket with an expiry date. Every increase needs an owner and a date on which it is reviewed for reversal.
3. Review enabled compute monthly. Compare enabled capacity per VM cluster against actual consumption, and scale down what the tickets no longer justify.
4. Report the fixed footprint as its own line. Use of the installed rack belongs in the monthly cost review next to the credit burn.

Where to check your own position

What will Oracle's account team say, and how should you answer?

Most Cloud at Customer proposals come with the same handful of lines. Each has a factual core, and each has a specific reply that keeps the discussion on your numbers.

• "Size for peak now, because adding capacity later takes months." Reply that you will commit to measured steady state and take expansion at signature rates, written into the order with the rack term factor capped.
• "Your data never leaves your data center." Agree for customer data, then ask for the telemetry scope, support artifact handling and backup targets to be written into the order.
• "It is a managed service, so your team gets time back." Point out that guest operating systems, Grid Infrastructure and database patching stay with you, and ask Oracle to reflect that in the staffing assumptions of its business case.
• "Your existing licenses convert cleanly under BYOL." Ask for the mapping line by line, by customer support identifier and including option packs, before you accept any sizing built on it.
• "This pricing is only available if you sign this quarter." Ask for the same discount to apply to expansion for the full term, which tests whether the price is about timing or about volume.

Which contract terms should you negotiate before you sign?

Negotiate six terms as one package, because each one covers a gap the others leave open. A deal with a good unit rate and none of these terms still pays for idle capacity, drift and late expansion.

Scaling governance costs nothing to set up and is the highest return control on this platform, so launch it on the day the contract starts. The Oracle practice runs this negotiation with you, and the BYOL versus license included cost comparison has more worked pricing.

What to do next

1. 12 months out. Write down the real driver, whether regulator, latency or an Exadata refresh, and have legal test the residency claim against the service description.
2. 9 months out. Measure steady state compute demand and map every license you plan to bring by customer support identifier, option packs included.
3. 6 months out. Price BYOL and license included per workload, with and without Support Rewards, and set your commitment at 70 to 80 percent of the result.
4. 4 months out. Put the security exception for the Oracle managed layers and the telemetry scope through approval.
5. 3 months out. Negotiate the six contract terms as one package against Oracle's sizing proposal.
6. Before go live. Set the maintenance window, name the deferral owner and the 2am approver, and restrict scaling to one group.
7. Every month after. Review enabled compute against consumption and the idle share of the installed rack.

Frequently asked questions