Cluster I · Article xxxiv of forty

Oracle Multicloud.

Database@Azure, Database@Google Cloud, Database@AWS. The publisher's database delivered inside the hyperscaler data centre through OCI Interconnect. The Admodum read on the commercial mechanics, the egress position and the buyer-side discipline.

ClusterOracle
Read10 minutes
AuthorGregory R. Hale
PublishedJune 2025
UpdatedMarch 2026

Key takeaways

Section i

What Multicloud is.

Oracle Multicloud is the publisher's strategic answer to running OCI-grade database services inside the hyperscaler footprint. The publisher physically deploys OCI infrastructure (Exadata Database Service hardware, network fabric, control plane) inside Microsoft Azure, Google Cloud and AWS data centres; the buyer's hyperscaler workloads access the database service through a low-latency interconnect.

The principal services are Oracle Database@Azure (launched 2023), Oracle Database@Google Cloud (2024) and Oracle Database@AWS (announced 2024, generally available 2025). Each is the same OCI database service portfolio (Autonomous Database, Exadata Database Service, Base Database Service) delivered inside the hyperscaler's regional footprint rather than inside an OCI region.

The wider editorial sits in the Oracle pillar; the OCI construct context sits at the OCI construct; the Cloud Authorisation document context sits at the Oracle Cloud Authorisation.

Section ii

The commercial mechanics.

The commercial construct is dual-booked. The buyer's hyperscaler marketplace records the consumption and the spend; the same spend draws down on the hyperscaler commitment (Azure MACC, GCP EDP, AWS EDP). The publisher books the same revenue against its own ledger.

The arrangement is contractually mediated by a multi-party agreement: the buyer signs a Universal Cloud Authorization with the publisher (governing the Oracle service terms) and a service order with the hyperscaler (governing the marketplace consumption). The two contracts overlap; the buyer-side discipline reads them as a pair.

The single most useful feature for the buyer is the hyperscaler-commitment drawdown. A buyer with an Azure MACC carrying material unspent commitment, an Oracle Database workload running on Azure, and a latency or compliance requirement that prevents the workload moving to an OCI region historically had no path to bring the database consumption inside the MACC. Database@Azure provides that path.

The hyperscaler commitment absorbs the database consumption. The publisher books the revenue. The buyer holds one fewer cloud vendor's commitment to reconcile.
Section iii

The licensing position.

The licensing position on Multicloud remains the OCI licensing position. The buyer can consume the service in licence-included mode (the rate carries the database licence and the support) or in BYOL mode (the buyer's perpetual licences and active support cover the database licence; the rate carries only the infrastructure).

The BYOL conversion arithmetic is identical to the OCI conversion: one Database EE Processor licence covers four OCPUs on Database Cloud Service / Exadata Cloud Service, or eight ECPUs on Autonomous Database; one SE2 Processor licence covers two OCPUs. The conversion is governed by the version of the Cloud Authorisation document in force at order date.

The wider BYOL bridge read sits at the OCI BYOL bridge; the OCI ramp design read sits at OCI ramp design; the Exadata read sits at Exadata licensing.

Section iv

The egress position.

Historically the strongest commercial barrier to running Oracle Database on a hyperscaler was egress: the cost of moving data between the hyperscaler footprint (where the application ran) and OCI (where the database ran), at hyperscaler egress rates, accumulated quickly.

Multicloud collapses the egress: the database sits inside the hyperscaler region; the application sits inside the hyperscaler region; the data crosses an in-region interconnect rather than the open internet. The Database@Azure and Database@Google Cloud constructs are zero-egress between the hyperscaler workload and the OCI database service. The Database@AWS construct carries similar zero-egress mechanics where deployed in-region.

The buyer-side architectural read changes accordingly: low-latency reads, in-region failover, full RAC and Data Guard semantics, and the Exadata hardware grade all become available without the egress penalty. The wider AWS, Azure and GCP context sit in the AWS practice, the Microsoft practice and the Google Cloud practice.

Section v

The negotiation read.

Multicloud creates a three-cornered negotiation. The publisher proposes a database commercial; the hyperscaler proposes a commitment-drawdown commercial; the buyer holds the architectural choice. The buyer's BATNA reads against all three corners.

Levers worth modelling: the multicloud-versus-OCI-region price differential (the publisher's published rate is the same; the hyperscaler-margin layer varies by service and by region); the BYOL-versus-licence-included read (BYOL transfers the perpetual-licence economics into the cloud; licence-included accepts the publisher's monetisation of the same licence); the multi-year commitment construct (the hyperscaler commitment can absorb the database spend, lengthening the commitment tenor); the alternative-platform read (PostgreSQL or hyperscaler-native services may be the credible alternative for a portion of the portfolio).

The wider BATNA read sits at the Oracle BATNA; the renewal-cycle context sits at the Oracle renewal cycle; the quarter-end context sits at the Oracle quarter-end.

Section vi

What the buyer holds.

The buyer-side artefacts to hold against Multicloud are: the application-to-database placement map (which workloads sit in which hyperscaler region, against which Multicloud footprint), the hyperscaler-commitment read (MACC, EDP, EDP balance versus drawdown trajectory), the licence-included-versus-BYOL conversion model (against the cumulative perpetual-licence inventory), the egress-eliminated read (the historical hyperscaler egress line removed against the new in-region path) and the contract-pair (the Universal Cloud Authorization with the publisher against the hyperscaler service order).

The renewal-time conversation is then a three-way negotiation against artefacts, not a binary publisher-versus-hyperscaler conversation. Specific workload-level placements are decided on their own arithmetic against the artefacts.

The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; active renewal moments route to the Renewal Programme; active audit moments route to Audit Defence.

More from the Oracle cluster

Continue the reading.

Article xxiv

The OCI construct

The OCI cloud against which Multicloud is delivered inside hyperscaler footprints.

Article xxviii

The Oracle Cloud Authorisation

The publisher policy document that governs the Multicloud conversion.

Article xxxviii

The Oracle BATNA

The credible alternative read across the three-way Multicloud negotiation.

Engage

Read your Multicloud move with a senior advisor.

A senior Admodum Oracle advisor will read your placement map and the three-cornered commercial on a private call. Active renewal moments route to the Renewal Programme.

Independence
Admodum is not a partner, reseller, or affiliate of Oracle, Microsoft, Google, AWS, or of any other software vendor. No reseller margin, no referral commission, no audit-subcontract relationship.