Cloud-Based GoldenGate Licensing: OCI, AWS, and Azure
As organizations move to cloud infrastructure, Oracle GoldenGate can also be deployed in the cloud.
There are two main models here: using Oracle’s GoldenGate service on Oracle Cloud (OCI) or deploying GoldenGate manually on third-party clouds like AWS and Azure.
Licensing in the cloud follows some of the same rules as on-premises, with adjustments for cloud-specific metrics and Oracle’s Bring Your License (BYOL) programs.
Oracle Cloud Infrastructure (OCI) Deployment
Oracle offers GoldenGate as a fully managed service on Oracle Cloud Infrastructure, called OCI GoldenGate. This cloud service provides GoldenGate functionality without customers having to manage the underlying servers.
There are a couple of licensing options on OCI:
- Oracle Cloud Subscription (License-Included): You can subscribe to GoldenGate on OCI and pay for it entirely as a cloud service. In this model, you do not need to purchase any on-prem GoldenGate licenses; Oracle includes the software license in the hourly rate. Pricing is typically based on OCPUs (Oracle CPU cores) consumed per hour. For example, Oracle’s public pricing (as of 2025) shows a rate around $0.6721 per OCPU hour for GoldenGate in OCI (this rate can vary by region), which roughly equates to about $0.336 per vCPU hour since 1 OCPU = 2 vCPUs on x86. You are billed through your cloud account and can scale usage up or down. This approach is analogous to any other SaaS/PaaS service – you pay for what you use. It’s ideal for scenarios where you want elasticity or want to avoid upfront licensing costs. Over the long term, license-included cloud pricing could become more expensive than owning licenses, but it provides flexibility and shifts cost to OpEx.
- Bring Your Own License (BYOL) on OCI: Oracle also allows customers to bring their existing GoldenGate licenses to OCI, treating the cloud service as an entitlement they’ve already paid for. In practice, if you already own GoldenGate Processor licenses on-prem (with active support), you can deploy the GoldenGate OCI Service at a much lower hourly cost, paying only for the OCI infrastructure and a small service fee. Oracle’s price list shows a BYOL rate of about $0.1613 per OCPU hour for OCI GoldenGate, about 75% lower than the full license-included rate. The assumption is you’ve already paid for the license via your on-prem purchase. Under BYOL, Oracle’s rules state you must match the licenses. For example, if you spin up GoldenGate using 4 OCPUs on OCI, you should have at least 4 Processor licenses of GoldenGate available (and not concurrently fully used elsewhere). BYOL is a cost-optimization approach if you’re migrating to OCI or bursting to the cloud but want to leverage existing investments.
- License Calculation on OCI: When using BYOL on OCI, Oracle treats two vCPUs as one license (similar to AWS/Azure, see below). OCI’s “OCPU” concept already accounts for that (1 OCPU = one physical core = 2 vCPUs). So if you allocate 1 OCPU of GoldenGate service, that corresponds to one Processor license of your BYOL allocation. The key point is that the core factor is not applied in the cloud – Oracle simply counts cores/vCPUs. In OCI, Oracle manages the mapping for you.
- OCI Marketplace and Compute Instances: Aside from the managed service, one could manually deploy GoldenGate on OCI Compute VMs. Oracle provides machine images and perhaps Marketplace templates for GoldenGate. If you take this route, the licensing is treated like on-prem: you must use your GoldenGate license (BYOL) to cover the OCI VM’s cores. OCI’s advantage here is Oracle’s partitioning policy recognizes OCI virtualization, so you can license just the VM’s OCPUs (no need to license the whole underlying host, since Oracle allows sub-capacity on their cloud). Many clients, however, will opt for the easier managed service unless they need a custom setup.
OCI Summary: Oracle’s cloud offers the most straightforward path for GoldenGate licensing in the cloud—either pay per use with a license included or use BYOL to leverage existing licenses with minimal additional cost.
OCI also frequently has programs (like Oracle Support Rewards) that can further offset cloud costs if you have on-prem support, making OCI an attractive option for running GoldenGate. The choice between license-included vs. BYOL will depend on whether you already own licenses and your expected usage pattern:
- If you already have significant GoldenGate licenses and are moving workloads to OCI, BYOL will be most cost-effective.
- The pay-as-you-go model might be simpler if you are starting fresh or have a short-term need.
Read GoldenGate Licensing for High Availability and Disaster Recovery.
Amazon Web Services (AWS) and Microsoft Azure Deployment
Oracle does not offer a managed GoldenGate service on AWS or Azure. Still, you can run GoldenGate on these clouds by installing it on cloud VMs (EC2 instances, Azure VMs, containers, etc.).
The licensing on AWS/Azure follows Oracle’s “Authorized Cloud Environment” policy:
- Counting vCPUs as Processors: Oracle’s policy for AWS and Azure (“Authorized Cloud Environments” for Oracle licensing) is that each pair of vCPUs counts as one Oracle Processor license for licensing purposes. In other words, two vCPUs = 1 Processor license. This applies to GoldenGate just as it does to Oracle Database. For instance, if you run Oracle GoldenGate on an AWS EC2 VM with eight vCPUs allocated, you need 4 GoldenGate Processor licenses to cover it. If the VM has an odd number of vCPUs, round up (e.g., six vCPUs = three licenses). Oracle explicitly states that the standard Core Factor table does not apply in public cloud VMs like AWS/Azure – they’ve simplified it to the 2-for-1 rule regardless of CPU type.
- No License-Included Option on AWS/Azure: Unlike OCI, AWS/Azure do not sell Oracle GoldenGate as a service with the license bundled. So the only way to run GoldenGate on these clouds is to bring your GoldenGate licenses. If you plan to migrate GoldenGate workloads to AWS or Azure, you should budget to purchase sufficient GoldenGate licenses (or reallocate existing ones) to cover the cloud VMs. One exception could be if you have an Unlimited License Agreement (ULA) or some enterprise arrangement that allows deployment on third-party clouds. However, that is still BYOL in concept.
- AWS/Azure BYOL Example: Suppose you want to set up GoldenGate on an AWS EC2 instance to replicate between an RDS Oracle database and a SQL Server on EC2. If the GoldenGate instance on AWS uses 16 vCPUs, Oracle would require 8 Processor licenses for GoldenGate. You must have those in your inventory (purchased and active). You could choose to run GoldenGate on the same instance as the database or separately – either way, count the vCPUs running GoldenGate processes. Note that if GoldenGate is reading/writing to an Oracle RDS (a managed Oracle DB service on AWS), RDS’s Oracle Database license (which is usually included in RDS pricing or BYOL for DB) does not cover GoldenGate; GoldenGate is separate. You might run the extract on the RDS host via AWS DMS integration or, more commonly, run GoldenGate on a separate EC2 that connects to RDS. In all cases, ensure the GoldenGate EC2’s vCPUs are licensed via BYOL.
- Azure similar: The same two vCPU = 1 license rule applies to Oracle products on Microsoft Azure. If using Azure VMs to host GoldenGate, count the VM’s vCPUs accordingly. Azure doesn’t have an Oracle DB managed service like RDS (except third-party offerings), so both source and target might typically be on VMs or a mix with on-prem.
- Cloud Core Factors Pitfall: A common mistake is applying the on-prem core factor to cloud VMs. For example, someone might think “my AWS instance is an Intel x86, factor 0.5, so eight vCPUs × 0.5 = 4 licenses (which is true), but then apply 0.5 again on top of the 2:1 rule or instead of it incorrectly.” Oracle’s rule already effectively gives 0.5 per vCPU because of the 2-for-1. Do not apply the core factor to the cloud twice – it’s one or the other. Oracle’s documentation highlights that misapplying core factors to cloud deployments is a compliance risk.
- Multi-Cloud and Hybrid Considerations: If you are running GoldenGate in a hybrid cloud scenario (e.g., one end on-prem, one end on AWS), you’ll need to ensure both are licensed appropriately. The on-prem side could use standard processor licensing, and the AWS side uses the 2:1 vCPU rule. If you have a pool of GoldenGate licenses, you can split them across environments; just track the usage. Oracle licenses generally float within your organization – you just need enough licenses for the total deployment. For instance, you might repurpose some on-prem licenses to cover an AWS deployment (essentially a BYOL move) – just make sure not to double-count if both environments run concurrently beyond your entitlements.
- Containers and Kubernetes: Some organizations containerize GoldenGate Microservices in Kubernetes clusters on the cloud. Oracle’s stance on container licensing is evolving, but generally it’s similar to VMs – you must license the underlying compute nodes (especially if the container can move across nodes). On AWS EKS or Azure AKS, for example, if GoldenGate containers can run on any cluster node, you’d need to license the vCPUs of those nodes (or use mechanisms to constrain the scheduling to specific licensed nodes).
Cloud Licensing Takeaway: Running GoldenGate on AWS or Azure is fully supported, but you must bring your licenses. Oracle’s standardized vCPU counting makes it somewhat easier to calculate needs: count all vCPUs where GoldenGate will run and divide by 2 for the number of licenses.
Ensure you include all active GoldenGate instances (including for high availability or dev/test, if applicable) in that count. One advantage of cloud VMs is that you can choose instance sizes to manage license usage – e.g., instead of a 32 vCPU monster VM (which would need 16 licenses), you might run two eight vCPU instances (needing 4+4=8 licenses) if that suffices for throughput.
The total license count is the same in that simplistic example, but in some cases, splitting or right-sizing instances can avoid waste. Remember that if you spin up additional instances for scaling out, those add to your license requirements if running simultaneously.
Bring Your Own License (BYOL) Summary
Whether on OCI or AWS/Azure (or other clouds), the BYOL model allows you to apply existing GoldenGate licenses to cloud deployments.
A few best practices for BYOL:
- Maintain Support: Oracle typically requires that licenses moved to the cloud under BYOL be covered by active support contracts. This ensures that you have rights to new versions (often needed for the cloud) and that the usage is considered authorized.
- Avoid Dual Use: If you shift a license to the cloud, ensure you’re not accidentally using that same license for on-prem deployment simultaneously beyond your total count. This can happen during transitions (e.g., cloud testing before decommissioning on-prem). A short overlap is usually okay if within the same license count (since Oracle licenses are not tied to a specific server, just count), but document what is running where in case of an audit.
- Cloud Provider Specific: Outside AWS/Azure/OCI, other clouds (Google Cloud, IBM Cloud, etc.) are not explicitly covered by Oracle’s relaxed vCPU rule. Technically, Oracle might treat those like on-prem (i.e., it requires counting each vCPU as one if it is not “authorized”). This is a grey area – Google Cloud, for instance, is not listed in Oracle’s policy document. Many clients also apply the 2:1 rule there by analogy, but it’s not officially blessed. If using a less common cloud, consult independent licensing experts to clarify how to license properly.
By effectively leveraging BYOL, organizations can migrate GoldenGate workloads to the cloud without incurring duplicate licensing costs. Conversely, Oracle’s own OCI GoldenGate service provides an option to completely avoid license management in exchange for a higher ongoing fee, which might be worthwhile for some use cases (e.g., a short-lived project or uncertain scale).
