Oracle GoldenGate Licensing in Cloud and Hybrid Environments — AWS, Azure, OCI, and Multi-Cloud Compliance

How Oracle Licences GoldenGate — The Fundamentals

Oracle GoldenGate is a real-time data replication and integration platform used to keep databases synchronised across environments. Unlike most Oracle database options that are bundled with database licences, GoldenGate is a standalone product with its own licensing requirements. Every server — source and target — that runs GoldenGate processes must hold sufficient licences, regardless of which database engine it connects to.

GoldenGate is licensed exclusively on a Processor metric. There is no Named User Plus (NUP) option. The list price is $17,500 per Processor licence, with annual support at approximately 22% of the net licence fee. In enterprise deals, discounts of 20–40% off list are common, but the Processor-only metric means costs scale directly with compute capacity — making architecture decisions critically important to licence spend.

The critical point that trips up most enterprises is the dual-licensing requirement. If GoldenGate replicates from Server A to Server B, both servers need GoldenGate licences — counted according to the rules of each server's environment. In a hybrid scenario where Server A is on-premises and Server B is in AWS, you apply core factors to Server A and the 2-vCPU rule to Server B. Missing either side is a compliance gap that Oracle auditors will identify.

GoldenGate on AWS and Azure — BYOL Licensing Rules

When deploying GoldenGate on Amazon Web Services or Microsoft Azure, Oracle's Authorised Cloud Environment licensing policy applies. This policy replaced the older cloud counting rules and establishes a simple formula: two vCPUs equal one Processor licence. No core factor table is used. No distinction is made between Intel, AMD, or Graviton processors.

This is a Bring Your Own Licence (BYOL) model. You either reassign existing on-premises GoldenGate licences to the cloud VMs (provided they are not simultaneously used elsewhere) or purchase new licences. There is no cloud-only GoldenGate SKU for AWS or Azure — you buy standard Processor licences and deploy them under BYOL terms.

When reassigning licences from on-premises to the cloud, several constraints apply. First, the licences must have active support — you cannot redeploy unsupported licences under BYOL. Second, the licences cannot be simultaneously deployed on-premises and in the cloud. If you are migrating GoldenGate from a data centre to AWS, you must decommission the on-premises installation before the cloud deployment is compliant under the same licences. Third, ensure your Oracle ordering documents do not contain restrictive territory or deployment clauses that might limit cloud use — some older contracts include geographic restrictions that could technically prevent BYOL deployment in certain cloud regions.

For enterprises purchasing new GoldenGate licences specifically for cloud deployment, the procurement process is identical to on-premises: you acquire Processor licences through an Oracle ordering document, typically negotiating the standard enterprise discount. The licence purchase carries no restriction on deployment environment — the same licence can be deployed on-premises, in AWS, in Azure, or in OCI under BYOL terms, provided it is only active in one location at a time.

"The single most common licensing mistake we see with GoldenGate in AWS and Azure is applying the on-premises core factor (0.5 for Intel) to cloud vCPUs. Oracle's cloud policy explicitly overrides the core factor table. An 8-vCPU instance requires 4 licences — not 2. This error alone accounts for roughly half of GoldenGate audit findings in cloud environments."

Several additional rules apply to AWS and Azure deployments that enterprises frequently overlook:

• You must licence all vCPUs allocated to the VM — not just the ones GoldenGate "uses." If GoldenGate runs on an 8-vCPU instance but typically consumes only 2 vCPUs of compute, you still need 4 Processor licences.
• Auto-scaling creates compliance risk. If your infrastructure scales GoldenGate instances up to larger VMs during peak periods, the larger vCPU count defines your licence requirement — even if the scaling is temporary.
• Containers and Kubernetes follow the same vCPU rules. If GoldenGate runs in a container on a node with 16 vCPUs, you must licence all 16 vCPUs (8 Processor licences) unless you can demonstrate hard partitioning that limits the container to a fixed subset of CPUs. Kubernetes soft limits (resource requests/limits) do not qualify as hard partitioning under Oracle's policy.

GoldenGate on Oracle Cloud Infrastructure (OCI)

Oracle Cloud Infrastructure offers GoldenGate as a fully managed cloud service, fundamentally changing the licensing model. Instead of purchasing perpetual Processor licences, you pay an hourly subscription rate based on OCPU consumption. Oracle's published rate is approximately $0.32 per OCPU-hour (licence included), though pricing varies by region and is subject to change.

The OCI managed service handles infrastructure provisioning, patching, scaling, and monitoring — significantly reducing operational overhead compared to self-managed GoldenGate deployments. However, it introduces a different cost dynamic. For a workload running 4 OCPUs continuously for a month (730 hours), the licence-included cost is approximately $934 per month ($0.32 × 4 × 730). Over three years, that totals roughly $33,600 — compared to a one-time perpetual licence cost of $70,000 (for 4 Processor licences at list) plus approximately $46,200 in cumulative support fees over the same period.

The break-even calculation depends on your discount level, workload variability, and operational costs. For steady 24/7 production workloads, BYOL on OCI or perpetual ownership typically wins. For intermittent, variable, or migration-phase workloads, the licence-included hourly model avoids stranded licence costs.

OCI also supports auto-scaling for the managed GoldenGate service, which can dynamically increase OCPU allocation during high-throughput periods and scale down during quiet periods. This is a powerful cost optimisation lever — particularly for enterprises with predictable peak windows (e.g., end-of-day batch replication or monthly close processing). Under the licence-included model, you pay only for the OCPUs consumed, so a service that scales from 2 OCPUs to 8 OCPUs for two hours and then returns to 2 OCPUs incurs the higher rate only during those peak hours. Under perpetual or BYOL licensing, you would need to licence the peak capacity permanently.

One additional consideration for OCI deployments: Oracle's managed GoldenGate service runs on Oracle-managed infrastructure that you do not directly control. This means you cannot install custom GoldenGate configurations, use unsupported adapters, or run GoldenGate alongside other workloads on the same compute. If your architecture requires deep customisation or co-location of GoldenGate with other processes, a self-managed IaaS deployment on OCI (using BYOL licences on a Compute instance) provides more flexibility — but shifts operational responsibility back to your team.

Hybrid Deployment Scenarios — On-Premises to Cloud

The most common — and most compliance-sensitive — GoldenGate architecture is the hybrid model: replication between on-premises databases and cloud instances. This creates a split licensing environment where different counting rules apply to each side of the replication pipeline.

Hybrid deployments require careful documentation. Oracle's audit teams will examine both environments, and the methodology differs for each. Ensure your software asset management (SAM) records clearly map which licences cover which servers, with vCPU counts for cloud instances and core/socket details for on-premises hardware.

Multi-Cloud Replication

Some enterprises replicate data across multiple clouds — for example, from OCI to AWS for analytics, or from Azure to GCP for disaster recovery. Each cloud environment running GoldenGate requires its own licensing. If GoldenGate runs on both an OCI instance and an AWS instance, you need OCI subscription coverage and BYOL Processor licences for the AWS side. There is no cross-cloud licence sharing.

For architectures involving GoldenGate Hub configurations — where a central intermediary server distributes changes to multiple targets — the hub server itself must be fully licensed in addition to all endpoints. The hub's licence requirement is based on its own compute capacity, not the aggregate of downstream targets. This distinction matters because hub servers often run on relatively small instances, making them a cost-efficient consolidation point — but only if each downstream target server running GoldenGate Replicat is also independently licensed.

Disaster Recovery and Standby Licensing

A frequent and costly misconception is that GoldenGate on a disaster recovery (DR) or standby system does not require licensing because the system is "idle." This is incorrect. Oracle's licensing policy requires that any server where GoldenGate is installed and actively applying data must hold full licences — even if that server only activates during a failover event.

"Oracle's 10-day failover rule, which provides limited licensing relief for certain database deployments, does not apply to GoldenGate. If GoldenGate is installed on a DR server and configured to apply changes — even in a passive warm-standby mode — that server requires full Processor licensing."

This has significant cost implications for enterprises that maintain cloud-based DR environments. A GoldenGate Replicat running on a DR instance in AWS, continuously applying changes to keep the standby database current, needs the same licensing as a production instance. Strategies to manage this cost include:

• Right-size DR instances: Use smaller VM types for DR than for production. A production GoldenGate on an 8-vCPU instance needs 4 licences, but if the DR instance runs on a 4-vCPU VM, it only needs 2 licences.
• Evaluate cold standby: If GoldenGate is not installed or not running on the DR server (only activated manually during failover), licensing may not be required during the dormant period. However, this increases recovery time and must be carefully documented.
• Consider OCI for DR: Using OCI's managed GoldenGate service for DR with pay-as-you-go billing can be more cost-effective than maintaining perpetual licences on a server that rarely runs at full capacity.

For detailed guidance, see the companion article GoldenGate Licensing for High Availability and Disaster Recovery.

GoldenGate with Non-Oracle Databases and Big Data Targets

Oracle GoldenGate supports replication to and from a wide range of non-Oracle databases — including MySQL, PostgreSQL, SQL Server, Db2, Teradata, and big data platforms such as Apache Kafka, Hadoop, and Amazon Kinesis. The licensing requirement does not change based on the target or source database engine: every server running GoldenGate processes must be licensed, regardless of which databases it connects to.

This means a GoldenGate deployment replicating from Oracle Database to Kafka on a 16-vCPU AWS instance requires 8 GoldenGate Processor licences for the Kafka-side server — even though no Oracle database runs there. Enterprises that assume GoldenGate licensing only applies to Oracle-to-Oracle replication are a frequent audit target.

For complete details, see the companion article Oracle GoldenGate Licensing for Non-Oracle Databases and Big Data.

Common Audit Risks and Compliance Traps

GoldenGate is one of Oracle's most frequently under-licensed products. Its distributed nature — running on multiple servers, often in different environments with different counting rules — creates ample opportunity for compliance gaps. Oracle's Licence Management Services (LMS) and Global Licensing & Advisory Services (GLAS) teams have become increasingly sophisticated at identifying GoldenGate deployments during audits.

Additional audit risks include containerised deployments where GoldenGate runs on Kubernetes clusters without proper hard partitioning documentation, auto-scaled instances where the peak vCPU count exceeds the licensed quantity, and test/dev environments that run GoldenGate without dedicated licences. Oracle treats all installed and running instances identically — there is no free tier for non-production GoldenGate.

Another area of increasing audit focus is GoldenGate Marketplace images. AWS and Azure marketplaces both offer GoldenGate deployment templates that make provisioning quick and simple. However, launching a Marketplace image does not automatically create licence compliance — the image merely installs the software. You still require either BYOL Processor licences or an active OCI subscription covering that instance. Enterprises that spin up GoldenGate Marketplace images for testing and forget to decommission them or account for the licence requirement accumulate compliance exposure with each untracked instance.

Oracle's audit teams now routinely request cloud console access or usage reports from AWS and Azure as part of their verification process. Having clean, timestamped records of when GoldenGate instances were running, their vCPU allocations, and which licence entitlements cover them is no longer optional — it is essential for defensible audit response.

Proactively, enterprises should conduct an internal GoldenGate licence position review at least annually. Inventory every server (physical, virtual, and cloud) where GoldenGate processes run, calculate the licence requirement for each, and compare against entitlements. For detailed audit scenarios and defence strategies, see GoldenGate Common Audit Risks and Non-Compliance Scenarios.

Cost Optimisation Strategies

GoldenGate's Processor-only metric and dual-licensing requirement mean that architecture and deployment decisions directly drive licence costs. Several proven strategies can significantly reduce total expenditure without compromising replication functionality.

Strategic Recommendations for CIOs and IT Leaders

Related Reading