Oracle Cloud at Customer. The boundary decides the bill.

Oracle Cloud at Customer is a family of Oracle owned, Oracle operated racks that sit inside your data center and are billed as a cloud service. The interesting part is not the hardware. It is the service boundary, what still has to leave your building, and who is on the hook at 3am.

Most Cloud at Customer decisions are made on a slide that says "cloud economics, your data center." That slide is accurate and almost useless. It describes the commercial wrapper and skips the two things that determine whether the deal works.

The first is the service boundary: exactly which layers Oracle now owns and which layers you still have to staff. The second is what has to cross your firewall for an Oracle managed rack to be an Oracle managed rack at all.

This guide covers the family, the boundary, the meter and day two. For the head to head between Cloud at Customer and a full Dedicated Region, see our platform comparison. For the money on the largest variant, see Dedicated Region pricing and licensing.

What is actually in the Cloud at Customer family?

Cloud at Customer is four products under one brand, and they differ more than the marketing suggests. Oracle's own distributed cloud page groups them because they share a delivery model: Oracle owns the hardware, installs it in your facility, and operates it remotely.

They do not share a service catalog, a control plane design, a minimum commitment, or an operating model. Buyers who evaluate "Cloud at Customer" as a single decision usually end up sized for the wrong one.

The four things Oracle sells under this banner

The practical dividing line is service catalog breadth. Exadata Cloud at Customer gives you database services and nothing else, so your application tier still needs a home.

Compute Cloud at Customer fills that gap with general purpose compute and block storage. A Dedicated Region gives you the wide OCI catalog and a proportionally wider commitment.

The siblings that get confused with it

Three adjacent Oracle offers are not Cloud at Customer, and mixing them into the evaluation wastes weeks. Each solves a different problem.

• Oracle Database at Azure, at Google Cloud and at AWS. The same Oracle owned Exadata hardware, but installed in a hyperscaler data center rather than yours. Same operating shape, entirely different procurement and network story.
• Oracle Alloy. A partner operates an OCI based cloud for its own customers. It is a licensing and partnership model, not something a typical enterprise buys for itself.
• Roving Edge. Ruggedized portable devices for disconnected and field use. Useful, unrelated to a rack in a data hall.

Why buyers actually land here

The honest 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 rather than a scandal, and test the residency claim before you test the spreadsheet.

Where does Oracle's responsibility stop and yours start?

Oracle owns everything from the rack rails up to the hypervisor, and you own everything from the guest operating system up. That single sentence explains most of the operational surprises in year one.

On current generation Exadata Cloud at Customer you receive root access on the guest virtual machines in your VM cluster. You receive no access at all to the physical database servers' hypervisor, the storage servers, or the fabric switches.

What Oracle holds and you cannot touch

• The hypervisor layer on the physical database servers. No agents, no shell, no exceptions.
• The storage servers. Exadata storage software, cell configuration and the flash tier are Oracle managed and not customer addressable.
• The internal fabric. Switches and the low latency interconnect are part of the appliance, not your network.
• Firmware and infrastructure patching across all of the above, on Oracle's cadence.

The consequence lands on your security team, not your database team. Endpoint agents, configuration management, vulnerability scanners and log shippers can only reach the guest virtual machines.

If your security standard says "every host runs the agent," that standard now has a documented exception covering roughly two thirds of the physical stack. Get that exception approved before the rack ships, not after your first internal audit finds it.

What you still own after Oracle has taken the hardware

Read the fourth and fifth rows together. Buyers frequently assume that a managed cloud service means managed database patching, and it does not on Exadata Cloud at Customer.

You still plan, test and apply quarterly database patches. The tooling is better than it was on premises. The accountability has not moved an inch.

Autonomous moves the line, at a price

Autonomous Database on Exadata Cloud at Customer is the one variant where Oracle does take database operations. Oracle patches the database, manages the instance and handles most tuning.

The trade is control. Your database administrators lose direct access to configuration they are used to owning, and some third party tooling stops working. Pilot one real workload before you commit the estate.

What still has to leave your building for this to work?

More than most residency business cases assume. The rack is local, but the service that operates it is not, and the difference matters to any regulator who reads the architecture rather than the brochure.

The control plane lives in the linked region

Exadata Cloud at Customer and Compute Cloud at Customer are provisioned and managed through a control plane in a linked OCI region. Your rack maintains an outbound connection to that region for lifecycle operations, telemetry and billing.

When that link drops, running databases keep serving traffic. What stops is everything else: provisioning, scaling, patching orchestration, and console visibility.

Test that failure mode deliberately during acceptance. Ask Oracle in writing which operations survive a control plane outage and for how long, and put the answer in your runbook.

Oracle staff can reach the infrastructure, and you should gate it

Oracle operators need access to the infrastructure they are contracted to run. That is not a scandal, it is the service, but it is a control point most buyers leave switched off.

Oracle Operator Access Control lets you require explicit customer approval before an Oracle operator can act on your infrastructure, with the session recorded. Confirm current coverage for your specific service in the applicable Oracle cloud service description rather than assuming it applies everywhere.

Two questions decide whether it is worth enabling. Who in your organization approves a request at 2am, and what is the documented behavior when nobody answers?

How does the meter work once the rack is installed?

There are two charges, and conflating them is the single most common modelling error we see. A fixed infrastructure subscription pays for the installed rack, and a variable service charge pays for the compute you enable on it.

Both run through Oracle Universal Credits: you commit to a spend over a term and draw it down. Unused commitment expires at the end of the term and does not roll forward.

The unit you are charged in, and why it is changing

Exadata Cloud at Customer database services have historically billed per OCPU per hour, where one OCPU is one physical core with hyperthreading enabled. Autonomous services have been moving to the ECPU, an abstracted unit that decouples billing from the physical core.

Do not assume which unit applies to your service and generation. Check the current service description and price list for the exact service you are buying, because the conversion between units also changes how bring your own license entitlements are consumed.

We work the unit mechanics, the conversion ratios and the OCI specific rules in detail on our OCI licensing page.

Committed capacity bills the footprint, not the usage

The infrastructure subscription is charged on what is installed, every month, whether a workload touches it or not. Scaling database compute to zero reduces the variable charge and leaves the fixed one intact.

That is why sizing to real demand beats sizing to peak by a wider margin here than in public cloud. The rack is installed once. The subscription is paid every month of the term.

Idle capacity is the line item nobody sees

Capacity sized to peak projections left 25 to 45 percent of the committed footprint idle across the engagements reviewed. Minimums signed at full forecast left 25 to 35 percent of capacity idle by year two in roughly half the deals.

Neither figure appears on an invoice as idle. Both are paid in full every month, which is what makes them so easy to miss in a quarterly cost review.

Which license path do you land in on day one?

Two, and you choose per workload rather than once for the estate. You either bring your own license against a lower service rate, or you take license included and let the subscription carry the license.

What bring your own license actually requires of you

It requires a defensible entitlement baseline and active support on every license you count. The Oracle Database Licensing Information document governs what those licenses permit before any cloud conversion applies.

The mechanics of the conversion, and what happens when you get it wrong, sit on our bring your own license guide. Our Oracle Cloud at Customer white paper works the same comparison through a benchmark estate.

What license included is really buying

Containment. The audit exposure row in the table above is the one buyers skip, and it is the row that justifies the higher rate.

On bring your own license a wrong entitlement baseline stays wrong after the migration, and it is now wrong on a platform Oracle meters directly. License included makes that question mostly disappear, and Oracle prices the relief accordingly.

Where Support Rewards change the math

Consumption on the platform earns credits that retire technology support spend. Oracle Support Rewards accrue at a rate that differs by agreement type, so read the program terms rather than the sales slide.

The interaction runs both ways. Bring your own license keeps your existing support stream running, and support spend is exactly what the rewards retire. Move to license included, drop support on licenses you no longer need, and there is less spend left to offset.

Price both paths with rewards applied and both without, then put the four numbers side by side. That is a fifteen minute exercise that has moved seven figure decisions in our engagement file.

What does day two actually look like?

It looks like a shared operations model that most teams have never run before. You keep a database team, you lose infrastructure control, and you gain a scheduling dependency on a vendor.

In roughly two thirds of the engagements behind this page, the customer had not staffed or trained for that split before go live. The first quarterly maintenance window is where they found out.

The maintenance calendar you now live inside

Oracle patches the infrastructure on a quarterly cadence. You get to set a maintenance window and receive notification, and within limits you can defer, but you do not get to say never.

• Set the window before go live, not at the first notification. Align it to your existing change calendar or you will spend every quarter arguing.
• Understand rolling versus non rolling. Rolling maintenance takes nodes one at a time and assumes your application survives node loss. If it does not, you have an availability problem Oracle cannot fix for you.
• Name a deferral owner. Someone has to decide, on a deadline, whether to accept a window. Unowned deferrals become forced windows.
• Keep your own patch calendar separate. Guest operating system, Grid Infrastructure and database patching remain yours and do not happen automatically.

Scaling is online, which is exactly the problem

Compute can be scaled up without downtime, from a console or an API call, by anyone with the right permission. That is a genuine operational benefit and the most reliable way to blow a budget.

Unreviewed online scaling pushed actual spend 20 to 40 percent above the original forecast in roughly half the estates we reviewed. Nobody did anything wrong. Each individual increase was justified and none of them were ever reversed.

1. Restrict scaling permissions to a named group, not the whole database team.
2. Require a ticket with a business justification and an expiry date for every increase.
3. Review enabled compute monthly against consumption and scale back down.
4. Report drift against the original forecast to whoever signed the business case.

Who gets the call at 3am, and what do they open

The answer is your team first, and the routing decision is harder than it sounds. A slow query is yours. A failed storage cell is Oracle's. A slow query caused by a degraded storage cell looks identical to the first one at 3am.

Agree the escalation path and the severity definitions before go live, and rehearse one. Support continuity on the underlying products still follows the Oracle lifetime support policy, which matters if you are running an older database release on new hardware.

Capacity expansion is a procurement event, not a console click

You can scale compute within the installed rack instantly. You cannot conjure a rack you did not order.

Adding physical capacity means a new order, a new site survey where relevant, manufacturing and shipping, and an installation window. Plan for months, not days, and price expansion at signature rates in the original contract so the lead time is your only problem.

The four moves that change the number most

• Set the floor to steady state, not to peak. Buy headroom through negotiated expansion rather than through a permanent minimum.
• Negotiate a step down. The right to shrink the committed footprint across the term is worth more than a point or two on the unit rate.
• Lock expansion pricing at signature rates, in writing, for the full term.
• Govern scaling from day one. A monthly review gate costs nothing and is the highest return control on this platform.

Where does audit exposure sit once the rack is in your building?

It moves rather than disappears. Counting deployments gets easier because Oracle meters the platform, and proving bring your own license eligibility gets harder because the boundary between your servers and the platform is now blurred.

• Double counting. A license still pinned to an on premises server cannot also cover the platform. Map every license to a single home and keep the mapping current.
• Support mismatch. Lapsed support on an owned license breaks bring your own license eligibility, usually without anyone noticing until renewal.
• Edition and option drift. Options consumed on the platform must match owned entitlements pack by pack, and diagnostic features are easy to enable by accident.

One metering rule reverses the position you know from your own floor. Oracle's partitioning policy does not govern cloud metering, so soft partitioning counts on the platform itself.

That runs in your favor right up to the moment one license has to cover both sides of the fence. Auditors test for exactly that.

Which contract terms decide whether this works?

Six, and they have to be negotiated as one package. Traded one at a time, Oracle wins each on its own logic and you lose the total.

• Minimum: commit at 70 to 80 percent of an honest forecast and cover the upside with expansion at locked rates.
• Term: a typical commitment runs around four years. Shorter beats longer unless the rate concession is structural.
• Expansion pricing: future capacity at signature rates, never at future list.
• Step down: a negotiated right to shrink the committed footprint across the term.
• Rate lock: fix service and storage rates across the full term, in writing.
• Support treatment: rewards, parked licenses and any unlimited agreement interaction documented in the order.

Exit, egress and what happens to the rack

Define exit, data egress and decommissioning in writing before the hardware is installed. Oracle's standard template is written for Oracle, and the Oracle Master Agreement frames the arrangement rather than protecting you inside it.

Ask the unglamorous questions early. Who physically removes the rack, on what notice, at whose cost, and what is the certified data destruction process?

A meter you cannot leave is a meter Oracle prices freely. Hold a contractual off ramp and a benchmark clause against public OCI list pricing.

Sequencing the migration, and the two traps

Front load the licensing work, because entitlement decisions taken early are yours and the same decisions taken late are Oracle's.

1. Baseline entitlements, with support status, before any quote.
2. Reconcile deployment reality against that baseline.
3. Classify workloads: residency bound, latency bound, or free to move to public OCI.
4. Model both license paths per workload, with option packs mapped explicitly.
5. Size against measured utilization, not Oracle proposed capacity.
6. Negotiate minimum, term, expansion, step down and exit together.

The traps sit at steps one and four

Skip the entitlement baseline and Oracle scopes the deal against its own audit view of your estate. Whoever brings the inventory controls the negotiation.

Rush the mapping and the configuration gets priced against entitlements you do not cleanly hold. Mapping errors, mostly option packs and processor conversions, inflated Oracle's first proposed sizing by 20 to 40 percent.

How a live unlimited agreement changes the order of operations

Migrating mid term changes the certification math. Deployment counts at certification set the perpetual position you keep afterwards, so what you moved onto the platform and what you switched off on your own floor both land in that count.

Get the order right and the agreement funds the migration. Get it wrong and you certify against a half moved estate, then buy back capacity you already owned.

Where the common advice on Cloud at Customer is wrong

We disagree with the standard framing that Cloud at Customer is a data residency product with a cost case attached. In the engagements behind this page, residency was the reason the project started and the operating model was the reason it succeeded or failed. Teams that treated it as procurement, signed the four year commitment, and kept running the estate the way they always had were the ones that hit trouble, because the platform quietly transferred infrastructure control to Oracle while leaving database accountability with them. The buyers who did well rebuilt the runbook, the change calendar and the scaling controls before the rack arrived. Residency gets you the budget. The operating model decides whether the money was well spent.

30%

Median compute oversize at signing

2 in 3

Estates not staffed for the split model at go live

25 to 45%

Committed footprint left idle when sized to peak

Source: Redress Compliance advisory engagement file, 2024 to 2025. Cloud at Customer, Dedicated Region and Exadata engagements only, on the basis stated at the top of this page.

Cloud at Customer moves the hardware into your building. It does not move the operating model, and it does not move the negotiation onto your side of the table.

What should a buyer do next?

Work the operating model before the commercial model. The commercial terms are easier to fix at renewal than a runbook you never wrote.

1. Pick the right family member first. Database only estate, application tier too, or a full region replacement. Read our comparison before you accept Oracle's framing of the choice.
2. Write the responsibility matrix yourself, layer by layer, and have Oracle sign it. Do not accept a slide.
3. Get the security exception for the layers you cannot instrument approved in advance, in writing, by whoever owns your security standard.
4. Document what leaves the building: telemetry, diagnostics, support artefacts and your chosen backup target. Take that list to legal before you take the price to finance.
5. Baseline every owned database license, option pack and middleware entitlement with its support status, then reconcile against what runs where.
6. Measure steady state demand from current workloads and refuse to start sizing from the Oracle forecast.
7. Model both license paths per workload, with option packs mapped and Support Rewards applied and unapplied.
8. Set the commitment at 70 to 80 percent of honest forecast, then negotiate minimum, term, expansion, step down and exit as one package.
9. Stand up scaling governance and the maintenance window owner before the rack ships, not after the first invoice.

Frequently asked questions

What is Oracle Cloud at Customer?

Oracle Cloud at Customer is a family of Oracle owned racks that Oracle installs and operates inside your own data center and bills as a cloud service. It covers Exadata Cloud at Customer, Autonomous Database on that platform, Compute Cloud at Customer and the full Dedicated Region.

Does Cloud at Customer keep all of my data inside my data center?

Your customer data stays on the rack unless you choose to send it elsewhere, but operational metadata, telemetry, diagnostics and support artefacts travel to Oracle by design. Check your backup target too, because backing up to Object Storage in the linked region moves data off site.

What access do I get to the hardware?

You get root access on the guest virtual machines and nothing below them. The hypervisor, the storage servers and the internal fabric are Oracle operated, which means your security agents and scanners cannot reach them.

Who patches what on Exadata Cloud at Customer?

Oracle patches the infrastructure, including the hypervisor, storage servers and firmware, on a quarterly cadence. You patch the guest operating system, Grid Infrastructure and the database homes, using Oracle's cloud tooling but on your own accountability.

What happens if the rack loses its connection to the OCI region?

Running databases continue to serve traffic, but lifecycle operations stop. Provisioning, scaling, patching orchestration and console visibility depend on the control plane in the linked region, so ask Oracle in writing which operations survive an outage and for how long.

Is Cloud at Customer billed in OCPUs or ECPUs?

It depends on the service and the generation, and Oracle has been migrating cloud database services toward the ECPU. Verify the unit in the current service description and price list for the exact service you are buying, because the unit also affects how bring your own license entitlements are consumed.

Can I scale compute down to reduce the bill?

You can reduce the variable service charge by scaling compute down, but the infrastructure subscription for the installed rack is fixed and continues regardless. That is why sizing the physical footprint correctly matters more here than it does in public cloud.

How long does it take to add capacity?

Scaling within an installed rack is immediate, but adding physical capacity is a procurement and logistics event measured in months. Order expansion at locked signature rates in the original contract so lead time is your only constraint.

Does Cloud at Customer remove my Oracle compliance risk?

No, it relocates it. On bring your own license you still consume your own entitlements and must keep support current, and auditors specifically test whether one license has been counted both on your servers and on the platform.

Do I still need database administrators?

Yes, on every variant except Autonomous Database on Exadata Cloud at Customer. Oracle takes the infrastructure, not the database, so patching, tuning, backup design and capacity planning remain your team's work.

Can I stop Oracle staff from accessing the infrastructure?

Not entirely, because operator access is how the service is delivered, but you can gate and record it. Oracle Operator Access Control allows explicit customer approval of operator sessions, and you should confirm coverage for your specific service in the applicable service description.

Which member of the family should I be evaluating?

Choose on service catalog breadth rather than brand. Exadata Cloud at Customer covers database only, Compute Cloud at Customer adds general purpose compute, and a Dedicated Region is for replacing a data center rather than a database platform.