Cloud at Customer versus OCI, one question and one floor
Cloud at Customer and public OCI run the same Oracle services under the same license postures, so the decision between them is one question: does this workload have to sit behind your firewall, or can it live in Oracle's region? Teams that argue licensing first go in circles, because the licensing is nearly symmetrical, and the asymmetry lives in the commercial structure and the physics.
Prepared by Redress Compliance · August 7, 2026 · Oracle advisory. Based on 10 to 15 cloud footprint decisions supported 2024 to 2025.
Executive summary
The licensing is symmetrical; the commercial structure is not. BYOL and license included exist on both footprints under the same published terms, and Autonomous Database bills in ECPUs, one OCPU equal to four, wherever the service runs.
The asymmetry: Cloud at Customer stacks a fixed infrastructure line across a four year term, while public OCI has no infrastructure floor and commits run one to three years. Comparisons that leave the floor out make Cloud at Customer look closer to OCI pricing than it ever is at low volume.
The floors bill whether or not you consume. On Exadata Cloud at Customer, every database node carries an activation floor of eight ECPUs that bills even when idle, while public OCI scales to zero on many services.
The floor is the price of the firewall, and it belongs in the model as a standing charge against the workload's real utilization curve, not as a footnote discovered at the first quiet quarter.
Half the residency mandates were preferences. In about 1 in 2 decisions we reviewed, the residency requirement cited for Cloud at Customer turned out to be a preference once the regulator's actual text was on the table.
The three legitimate drivers rank cleanly: a written mandate requiring data on your premises, which forces the choice; latency physics the applications cannot tolerate; and everything else, which is preference wearing a compliance costume and paying the infrastructure floor for it.
The credits and the rewards ride on both.
Universal credit commits were sized to deployment ambition on both footprints, with the shape decision used to justify the size decision, the inversion that strands value.
And Oracle Support Rewards accrue on universal credit consumption, offsetting the on premises support bill, confirmed in the order rather than in conversation.
The commit sizing discipline is footprint independent, and so is the failure to apply it.
The deltas that actually differ
| Dimension | Cloud at Customer | Public OCI |
|---|---|---|
| License posture | BYOL and license included, same published terms | Identical: the symmetry that ends the licensing argument |
| Infrastructure commitment | A fixed line stacked across a four year term | No floor: commits run one to three years |
| Idle economics | Eight ECPU activation floor per database node, billing regardless | Scales to zero on many services |
| Where the data sits | Behind your firewall, in your data center | Oracle's region, with residency by region choice |
| Support Rewards | Accrue on universal credit consumption | The same: confirm applicability in the order |
One question decides it. Must the workload run behind your firewall, or can it run in an Oracle region? Everything else, the credits, the BYOL math, the service catalog, follows from that answer rather than deciding it.
The three drivers rank by strength: a written regulatory mandate, latency the applications cannot tolerate, and preference, which is legitimate exactly up to the point where it pays a four year infrastructure floor to feel compliant.
The floor, priced against real utilization
The comparison fails wherever the floor is omitted: at high steady utilization the fixed infrastructure line amortizes and Cloud at Customer approaches OCI economics, while at low or spiky volume the idle floors dominate and the same workload prices multiples apart.
The model that holds prices the four year infrastructure stack plus the eight ECPU per node activation floors against the workload's honest utilization curve, quiet quarters included, and compares that against OCI consumption that scales down.
The service level detail sits in the Exadata Cloud at Customer analysis and the OCI licensing reference, with the dedicated region variant, the third footprint for estates large enough to carry it, in the Cloud at Customer versus Dedicated Region comparison.
The Cloud at Customer strategy brief
The footprint decision end to end: the mandate test, the floor arithmetic, the hybrid pattern, and the order terms that keep both options open.
Get the white paper →The mandate test, run before the architecture
The finding that half the cited mandates were preferences came from one exercise: putting the regulator's actual text on the table.
The test is documentary, which statute or supervisory instruction, which clause, and does it require the data on your premises in your control, or does it require demonstrable residency and access control that an Oracle region in country satisfies? A written mandate forces Cloud at Customer or stops the project.
Everything softer is a cost benefit decision the floor arithmetic should decide.
The hybrid pattern resolves most real estates: the mandated core behind the firewall on Cloud at Customer, everything else in the region, with the DR licensing analysis covering the cross footprint failover terms, and the wider rulebook map, which document governs which deployment.
In the multicloud licensing guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across footprint decisions, 2024 to 2025
Across the 10 to 15 Oracle cloud footprint decisions Fredrik Filipsson supported in 2024 and 2025, the pattern was consistent: the licensing analysis was done well, and the deployment shape decision was done on instinct:
Residency requirements cited for Cloud at Customer that dissolved when the regulator's text was read.
Comparisons omitting the infrastructure line, making Cloud at Customer look closer to OCI than it is at low volume.
The third finding is the commit inversion: universal credit commitments sized to deployment ambition on both footprints, with the shape decision used to justify the size decision, when the sizing discipline runs the other way, measured consumption first, the pessimistic floor committed.
And the ambition left on demand.
Support Rewards close the model: accruing on universal credit consumption against the on premises support bill at the published rates, applicable on both footprints, and confirmed in the order rather than assumed from the conversation, the mechanics in the Support Rewards guide.
Your first five moves
- Put the regulator's text on the table first, because half the mandates were preferences and the floor is expensive compliance theater.
- Model the floors honestly: the four year infrastructure line and the eight ECPU node minimums against the real utilization curve, quiet quarters included.
- Design the hybrid before defaulting either way, the mandated core behind the firewall and everything else in the region.
- Size the credits to consumption, not to the shape decision, because the ambition prices safely on demand and expensively as commitment.
- Write Support Rewards applicability into the order, and keep the DR terms cross footprint. The Oracle practice runs the decision with you.
Frequently asked questions
What is the licensing difference between Cloud at Customer and OCI?
Almost none, which is the point: BYOL and license included exist on both footprints under the same published terms, and Autonomous Database bills in ECPUs at the same one OCPU to four ECPU conversion wherever it runs.
The differences that matter are commercial, the infrastructure floor and term structure, not the license posture.
What does Cloud at Customer cost that OCI does not?
The floors: a fixed infrastructure line stacked across a four year term, and on Exadata Cloud at Customer an activation floor of eight ECPUs per database node that bills even when idle, while public OCI carries no infrastructure floor and scales to zero on many services.
At low or spiky volume the floors dominate the comparison; at high steady utilization they amortize.
When is Cloud at Customer actually required?
When a written mandate, a statute or supervisory instruction, requires the data on your premises in your control, or when latency physics rule out the region.
In about 1 in 2 decisions we reviewed, the residency requirement cited turned out to be a preference once the regulator's actual text was read, and preference pays the four year floor.
Does BYOL work the same on both footprints?
Yes: bring your own license and license included operate under the same published terms on Cloud at Customer and public OCI, and the ECPU metrics match.
The BYOL analysis ports unchanged between footprints, which is why the decision should never be argued on licensing grounds: the asymmetry is commercial and physical, not contractual.
Do Oracle Support Rewards apply on Cloud at Customer?
They accrue on universal credit consumption, which runs on both footprints, offsetting the on premises technology support bill at the published rates.
The discipline is confirmation in the order rather than in conversation, because the reward treatment is a contract term, and the model that includes it can swing a close footprint comparison.
What is the hybrid Cloud at Customer pattern?
The mandated core behind the firewall on Cloud at Customer and everything else in Oracle's region: most real estates resolve this way once the regulator's text separates the genuinely mandated workloads from the preferred ones.
The DR terms then run cross footprint, and the credit commit sizes to the combined measured consumption, not the architecture ambition.
