Oracle Licensing on Google Cloud (GCP): A Compliance and Cost Guide

Google Cloud as an Oracle Authorised Cloud Environment

Oracle officially added Google Cloud Platform to its list of Authorised Cloud Environments (ACEs) in 2024. This was a significant development: prior to this designation, running Oracle Database on GCP with BYOL licences occupied a grey area where Oracle's audit team could argue that the deployment was not explicitly covered by Oracle's cloud licensing policy. ACE status resolved that ambiguity — Google Cloud compute instances are now a valid destination for BYOL Oracle Database and technology deployments under Oracle's official policies.

However, ACE status comes with specific licensing rules that apply differently from OCI. Understanding those differences is essential for compliance and cost management. Critically, Google Cloud does not offer licence-included Oracle Database options the way OCI does. On GCP, Oracle licensing is exclusively BYOL — you must provide your own Oracle perpetual licences for every Oracle Database deployment. There is no consumption-based or subscription path to Oracle Database EE on Google Cloud Compute Engine.

The Core Licensing Rule on GCP: 2 vCPUs = 1 Processor Licence

The fundamental Oracle licensing rule for Google Cloud Compute Engine instances is: 2 vCPUs = 1 Oracle Processor licence, when hyper-threading is enabled. This is the same rule that applies on AWS and Azure, and it represents a less favourable conversion than OCI (where 1 Processor licence covers 2 OCPUs, equivalent to 4 vCPUs).

The practical implication: a GCE instance with 16 vCPUs (a common size for Oracle Database workloads) requires 8 Oracle Processor licences. At approximately $47,500 per Processor licence (list price) for Oracle Database Enterprise Edition, that is $380,000 in licence value deployed on a single VM. Annual support on that licence estate at Oracle's standard rate increases by 8% per year, creating a compounding cost obligation that must be modelled in any GCP Oracle migration business case.

If hyper-threading is disabled, the rule changes to 1 vCPU = 1 Oracle Processor licence. Organisations running Oracle on GCP with hyper-threading disabled should document that configuration explicitly — Oracle auditors will default to the 2 vCPU = 1 licence rule unless evidence of disabled hyper-threading is provided.

Google Cloud Deployment Options for Oracle

Option 1: Oracle Database on Google Compute Engine (GCE) VMs

The most common deployment path is running Oracle Database on standard GCE virtual machine instances with BYOL licences. GCE instances are available in a wide range of machine types across the Intel, AMD, and ARM processor families. For Oracle licensing, the machine type family affects the vCPU count but not the core factor (GCP uses vCPUs rather than physical cores as the licensing unit, making the on-premises core factor table irrelevant).

Key considerations for GCE-based Oracle deployments:

• All Oracle Database Options (RAC, Partitioning, Advanced Compression, Active Data Guard, Diagnostics Pack, etc.) must be separately licenced on GCE instances, exactly as on-premises.
• Google Cloud's Kubernetes Engine (GKE) is treated as soft partitioning — if Oracle runs in a GKE container, Oracle will require all physical cores of all nodes in the cluster to be licenced.
• Oracle does not recognise GCE's instance isolation as hard partitioning — the 2 vCPU = 1 Processor rule applies regardless of how GCE isolates instances at the hypervisor level.
• Migrating Oracle from VMware on-premises to GCE does not resolve the VMware partitioning issue — the GCE BYOL rules replace VMware cluster-wide licensing, but require proper vCPU-to-Processor licence mapping.

Option 2: Google Cloud Bare Metal Solution (BMS) for Oracle

Google Cloud Bare Metal Solution (BMS) provides dedicated physical servers co-located in Google's data centres, connected directly to GCP's network. Unlike GCE virtual machines, BMS instances are physical servers — you have exclusive access to the physical hardware and all its CPU cores. BMS is specifically designed for workloads that require bare metal performance, dedicated hardware, or Oracle features that are not supported on virtualised instances.

From an Oracle licensing perspective, BMS follows on-premises rules: all physical cores on the BMS server must be licenced, applying Oracle's core factor for the processor family installed. BMS servers typically use Intel Xeon processors with a 0.5 core factor, so a 48-core BMS server requires 24 Oracle Processor licences. Notably, BMS supports Oracle RAC (Real Application Clusters) — a feature not available on standard GCE virtual machines — making it an option for organisations requiring active-active Oracle clustering on GCP.

BMS also enables the use of Oracle-approved hard partitioning technologies. If an organisation deploys Oracle Linux KVM with hard cgroups on a BMS server, Oracle may recognise this as valid hard partitioning, allowing licence scope to be limited to the pinned CPU cores. This requires careful configuration and documentation to be defensible in an audit.

GCP vs OCI vs AWS vs Azure: Oracle Licensing Comparison

Understanding how GCP compares to the other major Oracle cloud platforms is essential for making cloud migration decisions. The table below summarises the key Oracle licensing differences:

The most notable structural difference is that OCI provides twice the compute coverage per Processor licence compared to GCP, AWS, and Azure. An organisation running Oracle Database on a 16-vCPU GCE instance needs 8 Processor licences; the same workload migrated to an equivalent OCI compute instance would require only 4 Processor licences, halving the licence cost and the ongoing 8% annual support escalator on that licence estate.

Oracle Support Rewards on Google Cloud

One significant advantage of running Oracle workloads on GCP — compared to AWS and Azure — is that Oracle now accrues Oracle Support Rewards on Google Cloud spending. Oracle Support Rewards are credits that reduce on-premises Oracle support fees based on OCI or approved cloud consumption. Google Cloud was added to the Oracle Support Rewards programme as part of the ACE designation, meaning GCP Oracle spend can offset on-premises support obligations.

For organisations with large Oracle on-premises support bills that are migrating workloads to GCP, this creates a path to reducing the compounding 8% annual support escalator that applies to perpetual licences. The mechanics require careful structuring — Oracle Support Rewards accrue as a percentage of cloud spending and must be applied within specific timeframes — but for large GCP consumers with significant Oracle on-premises footprints, the savings can be material.

Common Oracle Compliance Risks on Google Cloud

1. vCPU Miscounting

The most common GCP Oracle compliance error is miscounting vCPUs. Some organisations count physical cores using GCP's documentation (which describes underlying hardware), rather than the vCPU count visible to the operating system. Oracle's rule is based on the vCPU count visible to the guest OS — not the underlying physical cores or hyperthreads at the hypervisor level. When in doubt, the number to use is the vCPU count that Oracle software would report if it queried the system.

2. Unlicensed Oracle Database Options

As on any cloud platform, Oracle Database Options installed or enabled on GCE instances must be separately licenced. Diagnostics Pack and Tuning Pack are commonly enabled by default in Oracle Database installations and both require separate licences (approximately $7,500 per Processor each at list price). Oracle's LMS audit scripts will detect enabled options regardless of whether they were deliberately configured or enabled by default tooling.

3. GKE Container Deployments

Organisations running Oracle Database in containers on Google Kubernetes Engine (GKE) face the same containerisation problem as in any cloud: Oracle does not recognise Kubernetes as hard partitioning, and all GKE worker nodes in the cluster where Oracle containers could run must be licenced. This is a rapidly growing source of Oracle compliance exposure as organisations modernise application architectures using GKE.

4. Oracle RAC Assumed on GCE (It Is Not Supported)

Oracle Real Application Clusters (RAC) is not supported on standard GCE virtual machine instances. RAC requires shared storage access from multiple database nodes — a capability GCE's networking and storage architecture does not provide for standard VMs. Organisations that attempt to run Oracle RAC on GCE VMs are not only outside Oracle's supported configuration but are also likely violating RAC licence terms. RAC on GCP is supported only on Google Cloud Bare Metal Solution.

Migrating from On-Premises to GCP: Oracle Licence Considerations

When planning an Oracle Database migration from on-premises to GCP, several licence transition questions must be addressed before the migration begins — not after:

Licence sufficiency: Does your current Processor licence count cover the required vCPU count of the target GCE instances? For an on-premises server with 16 physical Intel cores (8 Processor licences at 0.5 factor), migrating to a GCE instance with 16 vCPUs requires the same 8 Processor licences — a clean mapping. But migrating to a 32-vCPU GCE instance would require 16 Processor licences, creating a shortfall of 8 licences that must be purchased before migration.

Options licences: All Oracle Database Options in use on-premises must be licenced for the GCE deployment — there is no grace period or cloud migration exemption. If on-premises databases use Diagnostics Pack or Advanced Compression under a site licence, verify that those licence rights extend to cloud deployments before assuming coverage.

ULA coverage: If your on-premises Oracle deployments are covered by a ULA (Unlimited Licence Agreement), verify that the ULA terms explicitly cover cloud deployments. Some older ULAs are restricted to on-premises use. Under a ULA, GCP deployments should be captured in the certification count to maximise the perpetual entitlement certified out of the agreement.

Right-sizing before migration: GCP Oracle migrations are the optimal time to right-size Oracle Database deployments. Moving a database from a 32-core on-premises server (16 Processor licences) to a smaller GCE instance may be possible if the workload does not require all 32 cores. Every vCPU reduction reduces future licence and support obligations. Oracle support fees increase by 8% per year — a reduction in Processor licences made before a migration has a compounding benefit for years.

GCP vs OCI: When to Choose Each for Oracle Workloads

The decision between deploying Oracle on GCP or migrating to OCI is a strategic one that goes beyond Oracle licensing, but the licensing economics are a major input:

Choose GCP when: Your organisation is deeply invested in Google Cloud services (BigQuery, Vertex AI, Google Workspace integrations), your Oracle Database workloads are relatively small and the 2 vCPU = 1 Processor rule does not create prohibitive licence costs, or you are migrating away from Oracle technology entirely and GCP represents an interim platform while you replatform to non-Oracle databases.

Consider OCI when: You have large Oracle Database EE deployments where OCI's 2 OCPUs = 1 Processor BYOL advantage provides significant licence savings, you need Oracle RAC or Exadata capabilities, you are approaching a ULA certification and want to maximise deployments on the most licence-efficient platform, or Oracle is offering Oracle Support Rewards or other commercial incentives tied to OCI consumption that reduce your overall Oracle spend.

For many organisations, the right answer is a hybrid approach: Oracle Database workloads with large Processor licence requirements migrate to OCI, while GCP hosts Oracle-adjacent workloads (analytics, application tiers, data pipelines) that benefit from GCP's native data services ecosystem.

Key Takeaways: Oracle Licensing on Google Cloud

• Google Cloud is an Oracle Authorised Cloud Environment (ACE) as of 2024 — BYOL deployments are officially sanctioned.
• The standard rule on GCE is 2 vCPUs = 1 Oracle Processor licence (with hyperthreading enabled).
• GCP is BYOL-only for Oracle Database — there is no licence-included Oracle Database EE option on GCE.
• Google Cloud Bare Metal Solution (BMS) supports Oracle RAC and follows on-premises licensing rules (all physical cores must be licenced).
• Oracle Support Rewards accrue on GCP spending, creating a path to offsetting on-premises Oracle support obligations.
• OCI provides twice the compute coverage per Processor licence compared to GCP — large Oracle Database deployments should model OCI vs GCP licence economics carefully.
• GKE container deployments of Oracle Database trigger cluster-wide licensing obligations — Oracle does not recognise Kubernetes as hard partitioning.
• Oracle support fees increase by 8% per year — right-sizing GCE instances before migration reduces the long-term compounding support cost.
• Oracle does not offer an Enterprise Agreement — ULA, PULA, OCS, and CSI are the contractual structures available for Oracle licensing on GCP.