Oracle Licensing on
Google Cloud Platform

Oracle on GCP — What Changed in June 2024 and Why It Matters

For years, running Oracle software on Google Cloud Platform sat in a compliance grey zone. Oracle's Authorised Cloud Environment policy explicitly named AWS and Azure as approved BYOL destinations, but Google Cloud was conspicuously absent. Enterprises running Oracle workloads on GCP did so under a policy ambiguity that Oracle's LMS team could, and occasionally did, exploit during audits. That changed in June 2024, when Oracle updated its cloud licensing policy to formally add GCP as an Authorised Cloud Environment (ACE), placing it on equivalent footing with AWS and Azure for Bring Your Own Licence purposes.

This is welcome clarity, but it does not mean the compliance challenge has disappeared. GCP's authorisation comes with the same vCPU-based licensing rules that apply to all public clouds — rules that are more expensive than on-premises Core Factor Table calculations for many processor architectures. Enterprises migrating Oracle workloads to GCP without understanding those rules consistently over-licence or under-licence, both of which create financial exposure. For organisations managing Oracle Database, WebLogic, or middleware on GCP, the Oracle cloud migration readiness assessment is the right starting point before moving any production workload.

The vCPU Counting Rules — Where Most Enterprises Go Wrong

Oracle's licensing rule for public cloud environments, including GCP, is deceptively simple: every two vCPUs with hyper-threading enabled equals one Oracle Processor licence. If hyper-threading is disabled, one vCPU equals one processor licence. Critically, Oracle's on-premises Core Factor Table — which applies multipliers that reduce licence requirements for many processor families — does not apply in any public cloud environment. Every vCPU is treated uniformly, regardless of the underlying processor type Google Cloud uses.

The practical consequence of removing the Core Factor Table can be significant. An enterprise running Oracle Database on a 32-core Intel server on-premises, using the Intel Core Factor of 0.5, requires 16 processor licences. That same workload migrated to a GCP VM with 32 vCPUs (with hyper-threading enabled) requires 16 processor licences — mathematically equivalent in this case. But if that on-premises server used processor types with a Core Factor below 0.5, or if the workload is moved to a GCP instance type with more vCPUs than the on-premises core count, the licence requirement can increase substantially. In our Oracle advisory work, we regularly see migrations that double the effective licence requirement simply because no one calculated the vCPU impact before committing to the GCP instance type.

Hyper-Threading Is the Variable Most SAM Teams Miss

The hyper-threading status of GCP VM instances matters enormously for Oracle licensing. Most GCP machine types have hyper-threading enabled by default, meaning the 2:1 vCPU-to-processor ratio applies. However, some specialised workloads or specific GCP machine configurations may have hyper-threading disabled, triggering the 1:1 ratio and doubling the licence requirement relative to the default. Before deploying Oracle on any GCP instance type, confirm hyper-threading status with your Google Cloud account team. Document the confirmation. This documentation will matter if Oracle's LMS team later questions your licensing position.

The BYOL Model on GCP — What the Policy Authorises (and What It Does Not)

Oracle's Authorised Cloud Environment policy enables Bring Your Own Licence (BYOL) for eligible Oracle products on GCP Compute Engine VMs and Google Kubernetes Engine (GKE) containers. Under BYOL, you deploy Oracle software using licences you already own or purchase separately, rather than consuming Oracle's licence-included cloud offerings. The BYOL model is the dominant approach for large enterprises running Oracle on GCP, because it allows them to leverage existing Oracle investments rather than paying cloud-native Oracle pricing, which is typically higher.

However, the authorisation has important limitations that the policy document itself acknowledges. The Oracle Cloud Licensing Policy is a non-contractual document. It states explicitly on every version that it is "for educational purposes only" and "may not be incorporated into any contract." Your Oracle Master Agreement (OMA) or licence agreements do not reference GCP. If Oracle's LMS team disputes your GCP deployment during an audit, they can argue from the contract — which is silent on cloud environments — rather than the policy document. This asymmetry is one reason why Oracle audit risk assessment for cloud deployments requires careful documentation of your compliance position before an audit request arrives, not after.

The policy also specifies that BYOL applies only to what Oracle terms "Eligible Products" — a list that does not include every Oracle product. Oracle Database Enterprise Edition, Standard Edition 2, WebLogic Server, and the Java SE subscription are all eligible for BYOL on GCP, but certain Oracle cloud-native products and SaaS applications are not available under BYOL terms. Before migrating any Oracle product to GCP under BYOL assumptions, verify the product's eligibility in the current version of the policy. Downloading our Oracle Cloud Licensing guide provides a structured framework for this verification process.

Compliance Risks Specific to Google Cloud Deployments

Beyond the core vCPU counting and BYOL eligibility questions, several GCP-specific scenarios create compliance risk that enterprises frequently underestimate. The first is GKE (Google Kubernetes Engine). Oracle's licensing policy addresses Kubernetes deployments with specific rules: if Oracle software is deployed in a Kubernetes cluster, all nodes in the cluster on which Oracle can run must be counted for licensing purposes, unless hard partitioning is applied at the cluster level. In practice, most Kubernetes deployments do not enforce hard partitioning — the scheduling flexibility that makes Kubernetes valuable is precisely what creates Oracle's licensing exposure.

The second risk area is Committed Use Discounts (CUDs) and GCP preemptible or Spot VMs. If Oracle workloads are temporarily migrated to differently-sized instances due to cost optimisation, the licensing obligation follows the instance's vCPU count at any point where Oracle software runs — not the original provisioned capacity. A workload that temporarily scales out to handle peak load creates a licensing obligation for that peak vCPU count, even if the scale-out lasts only hours. Implementing governance controls that require licence management approval before Oracle VMs are resized or migrated is essential for sustainable compliance in GCP environments.

The third risk is database options and features. This risk is not cloud-specific, but it compounds in cloud environments because GCP's easy provisioning encourages rapid environment creation. Oracle Database Enterprise Edition includes dozens of features that require separate licences — the Diagnostics Pack, Tuning Pack, Database Vault, and Advanced Security are the most commonly triggered. These features can be inadvertently enabled when DBAs provision new environments from templates that have them active. Our Oracle database licensing calculator includes checks for commonly-enabled unlicensed options that clients should run against any new GCP database environment.

Cost Optimisation Strategies for Oracle on GCP

Oracle licensing costs on GCP can be managed actively — the key is selecting the right GCP instance types and architectures to minimise the Oracle processor licence requirement. Right-sizing GCP VMs to the minimum vCPU count needed for Oracle workloads is the first lever. Oracle licences are expensive: Oracle Database Enterprise Edition carries a list price of approximately $47,500 per processor licence, plus 22% annual support (which increases at 8% per year). Reducing the GCP instance from 16 vCPUs to 8 vCPUs saves 4 processor licences — a saving of $190,000 in licence value at list price, plus approximately $41,800 per year in support costs. The performance trade-off is often more manageable than the licence cost trade-off.

The second lever is hard partitioning. On GCP, hard partitioning can be achieved through dedicated hosts or through strict affinity rules that prevent Oracle VMs from migrating to hosts not covered by your licence allocation. Implementing this correctly requires both GCP configuration expertise and Oracle licensing expertise — a combination that Redress Compliance provides through our Oracle cloud advisory service. We have helped clients reduce their Oracle GCP footprint by an average of 30% through right-sizing and partitioning optimisation, without any degradation in application performance.

Third, for organisations running Oracle Standard Edition 2 (SE2) on GCP, the licencing rules differ from Enterprise Edition. SE2 licences are sold per socket (not per processor core), with a maximum of 16 threads per server. In cloud environments, SE2 is limited to VMs with a maximum of 2 sockets, which translates to instance types that Oracle caps at certain vCPU counts. This limit exists regardless of what GCP's instance selection would otherwise allow. Understanding the SE2 restrictions before choosing GCP instance types prevents costly post-deployment rearchitecting. To explore the full range of Oracle advisory resources and understand your position across Oracle's licensing model, the Oracle Knowledge Hub provides our complete research library, and you can book a confidential call to discuss your specific GCP estate with our team.

Written by Morten Andersen, Co-Founder, Redress Compliance. 20+ years in enterprise software licensing and cloud compliance advisory.