The Oracle Cloud Authorisation document defines the conversion between on-prem Oracle licences and authorised public-cloud deployments. It is publisher policy, republished from time to time, not a contractual instrument. The Admodum read on what it covers and what to do at contract time.
The Oracle Cloud Authorisation document (formally the Oracle Cloud Policy on authorised cloud environments, sometimes also called the Cloud Licensing Policy) is a published Oracle policy document that defines two things: the cloud environments that Oracle authorises for the deployment of on-prem licences (BYOL); and the conversion arithmetic between the on-prem licensing metric and the cloud-deployment shape.
The document is publisher policy. It is republished by Oracle from time to time. The version in force at the time of the relevant order is the version that applies; later versions do not retroactively change earlier orders, but later orders read against the then-current version.
The wider editorial sits in the Oracle pillar; the parallel publisher-policy document for on-prem virtualisation sits at the Partitioning Policy.
The published authorised cloud environments are Amazon Web Services, Microsoft Azure, Google Cloud Platform and Oracle Cloud Infrastructure itself. The document defines specific deployment shapes inside each environment that qualify for the BYOL conversion (typically the standard general-purpose compute shapes with hyperthreading enabled).
Deployment on a cloud environment not named in the document is not authorised for BYOL. The buyer-side discipline is to read the deployment shape against the named environments before counting on the BYOL conversion. Custom hardware, regional clouds and sovereign clouds outside the named environments do not qualify by default; specific authorisation must be confirmed in writing.
The document additionally distinguishes between BYOL deployments (on-prem licences applied against cloud consumption) and licence-included deployments (Oracle-managed services where the licence is bundled into the consumption rate, as with Autonomous Database on OCI). The distinction matters for support, for renewal posture and for the cumulative entitlement read.
The published conversion on hyperscaler-shape instances (AWS, Azure, GCP) is typically two vCPUs equal one Database EE Processor licence with hyperthreading enabled. The arithmetic treats one hyperscaler vCPU as one virtual thread; two vCPUs equal one physical core; one physical core under hyperthreading carries the same licence weight as on the on-prem core (against the core-factor table).
For Standard Edition 2 (SE2), the published conversion is typically four vCPUs equal one SE2 Processor licence on hyperscaler-shape instances, with the SE2 socket-class limit applying to the underlying shape family.
The Named User Plus conversion follows the same arithmetic: the NUP minima apply against the converted Processor count, not against the raw vCPU count. The deeper read on the conversion arithmetic in the context of OCI sits at the OCI BYOL bridge.
The conversion on OCI itself is more attractive than on the third-party hyperscalers, reflecting Oracle’s commercial preference for OCI consumption. The headline OCI conversion is one Database EE Processor licence against four OCPUs on Database Cloud Service or Exadata Cloud Service, or eight ECPUs against Autonomous Database under the ECPU pricing.
Earlier versions of the Cloud Authorisation document carried a one-Processor-against-two-OCPUs conversion on OCI; later versions widened to four OCPUs. Buyers operating against earlier orders should hold the version in force at the time of order, not the latest version (the contract reads against the contemporaneous version).
The deeper read on the OCI commitment envelope that the converted consumption sits inside is at the OCI commitment construct; the ramp design read is at OCI ramp design.
The version in force at the time of the order matters because the conversion changes between versions. A buyer who placed an order in 2018 against the then-current Cloud Authorisation document carries that conversion forward against the deployments authorised by that order; a buyer placing a new order today reads against the current version.
The buyer-side discipline at contract time is to reference the Cloud Authorisation document by version in the order document, to retain a dated copy of that version on file, and to record the version date alongside the other Schedule A entries in the cumulative contract map. The deeper read on the Schedule A map sits at Schedule A, anatomised.
At renewal, the new order will read against the then-current version of the Cloud Authorisation document. The buyer-side discipline is to read the change between versions and to surface any material change before signing.
The buyer-side discipline holds a current version of the Cloud Authorisation document on file, alongside the dated version that applied at each prior order. The on-prem entitlement map (which products, which metric, which quantity) reads against the version that authorised the cloud deployment for each order line.
The cumulative read is the map of authorised cloud deployments per order line, against the deployed shapes in AWS / Azure / GCP / OCI. The audit-quality discipline is to surface any deployed shape not authorised by the relevant order’s Cloud Authorisation version, and to remediate (either by deploying on an authorised shape, or by acquiring additional entitlement against the current version).
The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; active audit moments route to Audit Defence; active renewal moments route to renewal programme.
The parallel publisher-policy document for on-prem virtualisation.
The cumulative contract map that records each order’s Cloud Authorisation version.
A senior Admodum Oracle advisor will read each order against the contemporaneous Cloud Authorisation version on a private call. Active audit moments route to Audit Defence; active renewal moments route to the Renewal Programme.