Oracle Authorized Cloud Environments

What are Authorized Cloud Environments?

Authorized Cloud Environments are the third party public clouds that Oracle names in a policy document as approved venues for running Oracle programs under a specific, more favourable counting rule than Oracle's general partitioning policy would otherwise impose. In plain terms, Oracle accepts that you can run its software on certain non Oracle clouds and count the cores in a defined way, rather than insisting you license the entire underlying physical estate. The designation exists because Oracle could not credibly claim, as it does with on premise virtualisation, that a customer must license every core in Amazon's or Microsoft's data centre.

The Authorized Cloud Environment policy is the single most important document for any customer running Oracle outside OCI, because it defines both what is permitted and how it is counted. It sits alongside the broader cloud rules described in the Oracle OCI licensing pillar, and it is distinct from the partitioning policy that governs on premise VMware. Understanding which document applies to which deployment is the first step in any multi cloud Oracle position.

Which clouds are authorized?

The policy has historically designated Amazon Web Services and Microsoft Azure as Authorized Cloud Environments, covering their core compute services. Google Cloud was notably absent from the designation for years, which materially changed how Oracle software had to be licensed there and is the subject of the Oracle on Google Cloud article. The list is defined by Oracle and can change, which is itself a governance consideration.

The deployment detail differs by platform. The mechanics on Amazon, including EC2 and RDS, are in the Oracle Database on AWS article, and the Azure equivalents in the Oracle Database on Azure article. Because the list and the rules are Oracle's to revise, the current policy version should always be confirmed before an architecture is committed.

The two vCPU counting rule

The defining feature of the authorized cloud policy is the counting rule: where hyper threading is enabled, every two vCPUs count as one Oracle processor licence, and where it is not, each vCPU counts as one. This is the cloud analogue of the on premise core, and it is the number that turns an instance size into a licence requirement. A 16 vCPU instance with hyper threading on therefore requires 8 processor licences of Enterprise Edition.

The arithmetic is worked in full in the OCPU versus vCPU article, but the key point is its simplicity and its rigidity: you license the instance you provision, counted at two vCPUs per processor, with no adjustment for utilisation. Standard Edition 2 is counted differently, by a vCPU threshold rather than a one to one mapping, which changes the calculus for smaller deployments.

Is the policy a contract term?

This is the question that decides how much weight to put on the policy, and the answer is that it is not a contract term. The Authorized Cloud Environment policy is a document published by Oracle on its website, not a clause in the OLSA, OMA, or ordering document that the customer signed. Oracle applies it as if it were binding, and in practice it is the basis on which most customers license their AWS and Azure estates, but it carries the legal status of a policy Oracle can revise at its discretion.

The implication is twofold. The policy is favourable to customers today, more favourable than the general partitioning policy, so relying on it is rational. But because it is not contractual, a customer building a large estate around it has no contractual protection if Oracle changes the counting rule, narrows the authorized list, or withdraws the policy. The full analysis of the policy's status sits in the Oracle cloud licensing policy article, and it is the reason the Oracle OCI licensing pillar treats policy reliance as a governance risk.

Why the core factor does not apply

On premise, the processor core factor table reduces the licence count for many processors, so a 16 core server with a 0.5 core factor needs only 8 processor licences. On an authorized cloud, that table does not apply. The two vCPU rule replaces it, and there is no further multiplier. For a processor that carried a favourable on premise core factor, this is worse in the cloud; for one that carried a 1.0 factor, the cloud counting can be neutral or better because hyper threading halves the vCPU count.

The practical consequence is that you cannot assume a cloud deployment costs the same in licences as the equivalent on premise server. The comparison must be run explicitly, processor by processor, against both the on premise core factor and the cloud two vCPU rule. The core factor in the cloud article works the cases where the change helps and where it hurts.

The risk of relying on the policy

The central risk is that a non contractual policy can change. Oracle has revised cloud and partitioning policies before, and a customer with a large AWS or Azure Oracle estate has built a material cost position on a document outside its contract. If Oracle were to alter the two vCPU rule, narrow the authorized list, or assert that a particular service falls outside the policy, the customer's licence requirement could rise with no contractual recourse.

The mitigation is partly architectural and partly documentary. Keep the deployment matched precisely to the current policy, document the counting basis and the policy version relied upon at the time of deployment, and avoid scaling beyond carried entitlement in a way that depends on the most generous reading of the policy. If a claim arises from a policy dispute, the audit defence practice handles the contractual argument, which often turns on whether the policy was ever incorporated into the agreement at all.

Architecting around the policy

A buyer side cloud strategy treats the authorized cloud policy as a useful but borrowed tool. Where possible, the strongest position is to negotiate the relevant counting rules into the contract itself, so that the favourable treatment is contractual rather than policy based. Failing that, the estate should be architected so that the licence requirement is defensible under the current policy and not dependent on Oracle declining to revise it. Multi cloud portability also helps: a workload that can run on OCI, AWS, and Azure preserves the negotiating leverage that comes from not being captive to any single venue, as discussed in the Oracle OCI licensing pillar.

The buyer side view

Authorized Cloud Environments let customers run Oracle on AWS and Azure under a favourable two vCPU counting rule, but that rule lives in a policy Oracle can change, not in the contract. The discipline is to use the policy where it helps, document the version relied upon, match the deployment precisely to it, and, where the estate is large, push to make the favourable treatment contractual. Confirm the current policy before committing an architecture, count the instance at two vCPUs per processor with no core factor, and keep multi cloud optionality as leverage. To assess a multi cloud Oracle position, request a consultation.

Managed services and the policy boundary

The authorized cloud policy was written around customer managed instances, where the customer provisions a virtual machine and installs Oracle on it. Managed database services such as Amazon RDS for Oracle sit in a more nuanced position, because the provider, not the customer, controls the underlying host. Oracle has historically accepted licence included options on RDS and a BYOL path, but the counting still flows from the vCPU size of the instance class, and the customer remains responsible for holding entitlement for any BYOL deployment. The boundary between what the managed service bundles and what the customer must license is a frequent source of error, because the convenience of a managed service masks the underlying licence obligation.

The practical rule is to treat any BYOL managed service exactly as you would a self managed instance for counting purposes: identify the vCPU count of the instance class, apply the two vCPU rule, and confirm you hold the matching processor licences plus any options enabled. Where the service is licence included, the entitlement is bundled and the exposure is lower, mirroring the OCI distinction set out in the Oracle OCI licensing pillar. The detail per provider is in the AWS and Azure articles.

Standard Edition on authorized clouds

Standard Edition 2 follows a different counting rule on authorized clouds than Enterprise Edition, and the difference favours smaller deployments. Rather than the two vCPU per processor mapping, Standard Edition 2 is counted against a vCPU threshold, with an instance up to a defined vCPU count treated as a single socket equivalent. For a small database that fits within the threshold, this can make Standard Edition 2 dramatically cheaper on an authorized cloud than the Enterprise Edition processor count would suggest, provided the workload does not need Enterprise features.

The trap is that exceeding the vCPU threshold, or enabling a feature that requires Enterprise Edition, silently converts a cheap Standard Edition deployment into a far more expensive one. As with everything in the authorized cloud policy, the counting is keyed to the instance you provision, so the discipline is to size the instance to the edition and confirm the feature set stays within Standard Edition limits. Where a workload genuinely needs Enterprise features, the comparison should be run against License Included on OCI, which bundles those features into the rate.