An independent advisory guide for SAM managers and CIOs running Oracle workloads on GCP — covering the rules Oracle won’t explain clearly.
Oracle licensing on Google Cloud Platform became significantly clearer in 2024 when Oracle officially classified GCP alongside AWS and Azure as an “Authorised Cloud Environment.” Before that, running Oracle on Google Cloud was a grey area — technically possible, but without the formal licensing rules that Oracle published for AWS and Azure. That ambiguity is now resolved, but the complexity has not gone away.
Oracle’s cloud licensing policy — the document titled “Licensing Oracle Software in the Cloud Computing Environment” — provides the counting rules for all three authorised clouds. GCP’s inclusion means enterprises can now apply the same vCPU-to-processor formula used on AWS and Azure when deploying Oracle on Google Cloud. The rules are straightforward on paper: every two vCPUs with hyper-threading enabled equals one Oracle Processor licence. If hyper-threading is disabled, one vCPU equals one licence.
There are three things that SAM managers and CIOs need to understand immediately about this policy:
Oracle’s cloud licensing policy is a publicly available guideline, not a clause in your Oracle licence agreement. Your contract may not mention GCP at all. Oracle expects customers to follow the policy, and auditors will reference it during compliance assessments — but Oracle reserves the right to change these rules at any time. To protect your position, consider negotiating a contract amendment that explicitly references cloud deployment rights, or retain a dated copy of the policy as evidence of the rules you followed.
Neither Google nor Oracle will prevent you from spinning up more Oracle instances on GCP than you have licences for. It’s on your organisation — typically the SAM team — to track vCPU counts running Oracle workloads and ensure they stay within licensed limits. Oracle audits extend to cloud environments, and Oracle’s audit teams treat GCP deployments with the same rigour as on-premises installations.
On-premises, Oracle applies a core factor multiplier (0.5 for Intel x86 cores) that effectively halves the licence requirement. In GCP — and in all authorised clouds — there is no core factor. All vCPUs are counted uniformly. This single rule change can double the licence requirement for the same computing power when migrating from on-premises to GCP. It catches organisations off guard constantly.
For a practical comparison of how Oracle licensing differs across cloud platforms, see our Oracle licensing on AWS vs Azure and Google Cloud guide and our Oracle licensing in public cloud environments overview.
Bring Your Own Licence (BYOL) is the primary — and in most cases the only — method to run Oracle software on GCP. Google Cloud does not provide Oracle licences as part of its service. Companies must bring their existing Oracle licence entitlements and deploy Oracle products on GCP infrastructure under those entitlements.
Before migrating any Oracle workload to GCP, inventory the exact Oracle products and editions you’re licensed for, along with quantities and metric types. Confirm how many Oracle Database Enterprise Edition processor licences or Named User Plus licences your organisation holds, and whether there are geographic or entity restrictions. Only move workloads to GCP if you have sufficient licences to cover the vCPU consumption under cloud counting rules.
For every GCP instance running Oracle, create a mapping document that ties the instance’s vCPU count to the number of processor licences consumed. An 8-vCPU Google Compute Engine VM running Oracle Database EE consumes 4 processor licences. This mapping should reference specific contract line items and CSI numbers. It’s invaluable evidence during an audit and prevents oversubscription.
Google Cloud Marketplace offers pre-configured Oracle images labelled “BYOL.” These images make it easy to launch an Oracle database VM, but they assume you have the licence. The word “BYOL” on the image means “you bring it” — Google is providing the software, not the licence. If a developer launches an Oracle BYOL image without an available licence allocation, you’re immediately non-compliant.
Oracle requires active support coverage for BYOL in authorised clouds. Running Oracle on GCP with lapsed support creates both a security risk (no patches) and a compliance flag that Oracle auditors will identify. Always include support renewal costs — typically 22% of net licence value annually — in your cloud migration budget.
Cloud makes it trivially easy to spin up new Oracle instances. Without governance controls, developers and project teams can create Oracle deployments that your SAM team doesn’t know about. Implement tagging policies for Oracle-related cloud resources, require approval workflows before Oracle images can be launched, and run regular GCP environment scans for undocumented Oracle installations. Learn more about Oracle licensing on Google Cloud — detailed licensing options.
For a detailed comparison of how BYOL works across all major cloud platforms, see Oracle BYOL: using on-premises Oracle licences in OCI, AWS, Azure, and GCP. For guidance on the broader Oracle licensing framework, our Oracle Licensing Guide for CIOs and Procurement Teams is essential reading.
Every Oracle deployment on GCP requires a licence allocation from your pool — production, development, test, DR, and failover instances alike. A single untracked Oracle VM can create thousands of dollars in compliance exposure during an audit. Treat BYOL in GCP with the same rigour you’d apply in your own data centre.
The single most consequential rule in Oracle licensing on Google Cloud is the vCPU-to-processor conversion. Get this wrong, and you’re either non-compliant (under-licensed) or overspending (over-licensed). Neither outcome is acceptable.
The rule: In GCP, every two vCPUs count as one Oracle Processor licence when hyper-threading is enabled (which it is on nearly all standard GCP instance types). If hyper-threading is disabled, one vCPU equals one licence. The minimum is always one licence — there are no fractional licences.
This formula mirrors what Oracle applies on AWS and Azure. But here’s where it gets expensive: Oracle’s on-premises Core Factor Table — which gives a 0.5 multiplier for Intel x86 cores, effectively halving the licence requirement — does not apply in any public cloud. This means that a workload requiring 4 processor licences on-premises (8 physical cores × 0.5 core factor) will require 8 processor licences on GCP (16 vCPUs ÷ 2).
| Workload | On-Premises (Core Factor 0.5) | GCP (vCPU counting, no Core Factor) | Impact |
|---|---|---|---|
| Oracle DB EE on 4 x86 cores | 2 processor licences | 4 processor licences (8 vCPUs) | 2× increase |
| Oracle DB EE on 8 x86 cores | 4 processor licences | 8 processor licences (16 vCPUs) | 2× increase |
| Oracle DB EE on 16 x86 cores | 8 processor licences | 16 processor licences (32 vCPUs) | 2× increase |
| Oracle WebLogic on 4 x86 cores | 2 processor licences | 4 processor licences (8 vCPUs) | 2× increase |
At Oracle Database Enterprise Edition list pricing of $47,500 per processor licence (plus 22% annual support), that doubling adds up fast. An 8-core on-premises workload that needed 4 licences ($190,000 + $41,800/year support) now requires 8 licences ($380,000 + $83,600/year support) on GCP. That’s $190,000 in additional licence cost and $41,800 in additional annual support — for the same computing power.
For a complete breakdown of Oracle’s pricing mechanics, see our Oracle Technology Price List guide. For the full database licensing picture, including editions and options, read our Oracle Database Licensing Guide.
Migration Licence Shock: 10 Licences Became 20. A financial services firm migrated an Oracle workload to GCP expecting to use their existing 10 processor licences. Under GCP’s vCPU counting rules — with no Core Factor Table credit — the deployment actually consumed 20 processor licences. The compliance gap was identified during our independent assessment before Oracle could flag it in an audit.
$475,000 in avoided back-licence costs + backdated support.
Google Cloud offers three primary ways to run Oracle workloads, and each carries different licensing implications:
The most common deployment model. You launch a GCP virtual machine, install Oracle software (either from a Marketplace BYOL image or manually), and licence it using the vCPU counting rules above. You have full control over instance sizing, and you can scale vCPUs up or down — but every change affects your licence consumption. This is identical in concept to running Oracle on AWS EC2 or Azure VMs.
For workloads requiring dedicated physical hardware — typically for performance, isolation, or licensing reasons — GCP offers Bare Metal Solution. These are physical servers provisioned within Google’s data centres but dedicated entirely to your workload. When running Oracle on Bare Metal, Oracle’s standard on-premises licensing rules apply, including the Core Factor Table. This means you can licence by physical cores with the 0.5 multiplier for Intel processors, potentially halving the licence count compared to a VM deployment.
The trade-off: Bare Metal is less flexible than VMs (no auto-scaling, no rapid provisioning) and typically more expensive from an infrastructure standpoint. But for large Oracle estates, the licence savings from Core Factor Table eligibility can far outweigh the higher infrastructure cost.
The newest option. Similar to Oracle Database@Azure, this is an Oracle-managed database service running on Oracle Exadata infrastructure inside GCP data centres. The key licensing difference: this service can be purchased as licence-included (the Oracle licence cost is bundled into the service fee) or as BYOL. The licence-included model simplifies compliance entirely — you pay Oracle directly through the service subscription and don’t need to count vCPUs or manage licence entitlements. The trade-off is higher per-unit cost and tighter Oracle lock-in. Learn more about Oracle licensing on Azure.
| Deployment Option | Licensing Model | Core Factor Applies? | Best For |
|---|---|---|---|
| Compute Engine VMs | BYOL (vCPU counting) | No | Flexible workloads, dev/test, smaller databases |
| Bare Metal Solution | BYOL (physical core counting) | Yes (0.5 for Intel) | Large Oracle estates, RAC, Exadata-class workloads |
| Oracle Database@Google Cloud | BYOL or Licence-Included | N/A (Oracle-managed) | Enterprises wanting Oracle-managed DB with GCP integration |
For a detailed look at how Oracle’s vCPU counting works across all cloud platforms, see our Oracle licensing in public cloud environments guide. For the full database licensing picture including editions and options, read our comprehensive Oracle Database Licensing Guide.
Oracle imposes specific restrictions on Standard Edition deployments in all authorised clouds, and GCP is no exception. Getting this wrong is a common audit finding.
Standard Edition 2 (SE2) can only be deployed on GCP instances with up to 8 vCPUs. Deploy SE2 on a larger instance and you’re in breach — Oracle will require you to purchase Enterprise Edition licences for the entire instance, which is dramatically more expensive.
Standard Edition (legacy SE and SE1) is limited to instances with up to 16 vCPUs. These editions are no longer sold but may still be in use under existing licences.
For SE2 licensing on GCP, the metric is per-socket equivalent: instances with up to 4 vCPUs count as one socket (one SE2 processor licence). Instances with 5–8 vCPUs count as two sockets (two SE2 processor licences). At SE2 list pricing of $17,500 per licence, that’s a significant cost difference compared to Enterprise Edition at $47,500 per licence.
Named User Plus (NUP) minimums also apply in the cloud. For Enterprise Edition, the minimum is 25 NUP per processor (where “processor” is calculated using the vCPU formula). For SE2, the minimum is 10 NUP per 8-vCPU block. These minimums are frequently overlooked in cloud deployments.
Our comprehensive Oracle Database Licensing Guide covers edition-specific rules in full detail. Also see our guide on Oracle Database licensing in cloud environments for the most common compliance traps.
Deploying Oracle SE2 on a GCP instance with more than 8 vCPUs violates Oracle’s licensing terms. GCP will not enforce this limit — it’s entirely on you. Oracle auditors specifically look for oversized SE2 deployments because the compliance gap (upgrading to Enterprise Edition) is enormously expensive. Right-size your instances before deployment.
Oracle’s licensing rules for HA and DR environments apply in GCP just as they do on-premises — and they are consistently misunderstood.
If you run Oracle Data Guard in Active Data Guard mode (where the standby database is open for reads), the standby instance must be fully licensed — same metric, same quantity as the primary. This applies on GCP identically to on-premises.
Oracle’s standard failover policy allows a passive standby (not open for any purpose) to run on reduced licensing in some configurations, but the rules are narrow and Oracle interprets them conservatively. If the standby is mounted but not opened, and failover is manual (not automatic), you may qualify for the “10-day rule” — but confirm this against your specific contract and Oracle’s current policy.
If your DR deployment is in a different GCP region, the vCPU count for the DR instance must be licensed separately. There’s no “shared licence” across primary and DR — each instance consumes licences independently.
Oracle Real Application Clusters requires shared storage and a cluster interconnect that GCP Compute Engine doesn’t natively support. RAC is available on GCP Bare Metal Solution and potentially via Oracle Database@Google Cloud. If you’re migrating a RAC deployment from on-premises to GCP, this constraint may force architectural changes — and different licensing calculations.
Oracle audits now routinely include cloud environment discovery. Prepare by maintaining a real-time inventory of every GCP instance running Oracle software, with vCPU counts, Oracle product editions, enabled options, and the licence entitlements allocated to each. Tag all Oracle-related GCP resources consistently. Document your GCP deployment architecture with screenshots and configuration exports — the same evidence standards you’d apply to a VMware environment.
For audit preparation strategies, see our Oracle Audit Defense Service page and our Oracle licensing VMware — audit strategies guide (the evidence standards apply equally to cloud environments). Our Oracle licensing assessment case studies show how proactive reviews avoid audit exposure.
Oracle’s licensing rules are remarkably consistent across AWS, Azure, and GCP — but the economic differences between platforms are significant, especially when you include OCI in the comparison.
| Factor | OCI | AWS | Azure | GCP |
|---|---|---|---|---|
| Licence counting | 1 OCPU = 1 licence | 2 vCPUs = 1 licence | 2 vCPUs = 1 licence | 2 vCPUs = 1 licence |
| Core Factor Table | Not directly; 1:1 OCPU | No | No | No |
| Licence-Included option | Yes (Autonomous DB, etc.) | AWS RDS for SE2 only | Database@Azure | Database@Google Cloud |
| Oracle RAC support | Yes | No | No (except DB@Azure) | Bare Metal / DB@GCP only |
| Bare Metal option | Yes | No dedicated Oracle BM | No | Yes (Bare Metal Solution) |
| Support Rewards | Yes (25–33% credit) | No | No | No |
| Authorised Cloud status | First-party (inherent) | Yes (since ~2017) | Yes (since ~2017) | Yes (since 2024) |
The key takeaway: OCI is the most licence-efficient platform for Oracle workloads because one processor licence effectively covers twice the compute capacity (1 OCPU = 2 vCPUs worth of processing power). On OCI, 1 licence covers 1 OCPU. On GCP/AWS/Azure, 1 licence covers only 2 vCPUs. For the same workload, OCI typically requires half the licences.
However, GCP has one advantage that AWS and Azure lack: the Bare Metal Solution, which allows Core Factor Table application and can make GCP competitive with OCI for large Oracle estates where physical server deployment makes sense.
For detailed platform-specific licensing rules, see Oracle licensing on AWS vs Azure and Google Cloud. For Azure-specific details, see Oracle licensing on Azure. For BYOL mechanics across all clouds, read Oracle BYOL: on-premises licences in OCI, AWS, Azure, and GCP.
Multi-Cloud Oracle Strategy? We model the licence cost across every platform — OCI, AWS, Azure, and GCP — with no vendor bias, so you can make the decision with real numbers.
The licence cost increase from on-premises to GCP is not inevitable. Several strategies can reduce or offset the impact:
If your organisation has an active Oracle Unlimited License Agreement (ULA), running Oracle on GCP during the ULA term is permitted — your unlimited deployment rights cover cloud environments. But the certification trap is real and consequential.
Standard ULA contracts may not allow GCP deployments to count toward certification. When you certify a ULA at end-of-term, you declare your deployment quantities to lock in perpetual licences. Under many standard ULA terms, only on-premises deployments (and in some cases OCI) can be counted at certification. Cloud deployments on GCP, AWS, or Azure may be excluded — meaning you deployed Oracle freely on GCP during the ULA, but those deployments don’t convert into perpetual entitlements.
This creates a dangerous scenario: you’ve been running Oracle on GCP for three years under the ULA. The ULA expires. You certify your on-premises deployments. The GCP deployments are suddenly unlicensed — because they weren’t counted in the certification and you don’t have separate licences for them.
Mitigation: Before deploying Oracle on GCP under a ULA, review your ULA contract’s certification clause with your licensing advisor. If cloud deployments aren’t explicitly included in certification scope, either negotiate an amendment before the ULA expires or plan to migrate those GCP workloads back to on-premises (or OCI) before certification.
For detailed guidance on ULA certification strategy, see our Oracle ULA Certification playbook and the complete guide to Oracle ULAs. Our Oracle ULA License Optimization Service helps enterprises navigate these exact scenarios.
Running Oracle on GCP under a ULA does not guarantee those deployments will count at certification. If your ULA contract doesn’t explicitly cover cloud certification, those GCP-based Oracle deployments could become unlicensed the day after your ULA expires. Review your certification clause now — not at T-minus-30 days.
Want us to run through this checklist with you? Free consultation, no obligation.
Oracle counts licences on GCP using a vCPU-to-processor formula: every two vCPUs with hyper-threading enabled equals one Oracle Processor licence. If hyper-threading is disabled, one vCPU equals one licence. The on-premises Core Factor Table does not apply on GCP. This formula is identical across AWS, Azure, and GCP. For a full comparison, see our Oracle licensing on AWS vs Azure and Google Cloud guide.
Yes. Oracle officially added Google Cloud Platform to its list of Authorised Cloud Environments in 2024, alongside AWS and Azure. This means Oracle has published formal licensing rules for GCP. However, the authorisation is a non-contractual policy document — Oracle can change it at any time, and your Oracle licence agreement may not explicitly mention GCP.
Yes, through the BYOL (Bring Your Own Licence) model. You deploy Oracle on GCP using your existing licence entitlements. However, the vCPU counting rules mean you’ll typically need more licences for the same workload compared to on-premises due to the absence of the Core Factor Table. See our comprehensive BYOL guide for details.
No — not on GCP virtual machines. The Core Factor Table only applies to physical hardware deployments. On GCP Compute Engine VMs, all vCPUs are counted uniformly at the 2:1 ratio. However, if you use GCP’s Bare Metal Solution (dedicated physical servers), the Core Factor Table does apply because you’re licensing physical cores, not vCPUs.
OCI is significantly more licence-efficient for Oracle workloads. On OCI, one processor licence covers one OCPU (which provides 2 vCPUs of compute power). On GCP, one processor licence covers only 2 vCPUs — which sounds the same but represents less total compute capacity. OCI also offers Support Rewards credits (25–33% of OCI spend applied to Oracle support bills) and full RAC support, neither of which is available on standard GCP VMs. See our Oracle licensing on AWS vs Azure and Google Cloud guide for detailed comparisons.
Yes. Oracle’s standard audit rights extend to all environments where Oracle software is deployed, including GCP. Oracle auditors can request evidence of your GCP deployment configurations, vCPU counts, and licence allocations. Maintain audit-ready documentation of every Oracle instance on GCP. For audit preparation, see our Oracle Audit Defense Service.
Oracle Database@Google Cloud is an Oracle-managed database service running on Oracle Exadata infrastructure deployed inside Google Cloud data centres. Similar to Oracle Database@Azure, it allows enterprises to run Oracle databases with GCP network integration while Oracle manages the infrastructure. It supports both BYOL and licence-included models. The licence-included model bundles the Oracle licence cost into the service fee, simplifying compliance.
Typically no, unless your ULA contract explicitly includes cloud deployments in the certification scope. Standard ULA terms often restrict certification counting to on-premises deployments. If you’re running Oracle on GCP under a ULA and plan to certify, confirm the certification clause covers cloud — or plan to migrate those workloads before certification. See our Oracle ULA Certification playbook for full guidance.
Oracle SE2 can only be deployed on GCP instances with up to 8 vCPUs. Deploying SE2 on a larger instance violates Oracle’s licensing terms and requires upgrading to Enterprise Edition licensing — a dramatic cost increase. GCP will not enforce this limit; compliance is entirely your responsibility.
No. Oracle’s cloud licensing policy (“Licensing Oracle Software in the Cloud Computing Environment”) is a publicly available guideline, not a contractual document. Your actual Oracle licence agreement may not mention GCP. Oracle auditors reference the policy during compliance assessments, and Oracle can update it at any time. To protect your position, consider negotiating a contract amendment that incorporates cloud deployment rights.