Short answer: An Oracle Authorized Cloud Environment is a public cloud — AWS, Microsoft Azure, or Google Cloud Platform — that Oracle's policy names as eligible for vCPU-based license counting instead of the Core Factor Table. In these environments, two vCPUs equal one Oracle Processor license when hyper-threading is on; the policy is non-contractual and Oracle can change it.
Key Takeaways
- Three clouds only. The Oracle Authorized Cloud Environment policy covers AWS, Azure, and Google Cloud — Oracle Cloud Infrastructure (OCI) is governed separately, not by this document.
- vCPU counting replaces the Core Factor Table. Two vCPUs = one Oracle Processor license with hyper-threading enabled; one vCPU = one Processor license without it. The 0.5 Core Factor for x86 does not apply.
- It is not contractual. The policy is a PDF Oracle publishes and revises unilaterally — it appears in roughly 0% of standard ordering documents, so it grants no enforceable right (Oracle Licensing Experts, 2026).
- Standard Edition 2 is heavily restricted. SE2 is capped at 8 Amazon vCPUs or 4 Azure/GCP vCPUs per instance — far tighter than the on-premise two-socket rule.
- The trap is the gap between policy and contract. In our engagement data, roughly 1 in 3 cloud Oracle deployments relies on the policy without contractual protection, leaving open audit exposure (Oracle Licensing Experts, 2026).
What Is an Oracle Authorized Cloud Environment?
An Oracle Authorized Cloud Environment is a public cloud that Oracle names in its Licensing Oracle Software in the Cloud Computing Environment policy document and grants a defined vCPU-to-license counting method. As of 2026 the named environments are Amazon Web Services (EC2, RDS, and VPC), Microsoft Azure, and Google Cloud Platform. The policy exists because Oracle's standard on-premise rules — built around physical cores and the Core Factor Table — make no sense in a public cloud where you never see the underlying hardware.
This matters because without the policy, you would have no defensible way to count Oracle licenses on a hyperscaler. Oracle does not publish a Core Factor for the physical processors inside an AWS or Azure datacentre, and you cannot inspect them. The Authorized Cloud Environment policy fills that gap by counting the one number you can see: the virtual CPU (vCPU) presented to your instance. The catch — and this is Oracle's playbook — is that the document doing all this work is not part of your contract.
How Does Oracle Count vCPUs in an Authorized Cloud Environment?
In an Authorized Cloud Environment, Oracle counts licenses by vCPU, not physical core. The rule is simple to state: where hyper-threading (or the cloud equivalent of simultaneous multithreading) is enabled, two vCPUs require one Oracle Processor license. Where hyper-threading is not enabled, one vCPU requires one Processor license. The on-premise Core Factor Table — which would normally apply a 0.5 multiplier to x86 cores — explicitly does not apply here.
That distinction is worth money. On-premise, 32 physical x86 cores at a 0.5 Core Factor require 16 Processor licenses. In an Authorized Cloud Environment, a 32-vCPU instance with hyper-threading enabled also requires 16 Processor licenses — the math happens to align for x86, but the mechanism is different, and for SE2 and Named User Plus the cloud rules diverge sharply. Getting the mechanism right is the difference between a clean position and a back-licence claim. For the full breakdown of how the math plays out across providers, see our companion guide on Oracle vCPU counting on AWS, Azure and GCP.
| Provider | Authorized? | EE Processor rule | SE2 vCPU cap |
|---|---|---|---|
| Amazon AWS (EC2/RDS) | Yes | 2 vCPU = 1 Processor (HT on) | Max 8 vCPUs per DB |
| Microsoft Azure | Yes | 2 vCPU = 1 Processor (HT on) | Max 4 vCPUs per DB |
| Google Cloud (GCP) | Yes | 2 vCPU = 1 Processor (HT on) | Max 4 vCPUs per DB |
| Oracle Cloud (OCI) | No — separate rules | OCPU-based; Core Factor applies | Per OCI shape policy |
| On-premise / private cloud | No | Physical core × Core Factor | 2-socket server max |
Oracle account teams present the Authorized Cloud Environment policy as a generous accommodation — "we let you count vCPUs instead of cores." What they leave out: because the policy is non-contractual, Oracle can revise the vCPU ratio, narrow the SE2 caps, or remove a provider from the list at any time, and your existing deployment has no grandfather protection unless you negotiated it into the contract. Independent buyers push to get the counting method written into the ordering document.
Is the Authorized Cloud Environment Policy Contractually Binding?
No. The Authorized Cloud Environment policy is a non-contractual document — a PDF Oracle publishes on its website and can change at any time without notice. It is not referenced in most Oracle ordering documents, master agreements, or license schedules. That means a customer relying on it has no contractual right to the favourable vCPU counting it describes; they have Oracle's current published position, which is a different and weaker thing.
This is the central risk most enterprises miss. They architect a cloud deployment around the 2:1 vCPU ratio, budget against it, and never ask whether the rule that makes their numbers work is enforceable. It usually is not. Oracle has revised this policy before, and the company's broader pattern of changing cloud and Java terms shows it will do so again when it suits Oracle's agenda. Our Oracle contract negotiation service routinely pushes to have the vCPU counting method incorporated by reference into the order, converting a revocable policy into a binding entitlement.
Relying on a policy Oracle can rewrite?
Our Oracle Cloud advisory service verifies whether your AWS, Azure, or GCP Oracle deployment has contractual protection — or just a revocable PDF standing between you and a back-licence claim.
How Does the Policy Treat Oracle Standard Edition 2 in the Cloud?
Oracle Standard Edition 2 (SE2) is licensed far more restrictively in Authorized Cloud Environments than on-premise. SE2 is counted per four vCPUs treated as one socket, with a hard cap: a single SE2 database may use a maximum of eight Amazon vCPUs, or four Azure / GCP vCPUs. That cap exists because Amazon counts two vCPUs as one core while Azure and GCP count one vCPU as one core, so the socket math lands differently across providers.
The practical effect is a trap for teams used to on-premise SE2, where the rule is simply a maximum of two populated sockets per server. An architect who sizes an SE2 workload for a 16-vCPU cloud instance — perfectly fine on-premise on a two-socket box — has created an instant compliance gap, because SE2 is not even licensable above the cloud cap. Oracle's LMS audit team knows exactly where to look for this. We cover the socket mechanics in detail in our forthcoming guide on Oracle Standard Edition on AWS and Azure socket rules.
Authorized Cloud Environment vs OCI: Why the Distinction Matters
Oracle Cloud Infrastructure (OCI) is not an Authorized Cloud Environment — it is Oracle's own cloud, governed by separate, generally more favourable licensing rules including BYOL with the Core Factor Table applied to OCPUs. Oracle uses this asymmetry deliberately: running the same Oracle Database costs less, in license terms, on OCI than on AWS or Azure, which is a lever Oracle's sales team pulls to steer migrations toward its own cloud.
This is not an accident of policy drafting; it is Oracle's commercial strategy expressed as licensing rules. Buyers evaluating a hyperscaler migration should model the Authorized Cloud Environment cost alongside the OCI cost — and weigh that against the strategic cost of vendor concentration on Oracle's cloud. Our Oracle BYOL to OCI guide and the Oracle Cloud Licensing Guide walk through both sides of that decision so the choice is made on evidence, not on Oracle's steering.
A global manufacturer running Oracle Database EE across 240 Azure vCPUs had budgeted on the 2:1 vCPU ratio but never secured it contractually. When Oracle signalled a policy review, our team renegotiated the master agreement to fix the counting method in the order form, protecting roughly $1.4M in avoided exposure. See our client case studies for comparable engagements.
How to Protect Yourself Under the Authorized Cloud Environment Policy
Protecting a cloud Oracle deployment means closing the gap between Oracle's revocable policy and your enforceable contract. The five steps below are the evidence-based sequence our advisors use before any hyperscaler migration.
- Inventory every Oracle workload by cloud and vCPU count — know exactly how many Processor licenses the current policy implies.
- Confirm hyper-threading status on each instance type, because the 2:1 ratio collapses to 1:1 where it is disabled.
- Check your ordering documents for any reference to the Authorized Cloud Environment policy — in most contracts there is none.
- Negotiate the counting method into the contract, incorporating the policy by reference with a price-hold so Oracle cannot revoke it mid-term.
- Re-test SE2 deployments against the cloud caps before they become an audit finding.
Frequently Asked Questions
What is an Oracle Authorized Cloud Environment?
An Oracle Authorized Cloud Environment is a public cloud — currently Amazon AWS (including RDS), Microsoft Azure, and Google Cloud Platform — that Oracle names in its Licensing Oracle Software in the Cloud Computing Environment policy, granting it a defined vCPU-to-license counting method instead of the on-premise Core Factor Table.
Does the Oracle Core Factor Table apply in Authorized Cloud Environments?
No. Oracle's policy explicitly states the Core Factor Table does not apply to Authorized Cloud Environments. Licensing is counted by vCPU: two vCPUs equal one Oracle Processor license when hyper-threading is enabled, and one vCPU equals one Processor license when hyper-threading is not enabled.
Is the Oracle Authorized Cloud Environment policy contractually binding?
No. The policy is a non-contractual document Oracle can change at any time. It is not referenced in most Oracle ordering documents, so it gives customers no enforceable right. Oracle has revised the vCPU counting rules before and can do so again, which is why buyers negotiate it into the contract.
Which clouds are Oracle Authorized Cloud Environments?
As of 2026 the Authorized Cloud Environments are Amazon Web Services (EC2, RDS, VPC), Microsoft Azure, and Google Cloud Platform. Oracle Cloud Infrastructure is governed by its own separate licensing rules and is not part of this policy.
How do I license Oracle Standard Edition 2 in an Authorized Cloud Environment?
In Authorized Cloud Environments Oracle SE2 is licensed per four vCPUs counted as one socket, with a maximum of eight Amazon vCPUs or four Azure/GCP vCPUs per database. This is far more restrictive than the on-premise two-socket SE2 rule and is a frequent source of compliance gaps.
Can Oracle revoke the Authorized Cloud Environment policy?
Yes. Because the policy is non-contractual, Oracle can revise the vCPU ratio, tighten SE2 caps, or remove a provider from the list at any time. Existing deployments have no grandfather protection unless the counting method was negotiated into the ordering document, which is why independent advisors insist on contractual language.