Oracle Licensing in the Cloud: OCI vs AWS vs Azure vs GCP – A Guide for SAM Managers

Oracle Cloud licensing – Compare Oracle, AWS, Azure, and GCP

• Oracle OCI: License included or BYOL, with support rewards.
• AWS: BYOL or limited license-included (RDS SE2).
• Azure: BYOL model only; OCI-Azure interoperability.
• GCP: BYOL, Oracle Cloud services available, vCPU licensing.

Introduction: The Challenge of Oracle Licensing in Multi‑Cloud

Oracle’s licensing is famously complex, and moving Oracle software into the cloud adds new twists for Software Asset Management (SAM) professionals.

Each major cloud—Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)—has its own rules and options for Oracle licensing.

SAM managers must navigate Bring Your Own License (BYOL) policies, virtual CPU counting, cloud-specific license offerings, support agreements, and high availability considerations while ensuring compliance to avoid costly audits.

Oracle’s specific policy document for “Authorized Cloud Environments” (covering AWS, Azure, and now GCP) defines how licenses are counted in those clouds​.

Keeping track of these rules is vital, as Oracle can update the policy and typically does so to its advantage​.

In this guide, we’ll compare Oracle’s licensing practices across OCI, AWS, Azure, and GCP, focusing on practical details SAM managers care about: BYOL rules, vCPU/core licensing, license-included services, support responsibilities, HA/DR licensing, and common pitfalls (including audit risks) on each platform.

Short, tactical insights and examples are provided to help you keep your Oracle deployments compliant and cost-efficient in a multi-cloud environment.

Oracle Cloud Infrastructure (OCI) – Oracle’s Home Turf

Bring Your Own License (BYOL):

OCI fully supports BYOL for Oracle software. Companies can apply their existing on-premises Oracle licenses to OCI instances or services, often termed “BYOL2PaaS” when used for Oracle’s platform services. Oracle even provides tooling in OCI to declare BYOL usage and help track compliance.

For example, when provisioning an Oracle Database on OCI, you can select a BYOL option and specify your license type. OCI will inform you of how many licenses you need for that deployment​. OCI’s BYOL program is straightforward since it’s Oracle’s cloud – there are typically no hidden restrictions beyond standard license rules.

Ensure the licenses you bring have active support and are equivalent to the OCI service (e.g., Enterprise Edition database licenses to cover an Enterprise DB service).

Oracle sales often encourage BYOL on OCI by highlighting cost savings (no duplicate licensing needed) and ease of compliance.

Oracle Licensing on Oracle Cloud OCI

vCPU/Core Licensing Methodology:

OCI uses the Oracle CPU (OCPU) concept, representing one physical core with hyperthreading (two virtual CPUs). Oracle’s licensing on OCI aligns with on-premises core factors: for Oracle Database Enterprise Edition, one license can cover 2 OCPUs (i.e., two cores, which is four vCPUs with hyperthreading)​.

This effectively gives the same two vCPU = 1 license ratio as other clouds, but Oracle expresses it in terms of OCPUs. In practice, the core counting in OCI is very license-friendly.

If you have 4 Processor licenses for Oracle DB Enterprise, you can run up to 8 OCPUs of that database on OCI under BYOL with no additional license purchase​.

For Standard Edition databases, OCI follows the standard policy of 4 vCPUs per license (one “socket”), with SE2 capped at 8 OCPUs (16 vCPUs) per instance, matching Oracle’s limits in authorized clouds​.

The key benefit is that OCI’s terminology might implicitly honor Oracle’s core factor (something not offered on AWS/Azure/GCP), meaning your licenses can go further on OCI.

From a SAM perspective, just remember that an OCI OCPU is roughly equivalent to a full core; Oracle requires the same number of licenses for a given core count as it would on-prem (Enterprise Edition), but compared to AWS/Azure, OCI doesn’t penalize you for the core factor since it’s their environment.

Oracle’s Authorized Cloud Policy:

Interestingly, OCI is not covered by third-party “Authorized Public Cloud Provider” policies like AWS, Azure, and GCP. That policy is designed for non-Oracle clouds. OCI, being Oracle’s service, inherently supports all Oracle software.

You don’t need to worry about Oracle not recognizing OCI as an approved environment – it’s Oracle’s home field. All Oracle programs are fully certified on OCI by default, and Oracle has no special vCPU formula beyond the OCPU usage described.

This means SAM managers don’t have to consult the authorized cloud policy document for OCI usage; Oracle treats OCI similarly to on-prem in terms of license acceptance, but with cloud-friendly terms built into OCI services.

License-Included Options:

OCI offers many Oracle services on a license-included (pay-as-you-go) basis besides BYOL. For instance, you can launch Oracle Autonomous Database or Oracle Database Cloud Service on OCI and either pay per use with the license included in the hourly rate or use BYOL for a lower rate.

Most Oracle PaaS offerings on OCI (database, WebLogic, etc.) have two pricing models: “License Included” (for those without existing licenses) and “BYOL” (for those providing their own licenses).

This gives flexibility. If you have spare licenses, BYOL reduces cloud costs; if not, you pay Oracle for the license as part of the cloud subscription.

Example: Oracle Autonomous Transaction Processing on OCI might cost X per OCPU per hour with license included, but only a fraction of X if you select BYOL and apply your existing license.

The Support Rewards program further incentivizes usage: OCI customers can get credits of up to 33% of their OCI spend for their on-prem Oracle support bills​. (For every $100 you spend on OCI, you could reduce your support fees by up to $33 – a significant saving for those with large support contracts.) This effectively discounts your support costs and is a unique benefit of using Oracle’s cloud.

Support Considerations:

Support in OCI is unified under Oracle. Suppose you’re running Oracle Database or middleware on OCI (whether BYOL or license-included). In that case, you will rely on Oracle’s support for the software issues and Oracle (OCI) support for infrastructure issues – but in practice, it’s the same Oracle support organization.

Because it’s Oracle’s platform, there’s no finger-pointing between vendor and provider; Oracle handles it end-to-end. Oracle’s support teams have full visibility into OCI environments, and Oracle certifies all Oracle software on OCI, so there’s never a question of “will Oracle support us on this platform?”.

Oracle fully supports and even encourages OCI use, and Oracle will honor BYOL licenses on OCI as long as you maintain your support contracts​. The Support Rewards mentioned above effectively reduce your support costs the more you use OCI.

For SAM managers, a key point is to keep your Oracle Support agreements active for any BYOL licenses you use in OCI – this ensures you remain eligible for updates and assistance.

OCI’s tooling can help track BYOL usage. Still, it’s wise to document which licenses have been deployed to OCI and ensure they’re not simultaneously counted for on-prem use (no “double dipping”).

High Availability & Disaster Recovery:

OCI, as Oracle’s cloud, supports all of Oracle’s HA/DR technologies – including Data Guard, Real Application Clusters (RAC), etc. However, licensing rules for HA/DR on OCI are essentially the same as on-prem. Suppose you set up an Oracle Database with a Data Guard standby in OCI under BYOL.

In that case, you need to license both the primary and the standby if the standby is running and applying logs (since that means Oracle software is installed and running on that server)​.

Oracle’s standard “10-day rule” for failovers (allowing a backup server to run Oracle for up to 10 days per year without a license in a true failover scenario) can apply in OCI as well​, but that only covers unexpected failovers to a secondary node, not a continuously active standby.

If you want a hot standby in OCI, treat it as needing a license. The exception would be if you keep the DR instance completely shut down until a disaster, you could use the 10-day rule during an emergency cutover.

For RAC, OCI offers Oracle RAC on virtual machines and Exadata Cloud Service; RAC must be licensed for all nodes/cores in the cluster just like on-prem (Oracle does not give a discount for using RAC on AWS/Azure at all – in fact, Oracle’s cloud policy document pointedly excludes RAC from authorized cloud usage, implicitly steering customers to OCI for RAC​).

On OCI, you can use RAC, but you have to license each OCPU in the cluster. The good news is OCI’s license-included database services (like Autonomous Data Guard or Autonomous Database with HA) bundle the licensing costs.

So if you use Oracle’s Autonomous Data Guard across regions, the cost you pay Oracle already covers the needed licenses for both primary and standby.

In summary, OCI doesn’t have special licensing exceptions for HA/DR beyond standard rules, but Oracle will manage HA features for you in some services and include those license costs. SAM managers should ensure any “standby” OCI instances using BYOL are either fully licensed or only powered on during actual disasters (with usage tracked to stay within the 10-day allowance).

Common Audit Risks & Pitfalls (OCI):

OCI is generally the least risky environment for Oracle licensing because it’s under Oracle’s umbrella.

Oracle is less likely to spring nasty surprises since it wants to promote OCI usage. Still, SAM managers should watch for a few pitfalls:

Assuming Oracle “auto-corrects” compliance:

While OCI services help and even give recommendations (e.g., warning you of how many licenses are required), Oracle will still hold the customer accountable for proper licensing.

An example of a real-world scenario is when Company A moved several Oracle databases to OCI using BYOL, thinking Oracle would manage compliance. In an audit, Oracle asked for proof of licenses for all those OCPUs.

Fortunately, Company A anticipated this and kept meticulous records, mapping cloud instances to license numbers. SAM managers should do the same—keep a record of which on-prem license (by CSI or contract) is allocated to which OCI resource. This makes audits routine rather than painful.

BYOL Compliance:

If you declare BYOL in OCI, make sure you own the equivalent licenses and that they’re current on support. Oracle can audit your OCI tenancy and expect proof of entitlements for BYOL usage. Don’t assume Oracle won’t check just because it’s their cloud – a lack of internal tracking could lead to non-compliance if audited.

Dual Use of Licenses:

A common mistake is using the same Oracle license entitlement for an OCI and on-prem deployment simultaneously. One license can’t cover two locations unless you’ve purchased separate licenses. When workloads move to OCI under BYOL, you remove or retire the on-prem installations (or have enough licenses to cover both until decommissioned).

Ignoring License Limits:

Even in OCI, Oracle’s product limits (like Standard Edition CPU limits) apply. For instance, deploying an SE2 database on an OCI VM shape with more than 8 OCPUs would violate the license terms (OCI won’t necessarily stop you from doing it if you use a manual setup on compute VMs). Always match your instance sizes to what your edition allows (OCI documentation can guide this, but it’s ultimately on the user to stay compliant).

Amazon Web Services (AWS) – Flexible but Watch the Rules

Bring Your Own License (BYOL):

AWS is a popular destination for Oracle workloads that customers want to lift and shift from data centers. AWS is an Authorized Cloud Environment for Oracle, which means Oracle consents to customers using their Oracle licenses on AWS, provided they follow Oracle’s cloud licensing policy​.

BYOL on AWS typically means running Oracle software on Amazon EC2 instances (virtual machines) or Amazon’s managed database service, RDS, in BYOL mode. On EC2 (Infrastructure-as-a-Service), you can launch a VM with your choice of OS and install Oracle Database, Oracle Middleware (WebLogic, etc.), or other Oracle software. It’s your responsibility to license it correctly.

Amazon even provides Oracle-certified machine images (AMIs) for convenience (for example, an AMI with Oracle Database pre-installed). Still, these AMIs are almost always BYOL – you must attach your license.

On Amazon RDS for Oracle, BYOL is one of the licensing options: if you want to run Oracle Enterprise Edition or already own Oracle Standard Edition licenses, you can spin up an RDS instance and indicate that you are bringing your licenses.

AWS then manages the database service (patching, backups, etc.), but you remain responsible for having sufficient licenses.

In summary, AWS fully supports BYOL for Oracle,, and it’s commonly used, but the customer is responsible for proving they have enough licenses. All Oracle programs (database, WebLogic, etc.) you run on AWS EC2 require BYOL since AWS doesn’t sell Oracle licenses for EC2 usage.

vCPU/Core Licensing Methodology:

Oracle’s cloud policy outlines how to count AWS virtual CPUs (vCPUs) against Oracle licenses, which is critical for SAM. If hyperthreading is enabled, two vCPUs are counted as one Oracle Processor license; if it is disabled, one vCPU is counted as one Processor license​.

This effectively means on AWS, normally two vCPUs = 1 license (because AWS EC2 instances by default have hyperthreading on, meaning each vCPU is a thread of a core, so two threads = one core = one Oracle license)​.

For example, an AWS EC2 instance with eight vCPUs (such as four cores with two threads each) would require 4 Oracle processor licenses for Enterprise Edition DB​​. If you turn off hyperthreading (possible on some AWS instance types or using “dedicated cores”), then each vCPU is a full core thread, and Oracle wants a license per vCPU​.

This is a common pitfall: if an admin uses a “single-threaded” instance type by mistake, your Oracle license requirement doubles on that instance. SAM managers should coordinate with cloud architects to ensure hyperthreading remains enabled (which is by default on standard instance families) to maximize license efficiency.

Also note that Oracle’s usual on-prem Core Factor table does not apply in AWS​ – no matter what CPU model (Intel/AMD) the cloud uses, you ignore core factors and use the vCPU counting formula only.

For Standard Edition databases on AWS, Oracle treats every four vCPUs as equivalent to a processor license (socket)​. Smaller instances up to 4 vCPUs count as one socket; if you have more than four vCPUs, you round up to the next group of 4 for licensing​. Additionally, Standard Edition 2 on AWS is limited to instances with a maximum of 8 vCPUs (Standard Edition “SE1” or older SE allowed up to 8)​.

This means you cannot legally run Oracle SE2 on, say, a 16 vCPU EC2 instance by just stacking licenses – Oracle’s policy forbids it beyond eight vCPUs for SE2. In practice, to use SE2 on AWS, keep the instance at eight vCPUs or fewer.

If more performance is needed, you’d have to use Enterprise Edition (with appropriate licenses) or scale out multiple SE2 instances (each up to 8 vCPUs) with application-level sharding.

Use of Oracle’s Authorized Cloud Policy:

AWS was the first cloud acknowledged by Oracle’s policy (along with Azure). The Oracle cloud policy document explicitly names AWS as an authorized provider and spells out the rules (vCPU counting, etc.)​.

It’s important to note that this document is non-contractual guidance (Oracle says it’s educational only​), but Oracle adheres to it during audits​.

SAM managers should use this policy as the rulebook for licensing Oracle on AWS. Key points from the policy for AWS: two vCPUs = one license (with hyperthreading on)​, Standard Edition core counts as discussed, and the policy excludes certain things like Oracle RAC on AWS (meaning Oracle does not permit you to use the cloud formula for RAC – essentially disallowing RAC usage unless you fully license by physical cores, which is impossible for customers to count in AWS, effectively a prohibition).

Common advice is to document that you followed Oracle’s policy in good faith. In an audit, having AWS instance reports showing vCPUs and your calculation of licenses can demonstrate compliance. AWS can also provide resource inventory and even has an AWS License Manager service, where you can track Oracle license usage, which SAM teams might leverage.

To stay safe, always assume Oracle will enforce the letter of the policy. For instance, if a new AWS instance type has some different thread configuration, wait for Oracle to clarify or stick to known instance configurations.

As of 2024, Oracle updated the policy to explicitly include GCP, but the rules for AWS remained the same​. Keep an eye on any Oracle announcements or independent licensing experts’ analysis (Oracle often doesn’t shout about policy changes beyond updating the PDF on their site).

License-Included Options:

AWS offers limited Oracle “license-included” offerings, mainly through Amazon RDS for Oracle in specific editions. Amazon RDS (Relational Database Service) for Oracle has two license models: “License Included” and “BYOL”. However, the License Included option on RDS is only available for Oracle Database Standard Edition Two (SE2) (and previously Standard Edition One) and only on certain instance sizes that align with SE2 limits.

In license-included RDS, the Oracle Database license (and support) cost is baked into the hourly pricing you pay AWS. This is convenient if you don’t have existing licenses or don’t want to worry about compliance for that instance – essentially, it’s like renting the Oracle license from AWS.

However, it’s important to note that AWS’s license covers only the database license for SE2 and its basic features. If you need Enterprise Edition or any options (like Partitioning, Advanced Security, etc.), you cannot use license-included RDS; you must go BYOL. AWS does not sell Oracle Enterprise Edition licenses by the hour – Enterprise Edition on RDS is BYOL only.

Similarly, if you want to run Oracle WebLogic or other Oracle software on AWS, there’s no license-included AWS service; you’d be using EC2 with BYOL. So, the license-included choices on AWS are narrow.

One more offering: AWS has a service called AWS Oracle Database Service on AWS (sometimes simply referred to as running Oracle on AWS Outposts, etc.) – but to avoid confusion, AWS doesn’t have an Oracle-managed Exadata service.

AWS’s main “Oracle-managed” aspect is RDS for Oracle, which is managed by AWS but not by Oracle. AWS also provides Oracle Linux as an OS option, but Oracle Linux (the operating system) is free to use on AWS; support for it can be bought from Oracle or obtained via AWS support if AWS covers it.

This is separate from Oracle software licensing but relevant if you prefer to stick with Oracle’s OS.

Support Considerations:

When running Oracle on AWS under BYOL, support is a shared responsibility: you (the customer) must have an active Oracle support agreement for the software, and AWS will support the cloud infrastructure.

For example, suppose an Oracle database on EC2 has an issue. In that case, you might open a case with Oracle Support for database software help (using your CSI number from your support contract) and/or a case with AWS if it seems like a VM or storage issue. Oracle Support has stated they will support customers on AWS/Azure if you have a valid license and support contract – they won’t refuse service just because you’re on AWS​.

Historically, Oracle did not officially certify all its software on AWS, but they have not made support conditional on running on Oracle hardware.

They may ask you to reproduce an issue on a certified platform if it’s obscure, but generally, Oracle Support treats AWS like any other environment now, given its widespread use. If you use RDS with a license included, your support goes through AWS support (and AWS has a back-to-back support arrangement with Oracle as needed).

In practical terms, AWS Premium Support will handle your case and involve Oracle if it’s a deep database issue. Still, as the customer, you don’t directly interface with Oracle for support in that scenario.

For SAM managers, keep track of support costs: license-included RDS pricing already includes Oracle Support (as part of the fee), whereas BYOL means paying Oracle support separately.

One potential support pitfall is Oracle Java on AWS: Oracle now requires licenses for certain Java versions. If running those on AWS, ensure those are licensed too (though outside database scope, SAM should note all Oracle products).

Also, be mindful that Oracle’s support policies say they could decline support if you run Oracle in an “unauthorized” cloud. AWS is authorized, so that’s fine.

But if someone tried to run Oracle on an AWS service that isn’t covered by policy (for example, an AWS partner’s virtualization not covered), Oracle could raise an eyebrow. Sticking to EC2 or RDS (explicitly named in Oracle’s policy​oracle.com) keeps you safe.

High Availability & Disaster Recovery:

AWS offers various ways to achieve HA/DR for Oracle, but each has licensing implications:

• Multi-AZ RDS for Oracle: If you enable Multi-AZ deployment for an RDS Oracle instance, AWS will create a standby copy of your database in a different availability zone for failover. When using RDS License Included (SE2), AWS licenses both the primary and standby – the cost is built in (you pay extra for Multi-AZ, and part of that covers the standby’s Oracle license). If using RDS BYOL, you are expected to have licenses for both the primary and the standby instances. Even though the standby is passive, it is continuously running Oracle (applying logs), which, under Oracle’s contract, means it must be licensed​. Oracle’s 10-day failover rule doesn’t apply to RDS’s always-on standby because that standby is not just spun up during failover – it’s up all the time. So, for BYOL on Multi-AZ, ensure you have double the licenses (one set for primary, one for standby) or opt for license-included if you don’t have enough licenses; AWS will handle it in that case.
• Data Guard / DIY HA on EC2: If you run Oracle on EC2 VMs, you might set up your own Data Guard standby or a cluster. The same principle applies to on-premises: an active Data Guard standby (in continuous recovery mode) requires a license on AWS​. You could alternatively keep a cold backup and only start it for tests or failovers. Oracle’s backup testing rule allows testing a backup on an unlicensed server up to 4 times a year for 2 days each​, and the 10-day failover rule allows a temporary use of an unlicensed server for up to 10 days in a year for disaster recovery​ (with some contract caveats). If your DR strategy is to keep an instance powered off and only launch it during an outage, you can potentially avoid licensing it permanently, as long as it doesn’t exceed those limits. However, any regularly running standby must be licensed even if not open to users.
• Oracle RAC on AWS: Running RAC on AWS is technically challenging and not officially supported by AWS or Oracle’s cloud policy. Oracle’s policy document doesn’t allow Oracle RAC to be used under the standard cloud vCPU licensing formula​. This effectively dissuades RAC on AWS. Some advanced users have attempted RAC on AWS bare-metal instances or specialized setups, but it almost certainly violates licensing unless explicitly agreed upon with Oracle. The safer approach is to avoid RAC on AWS; if you need RAC-level HA, consider Oracle’s own Exadata Cloud or OCI interconnected with AWS (Oracle and AWS do not have a native partnership for this as Oracle does with Azure and GCP).
• DR across Regions/Clouds: If you have, say, your primary Oracle DB on AWS in one region and want a DR copy on AWS in another region, treat it the same as above (both need licenses if running). If your DR is on OCI (some companies do primary on AWS, DR on OCI, or vice versa to leverage OCI’s support benefits), the licensing rules still apply per environment. Still, Oracle might view the OCI side more leniently. There’s no automatic free pass for DR; it depends on whether the Oracle binaries are installed and running.

Common Audit Risks & Pitfalls (AWS):

SAM managers overseeing Oracle on AWS should be vigilant about:

• Miscounting licenses due to vCPU misunderstandings: Ensure the team knows the two vCPUs = 1 license rule. A common mistake is to assume one vCPU equals one license, which would cause over-licensing (wasting money), or if hyperthreading is off, to assume the 2-for-1 still applies (which would under-license and violate compliance). Keep a close eye on any unusual EC2 instance types (like T-series burstable or specialty HPC instances) – confirm their hyperthreading status and vCPU count. Use AWS Config or scripts to detect if any instance has hyperthreading disabled so you can adjust licensing.
• Forgetting about inactive but installed software: Oracle licensing requires a license for any server on which Oracle software is installed and/or running​. Spinning up VMs from templates that include Oracle software is easy in cloud environments. If someone in DevOps creates an AMI with Oracle installed and launches test instances, those instances technically need to be licensed if they’re running Oracle binaries, even if they’re not actively used for long. One mitigation is to ensure that any Oracle-installed AMIs are only used when you intend to license and use Oracle. Terminate any orphaned instances with Oracle installations or remove Oracle software from instances that don’t need it. Oracle auditors can request evidence of all installations, not just production ones.
• Unlicensed features or options usage: AWS won’t prevent you from using Oracle options or packs (like Oracle Advanced Compression, Partitioning, etc.) if you installed Enterprise Edition – it’s up to you to ensure you’re licensed for them. Oracle LMS (License Management Services) scripts can detect option usage. Make sure your DBAs know how to disable or avoid features that aren’t licensed. For example, using Oracle Enterprise’s multi-threaded parallel query or Spatial features would require additional licenses if those options aren’t covered.
• AWS snapshots and clones: Taking an EC2 AMI snapshot of a configured Oracle server and sharing it across accounts could spread Oracle software beyond its intended scope. Therefore, it is important to maintain control over where Oracle-installed images are used.
• ULA and Cloud Usage: If your organization operates under an Oracle Unlimited License Agreement (ULA), be cautious with AWS. Oracle’s policy explicitly says ULA-acquired licenses can be used in AWS/Azure (authorized clouds) but cannot be counted toward certification at ULA’s end​. This means if you are trying to maximize usage to certify a higher number of licenses, any deployment on AWS won’t count in Oracle’s eyes. An unwary SAM manager might think, “We deployed heavily on AWS, so now we use many licenses, good for ULA cert” – but Oracle will exclude those. This has caught some companies off guard during ULA certification. The workaround is to negotiate cloud inclusion in the ULA or bring those workloads on-prem (or to OCI) before certification if you want them counted.
• Audit preparedness: Oracle can audit your AWS environment just as they do on-prem. They may ask for AWS usage reports, instance configurations, etc. Use AWS tagging to label instances that run Oracle, and keep a centralized spreadsheet of all Oracle deployments on AWS, with details like instance type, vCPUs, Oracle edition, options enabled, and the corresponding license from your inventory. Producing this mapping (and showing it aligns with Oracle’s policy counts) will make an audit go much smoother and demonstrate proactiveness.

Microsoft Azure – BYOL Only, with a Twist of OCI Integration

Bring Your Own License (BYOL): Microsoft Azure is also an Authorized Cloud Environment for Oracle licensing, similar to AWS​. Historically, if a company wanted to run Oracle Database or other Oracle software on Azure VMs, they had to bring their licenses since Azure did not offer any Oracle license-included service.

Azure provides pre-configured Oracle Database VM images in the Azure Marketplace (for example, an image with Oracle Database 19c on Oracle Linux). However, those images are BYOL—you must have a license to use them.

Essentially, running Oracle on an Azure VM is like running it on your virtualization on-premises, license-wise. All Oracle programs are supported on Azure BYOL (Oracle has recognized Azure in its policy for years), so you can migrate an Oracle database workload to an Azure VM and license it by vCPUs as per Oracle’s rules.

One nuance: Microsoft and Oracle recently formed a cloud partnership, resulting in the Oracle Database Service for Azure (sometimes called Oracle Database@Azure).

This service allows Azure customers to provision Oracle databases (including Exadata) hosted on Oracle Cloud Infrastructure but tightly integrated with Azure for a seamless experience. In that scenario, you can use BYOL or purchase the database service with a license included through Oracle – more on that below.

But if we’re talking about Azure-native deployment (e.g., an Azure VM running Oracle DB), BYOL is the way.

Azure does not restrict the Oracle editions or products you can run – you can install Oracle Database Standard Edition, Enterprise Edition, WebLogic Server, etc., as long as you have the licenses.

Oracle Licensing on AWS, Azure, and Google Cloud

vCPU/Core Licensing Methodology:

Oracle’s cloud licensing policy applies to Azure almost identically to AWS. Rule: 2 Azure vCPUs are 1 Oracle Processor license (with hyperthreading on), and one vCPU is one license if hyperthreading is off​. Azure VMs use hyperthreading by default for most instance types (Azure refers to vCPUs similarly to threads).

So, an 8 vCPU Azure VM requires 4 Oracle licenses for Enterprise Edition—the same as AWS, same math​. Azure also follows the “4 vCPU = 1 socket” rule for Standard Edition licensing​. Instances up to 4 vCPUs are one socket (one license for SE2), and > four vCPUs means multiple licenses (rounded up in chunks of 4). Standard Edition on Azure limits are 16 vCPUs max for Standard Edition (SE) and eight vCPUs max for Standard Edition 2 (SE2)​.

There is nothing fundamentally different in counting licenses on Azure versus AWS – Oracle made it consistent across these public clouds.

One thing to note: Azure’s VM sizing sometimes offers options like “without hyperthreading” for certain HPC VM types. If you use those for Oracle, remember to count the shifts to 1 vCPU = 1 license.

But for general-purpose or memory-optimized VMs (commonly used for databases), you’ll be in the normal 2-for-1 scenario. Azure also has physically isolated hardware options (like Azure Dedicated Host), which don’t change the Oracle metric. However, if someone pins Oracle VMs to specific cores and disables HT, the same caution from AWS applies.

In summary, SAM managers can apply the same calculation method on Azure as on AWS, and it aligns with Oracle’s policy (no core factor, treat threads as half-core licenses in pairs). It’s helpful to get a list of all Azure VMs running Oracle and verify their vCPU count and whether they’re HT-enabled. Tools in Azure (like Azure Monitor or tags) can help identify those instances.

Use of Oracle’s Authorized Cloud Policy:

Oracle’s policy document explicitly includes Azure alongside AWS​, so all the rules discussed are officially sanctioned. Oracle even includes examples in the policy, like counting licenses for an Azure instance with certain vCPUs​.

Azure has long been an authorized environment, which means Oracle customers can use it with some peace of mind.

Just like with AWS, Oracle expects you to follow that policy. Microsoft and Oracle’s partnership (since around 2019) also means Oracle knows many customers run Oracle on Azure and has provided guidance accordingly.

For a SAM manager, it is wise to keep a copy of Oracle’s “Licensing Oracle Software in Cloud Computing Environment” policy on hand and ensure the team references it when planning deployments.

If Oracle conducts an audit, showing that you adhered to their official policy for Azure should protect you from any compliance findings (assuming your license counts are correct).

Another policy-related point is that if you have an Unlimited License Agreement (ULA) with Oracle, the same warning applies to AWS – Oracle doesn’t let you count Azure deployments towards ULA certification​.

I mention it again because it’s a common gotcha—running up usage in Azure, thinking it will translate into perpetual rights after the ULA might fail. Always check your ULA terms about cloud usage; Oracle sometimes requires ULAs to be amended for public cloud use (except OCI) if you want to count that usage at the ULA end.

License-Included Options:

Unlike OCI or AWS, historically, Microsoft Azure did not offer a license-included Oracle database service. However, in 2022, Oracle and Microsoft announced the Oracle Database Service for Azure (ODSA), essentially an Oracle-managed database running on Oracle Cloud Infrastructure but accessible seamlessly from Azure.

Azure customers can create Oracle databases (including Exadata ExaCC instances) that appear as Azure resources through this service. The important part licensing-wise: Oracle Database@Azure (another term for it) allows customers to either BYOL or use a “license included” model when provisioning the database​.

If a customer chooses license-included, they don’t need to own an Oracle license; the cost is part of the service (billed via Oracle, but the purchase is made through the Azure marketplace or an interconnect billing).

If they choose BYOL, they apply their existing licenses and pay a lower rate for the service. It’s OCI’s database offerings that are made available in Azure’s portal. This is a special case and not an Azure-native capability; it’s enabled by the Oracle-Microsoft cloud interconnect and partnership.

From the SAM perspective, if your organization is using Oracle Database Service for Azure in the license-included mode, you should treat it as if you’ve subscribed to an Oracle Cloud service – Oracle will handle the licensing on their end (and you’ll pay for it in your service fees).

There’s no need to count vCPUs for those instances because you’re paying by the service metrics (like OCPUs used, etc., which internally include the license cost).

But be aware of which model you chose; it’s easy for an operations team to spin up an Oracle DB via Azure’s interface without communicating whether they clicked “BYOL” or “included.”

As a SAM manager, get visibility into any Oracle Database@Azure usage, and ensure you either have licenses allocated (if BYOL) or budget for the service cost (if included).

Outside of this specific multicloud service, Azure still does not offer a home-grown Oracle-managed database service. So if you’re not using the Oracle Database Service for Azure, all your Oracle on Azure is BYOL.

There’s no equivalent of AWS’s RDS in Azure for Oracle (Azure chose to partner with Oracle rather than do its own managed Oracle DB).

Azure has been a popular hosting platform for Oracle applications (like E-Business Suite, PeopleSoft, etc.), but again, those are BYOL; you bring the Oracle app and database licenses to Azure VMs.

In short, no native license is included for Oracle on Azure IaaS. Still, a powerful cross-cloud service exists to get an Oracle-managed DB with a license included if needed.

Support Considerations:

Running Oracle in Azure via BYOL means you rely on Oracle Support for the software and Microsoft support for the Azure infrastructure (VM, storage, OS if Windows, etc.). This is analogous to AWS.

Oracle Support will accept issues from customers on Azure since Azure is an authorized environment – you just need to provide your support identifier as usual. Microsoft won’t troubleshoot Oracle software issues (not their domain), but they will handle any Azure platform issues (like VM not starting, disk issues, and networking).

Suppose you use the Oracle Database Service for Azure (the Oracle-managed option). In that case, support is a bit more unified: Oracle would support the database itself (because it’s an OCI service), and Azure support would still handle any connectivity or Azure-specific issues. However, given the integration, customers likely have a streamlined way to open tickets. For SAM managers, ensure that you maintain Oracle support for any licenses used on Azure.

Suppose your company decided to drop Oracle support on some licenses (to save cost) and still deploy them to Azure. In that case, you’d be running unsupported, which is risky and could violate terms (if you’re using software versions released after support has lapsed). Another consideration: Interconnect Support – Oracle and Microsoft have a cloud interconnect such that an application in Azure can communicate with a database in OCI with low latency.

If your architecture uses this (say an app server in Azure connecting to Oracle DB in OCI), then you have a split environment: Oracle will support the DB side, and Microsoft the app side. This is fine; just plan for the coordination. From an audit standpoint, support doesn’t directly affect license compliance, except that having support proves your right to use the latest versions and patches.

One might worry, “Will Oracle support my Azure deployment or use it as an excuse in an audit?” As long as you’re properly licensed, Oracle treats Azure deployments like on-prem in audits​.

Oracle’s LMS will ask for evidence of licenses and possibly deployment data (which you gather from Azure), but they won’t say, “Because it’s on Azure, it’s invalid.” The era of Oracle implying “only Oracle Cloud is allowed” is over now that the policy is clear for Azure/GCP.

High Availability & Disaster Recovery:

Azure has many infrastructure features for HA/DR (like placing VMs in different availability zones or using Azure Site Recovery to replicate VMs).

Still, Oracle-specific HA setups in Azure will mirror what you’d do on-prem or on AWS:

• Failover Clustering: You could run Oracle RAC on Azure VMs, but this is not officially certified by Oracle on Azure either (similar to AWS, Oracle would rather you not run RAC in a non-OCI cloud under the cloud policy). It’s technically possible on Windows or Oracle Linux clusters with shared storage, but licensing becomes tricky, and Oracle’s stance is not to recognize cloud RAC under the policy. Most Azure Oracle users stick to standalone instances or Data Guard for HA.
• Azure Availability Sets/Zones: If you run multiple Oracle DB VMs behind a virtual IP (not a true RAC but, say, using Oracle Grid Infrastructure for failover), you’d need to license both nodes if they are running Oracle software. Suppose one is completely passive (Oracle is not installed or has not started unless there is a failover). In that case, you might attempt to use the 10-day rule, but often, to have a quick failover, Oracle software is pre-installed and possibly running at some capacity (even if idle). The same rule applies to any server with Oracle running counts. So many simply license both nodes and have a warm standby on Azure.
• Data Guard on Azure: You can set up Oracle Data Guard with an Azure VM in, say, Region A as primary and another in Region B as standby. The standby would require a license because it continuously applies changes (i.e., Oracle instance is running)​. You might save costs by sizing the standby smaller if it’s just for DR (though that can impact failover capacity). Oracle’s contract doesn’t care if it’s smaller – if it’s running, it needs a license, albeit if it has fewer cores, you could license fewer. Still, Data Guard typically expects similar capacity for failover.
• Backups and Recovery: Azure allows you to automate VM image backups or use Azure Backup for databases. Restoring an Oracle backup to an unlicensed VM for recovery testing would fall under the “4 times a year for 2 days” backup test clause​. So you could, for testing purposes, restore an Oracle DB to a new VM to test DR without licensing that test VM, as long as you keep to Oracle’s testing clause limits (essentially 8 days a year, split into four windows). If you use this exception, keep a paper trail of those tests in case Oracle asks.

Common Audit Risks & Pitfalls (Azure): Many are similar to AWS, but a few Azure-specific things to watch:

• Assuming Azure covers Oracle licensing: We’ve encountered scenarios where a project manager thought deploying an Oracle image from the Azure Marketplace meant that Microsoft somehow licensed it. Not true – those images are BYOL. Always double-check that the team isn’t under the false impression that “because Microsoft provides the image, we’re licensed”. The cost of the Azure VM does not include an Oracle license (unlike SQL Server images, where Azure does allow license-included pricing – but that’s Microsoft’s product). With Oracle on Azure, BYOL is the only way unless the cross-cloud service is used.
• Sprawl of VMs: Azure’s ease of deployment can lead to VM sprawl. An engineer can quickly spin up an Oracle VM for a test and forget to delete it. Each of those needs a license if it is running. It’s important to use Azure policies or resource graphs to find all VMs with Oracle software. Tag them and enforce lifecycle management so they don’t linger unaccounted for. Oracle auditors often ask for installation data (they might ask: give us a list of all VMs or servers with Oracle installed). Be prepared to run a script or query to get this from Azure anytime.
• Mixing up service types: If your company adopts Oracle Database Service for Azure, ensure the accounting for those instances is done separately from pure Azure VMs. The Oracle-managed service will appear in the Azure Portal but runs on OCI. Oracle’s audit might separately check your OCI tenancy for those (since that’s where they live), while Microsoft won’t have insight into Oracle licenses. Delineate which Oracle databases are running in which environment. The pitfall would be double-counting or missing them entirely in reports. For example, if you run an Oracle DB via the service and choose BYOL, you must allocate a license from your pool to it, even though it’s created through the Azure interface. Don’t assume someone else is handling that.
• Under-licensing Standard Edition due to VM size: As mentioned, Standard Edition has strict vCPU limits on Azure. If an admin up-sizes a VM beyond 8 vCPUs but still uses SE2, that deployment violates licensing (and Oracle could issue a finding). Implement guardrails: if you use SE2, use Azure Policy to restrict VM sizes in that resource group to those with eight or fewer vCPUs. Or at least monitor via Azure Advisor if any Oracle SE VM is scaled beyond eight vCPUs and flag it.
• Failing to track Unlimited Agreement restrictions: If you have a legacy Oracle contract that restricts usage to specific named platforms, ensure that Azure is allowed. Most licenses don’t have such restrictions (usually just by product and metric), but occasionally, older or enterprise agreements might have language restricting use to “Oracle hardware” or specific processors. If so, you’d need an amendment to run on Azure. Oracle’s cloud policy isn’t legal, so your contract terms still govern. It’s rare, but double-check any weird clauses.
• Not leveraging OCI interconnect when it could save money: This is more of an optimization pitfall: if you need high-performance Oracle DB and you’re in Azure, consider using the Oracle Database Service (OCI) rather than over-provisioning on Azure VMs. It might be cheaper and give you license-included options. From a SAM view, sometimes paying as-a-service is preferable to using many of your licenses, especially if those licenses can be used elsewhere or are limited. Always evaluate whether BYOL or a service subscription is more cost-effective and compliant for each scenario.

Google Cloud Platform (GCP) – Emerging Oracle Option with Bare Metal

Google Cloud Platform (GCP) has also been recognized by Oracle as an authorized public cloud vendor, providing additional flexibility for organizations that prefer GCP’s infrastructure.

• Google Cloud Virtual Instances: Oracle workloads are licensed on GCP virtual instances based on the number of vCPUs. GCP uses the same licensing model as other public cloud providers, where two vCPUs are equivalent to one Oracle Processor license when multithreading is enabled.
• Google Bare Metal Solutions (BYOL): GCP offers Bare Metal Solutions, which allow customers to run Oracle databases on dedicated physical hardware in a BYOL model. This approach is similar to running Oracle on-premises but offers more control and performance.
• Oracle Database Cloud Services: GCP also provides access to Oracle Database Cloud Services, where customers can use their Google Cloud Commitments to pay for Oracle services. This makes GCP an attractive option for cloud-native Oracle services without needing standalone license management.

Bring Your Own License (BYOL):

Until recently, Google Cloud was a gray area for Oracle licensing. Oracle did not list GCP as an authorized cloud in its formal policy until 2024. This led to uncertainty, but many customers still ran Oracle on GCP under BYOL, applying the same rules as AWS/Azure.

As of mid-2024, Oracle officially added GCP to its authorized cloud provider list​, confirming that BYOL is fully supported on GCP with the same vCPU counting methodology. So, GCP is on equal footing with AWS/Azure in Oracle’s eyes.

BYOL on Google Cloud means you can launch Google Compute Engine (GCE) virtual machines or use Google’s Bare Metal Solution to run Oracle software, and you must allocate your licenses for those installations. For instance, Google provides common OS images (you might install Oracle on a Linux VM).

They also have Oracle DB images in their marketplace, but like Azure’s, those are BYOL. In summary, GCP accepts your Oracle licenses; there’s no magic licensing from Google’s side – you manage it as if it were another data center.

One unique offering is Google Cloud’s Bare Metal Solution: Google will provision a physical server (with, say, Oracle Linux or RHEL) in a GCP region for you, often used specifically for Oracle workloads that require dedicated hardware.

This is still BYOL: You’re renting hardware from Google, but must bring Oracle licenses, similar to on-prem. Think of Bare Metal Solution as an extension of your on-prem environment into Google’s network – licensing is by physical cores (and since it’s dedicated hardware, hyperthreading vs not doesn’t change Oracle’s view that you count the actual cores).

vCPU/Core Licensing Methodology:

With GCP now included in Oracle’s cloud policy, the rules are the same: 2 vCPUs = 1 Oracle Processor license if hyperthreading is enabled; 1 vCPU = 1 license if hyperthreading is disabled​.

Google Cloud’s standard VM instances (GCE) use hyperthreading by default on Intel and AMD instances, so again, two vCPUs count as one license​.

For example, a GCP VM with 16 vCPUs (on a machine type with eight cores/16 threads) needs 8 Oracle licenses for Enterprise Edition – matching AWS/Azure calculations.

Suppose you choose a GCP instance type with hyperthreading off (some GCP machine types allow you to pick several cores and threads per core). In that case, you’d count 1:1. GCP’s documentation aligns with Oracle’s policy, and Oracle provided additional examples for GCP in the latest update to clarify it​.

For Standard Edition on GCP: The policy matches the others – 4 vCPUs per license (socket), up to 16 vCPUs max for Standard Edition, or eight vCPUs max for SE2​oracle.com. So you cannot exceed those with SE on GCP either.

One thing to note with GCP: Their Bare Metal Solution servers are physical machines (say, 32-core servers). Oracle licensing on those is traditional (they are not “vCPUs” but real CPUs). You’d apply Oracle’s core factor if it were on-prem, but since Oracle’s cloud policy disallows core factor in authorized clouds, you might need to license all cores 1:1 unless Oracle gives an exception.

However, Bare Metal Solution might be considered an extension of your on-prem environment (the Oracle policy is ambiguous because Bare Metal isn’t a “virtual” environment).

In practice, many treat Bare Metal like on-prem and use core factors if applicable. However, some advisory firms suggest treating it as cloud and not applying core factor discounts to be safe.

If Bare Metal Solution is being used heavily, getting clarification from Oracle or a licensing expert is wise. For typical GCP VMs, stick to the 2-for-1 rule. As a SAM manager, ensure the GCP team tags any project or VM running Oracle so you can track vCPU counts and ensure compliance.

GCP has its own Rightsize recommendations, but note that rightsizing a VM up or down might change vCPU count and thus license needs, so coordinate changes with license availability.

Use of Oracle’s Authorized Cloud Policy:

With GCP explicitly under the policy, Oracle customers can breathe easier using Google Cloud. Before this, you applied the AWS/Azure rules by analogy and hoped Oracle would accept it. Now it’s official.

Oracle’s June 2024 policy update “made it explicit that Google Cloud Platform (GCP) is covered”​. Still, remember this policy is not a contract, and Oracle can change it. For now, though, you should follow it exactly for GCP. That means if Oracle audits you, you justify your license counts on GCP using the same documentation as you would for AWS/Azure.

Oracle support should also treat GCP deployments as legitimate, not “unauthorized.” One caveat: Oracle’s policy (as of 2024) covers the main GCP offerings (Compute Engine VMs), but if you try to use something like Google Kubernetes Engine (GKE) with Oracle images, it’s less clear – likely you’d count the underlying nodes’ vCPUs the same way. The policy doesn’t mention containers separately.

The safest route is to use dedicated VMs or bare metal for Oracle, so counting is straightforward. If using GCP’s managed instance groups or similar auto-scaling, be careful: if instances scale out, each needs licensing. Oracle licenses are not elastic – you must license peak usage.

A potential risk is if auto-scaling kicks in and you temporarily run more Oracle instances than you have licenses for. SAM managers should prohibit auto-scaling for Oracle workloads or cap it to licensed capacity. Oracle’s policy doesn’t explicitly discuss dynamic scaling, but compliance would require licensing the maximum concurrently deployed vCPUs.

License-Included Options:

Google Cloud did not natively offer Oracle database as a managed service (there’s no Google “RDS” equivalent for Oracle). However, in September 2023, Oracle and Google announced a partnership similar to Oracle’s Azure partnership.

This “Oracle Database Service for Google Cloud” allows Google Cloud customers to provision Oracle Exadata Database services inside Google Cloud data centers, with simplified purchasing via Google Cloud Marketplace​.

Oracle deploys its Exadata-based managed database service on dedicated infrastructure co-located with GCP. You can buy it through the GCP marketplace and have the usage count toward your Google Cloud spending commitments.

In this arrangement, you can choose license-included or BYOL for the database service, just like on OCI or Azure.

So, if you go with Oracle Database@Google Cloud (license-included), you don’t need to provide Oracle licenses; Oracle will provide them as part of the hourly rate. If you go BYOL on that service, you apply your existing licenses to it (again at a reduced cost).

The upside of this service is that it’s truly Oracle-managed (you’re essentially using OCI tech through Google’s portal). The downside is that it’s not a native GCP product focused on Exadata/high-end Oracle DB needs, which might be overkill for smaller workloads.

For SAM, if your organization starts using Oracle via the Google Cloud Marketplace service, track those as subscriptions (not traditional licenses).

You’ll be paying for them as an OPEX cloud service, and compliance is simply being subscribed – no need to count vCPUs for those instances. But outside of that new service, any Oracle on GCP is BYOL.

GCP’s Bare Metal Solution also provides infrastructure. If you wanted, you could negotiate with Oracle to include licenses in a Bare Metal deal, but typically, it’s BYOL. Google doesn’t bundle Oracle licenses with Bare Metal by default; they just provide hardware and some management.

Support Considerations:

Oracle support on GCP BYOL follows the familiar pattern: Oracle handles software support, and Google handles infrastructure.

Google’s Bare Metal Solution has a hardware and environment support component, but you still need Oracle Support for the software. One historical wrinkle is that Oracle, before GCP was authorized, could have argued that GCP was “unsupported.” Now that it’s authorized, Oracle Support will take GCP issues like AWS/Azure.

You can point to Oracle’s approved GCP policy if any Oracle support rep is unsure. Also, the new Oracle DB Service on Google Cloud means Oracle is directly involved in those deployments, so Oracle Support covers those fully (and Google likely assists with any cloud networking issues).

It’s worth noting that Google Cloud support teams may not have deep Oracle expertise since Google didn’t run a managed Oracle service of their own – they’ll typically defer to your Oracle support for database problems.

If you have mission-critical Oracle on GCP, you’ll want to ensure you have Oracle’s CSI and maybe even advanced Oracle support tiers active. Another support consideration is patching and updates. On AWS/Azure, you patch your Oracle software (unless using RDS). The same is true on GCP—you are responsible for downloading and applying Oracle patches (with a support contract in place to have access to those).

Google’s Bare Metal team won’t patch your Oracle DB, so include that in your operational process. From a SAM view, ensure that using Oracle on GCP doesn’t lead to any lapse in patch updates (a lack of patching can be a security and compliance risk if you fall out of allowed versions).

License-wise, support status doesn’t change license requirements, but lack of support might mean you’re not entitled to certain versions or tech.

High Availability & Disaster Recovery:

On GCP, you can achieve HA/DR through their infrastructure or via Oracle’s tech:

• Google Cloud regions/zones: You might run a primary Oracle VM in one zone and a standby in another zone, similar to multi-AZ on AWS. Google doesn’t have an RDS-like service to automate that, so you’d manually set up Data Guard or a failover cluster. Licensing-wise, the standby in the other zone needs a license if it’s continuously running. If you only start it during a failover, you could use the 10-day rule for an unlicensed failover server​. But most likely, you’ll have it on, so plan for licenses on both.
• Bare Metal HA: Some GCP Bare Metal customers use Oracle RAC or clusters on those dedicated servers. The Bare Metal Solution is often used to run a traditional Oracle RAC cluster because it mimics on-prem hardware (for example, two physical machines connected to a storage array). If doing RAC on Bare Metal Solution, it’s like on-prem RAC – you must fully license all cores on all cluster nodes. There’s no cloud policy relief (the cloud policy doesn’t even acknowledge RAC, meaning it doesn’t let you do vCPU counting – you’re back to physical). Thus, RAC on GCP Bare Metal would require licensing every core of those machines (with Enterprise Edition plus RAC option licenses). That can be very expensive and likely only done by those who explicitly want RAC and are treating Bare Metal as an extension of on-prem with Oracle’s blessing. Many will avoid RAC and use Active Data Guard between two Bare Metal servers to reduce licensing (RAC option license vs just another DB license).
• Disaster Recovery to another cloud or on-prem: In some cases, the primary is on GCP, and the DR is on-prem or vice versa. The same licensing rules apply to DR – if the DR is on-prem and usually idle, you might use the 10-day rule, etc., or license both if running (like for Data Guard). No matter the combination (AWS <-> GCP, OCI <-> GCP, etc.), Oracle requires any installed/running instance to have a license. So, coordinate multi-cloud DR carefully, especially if failovers might last more than 10 days or if you plan to do DR drills that exceed the testing allowances. Document any such use and ensure the licenses are ready to be allocated if needed.

Common Audit Risks & Pitfalls (GCP):

Now that Google Cloud is an accepted platform, many pitfalls are similar to AWS/Azure, but here are a few to keep in mind:

• Pre-2024 Deployments: If your organization ran Oracle on GCP before it was officially authorized, Oracle might scrutinize those in an audit. Even though they’ve allowed it, technically, you were in a gray area. It would be wise to ensure all those deployments are now in line with the official policy (if any were miscounted or you assumed a different ratio, fix it). Oracle’s audit team might ask, “Since when have you been running this?” and could, in theory, claim non-compliance historically. Usually, Oracle would just ensure you’re compliant moving forward (especially since now it’s allowed), but be prepared to demonstrate that you were conservative (e.g., you counted 1 vCPU=1 license, perhaps, which would cover you).
• Bare Metal Solution confusion: Some SAM managers might not even know that a team ordered a “Bare Metal Solution” for Oracle. These are often handled outside the normal cloud console (in coordination with Google sales). Treat these like leased hardware – get a full inventory of what hardware, how many cores, etc. Because those won’t appear as vCPUs in a project, they’re physical. Not accounting for a Bare Metal server with 32 cores could leave you 32 licenses short. Open communication with the infrastructure team is key whenever Oracle is involved on GCP.
• Mix of cloud and on-prem licensing: GCP might be used for burst or temporary environments (like testing new Oracle versions). If teams spin up Oracle in GCP for a short-term project and then shut it down, make sure they acquired appropriate licenses for that period (e.g., using spare licenses from a pool) and reallocate them when done. Oracle doesn’t do short-term licensing (they phased out term licenses except for cloud services), so you either have the license or you don’t. If this is frequent, one strategy is to consider licensing via ULA or subscription to cover temporary use. Otherwise, you might inadvertently be non-compliant during those bursts.
• Assuming Google’s commitment covers Oracle fees: If your enterprise has a large committed spend agreement with Google, you might deploy Oracle via the marketplace and think it’s “free” since it draws down your commitment. Financially, that might be true, but remember that the cost of Oracle licenses is hidden in that service. From a SAM perspective, track how many Oracle instances you pay for through the GCP marketplace. The pitfall is losing track of Oracle usage because Google’s billing abstracts it. Always map it back – e.g., “We have X number of OCPUs of Oracle Database Service on GCP, which corresponds to Y number of licenses (if we were to do BYOL).” This helps if you ever consider switching those to BYOL or vice versa, or if Oracle asks how many licenses you consume in cloud services.
• Support Rewards applicability: Oracle’s Support Rewards program (33% back on support with OCI usage) technically can apply to Oracle Cloud services sold via Google Cloud (as Oracle states existing customers with on-prem licenses are eligible when using Oracle Database@Google Cloud)​. But this is an area to clarify with Oracle. If you are using the Oracle DB service on GCP and also paying Oracle support on some licenses, you might be able to get support rewards credit. Don’t leave that on the table – ask Oracle if your usage qualifies. It’s a nuanced benefit, but a pitfall would be not exploring it and missing out on support cost reduction.

After covering each provider’s nuances, it’s helpful to compare them side by side on key factors:

Head-to-Head Comparison: Oracle Licensing by Cloud Provider

Aspect	Oracle Cloud (OCI)	Amazon Web Services (AWS)	Microsoft Azure	Google Cloud Platform (GCP)
BYOL Support	Yes – Full support for all Oracle software on OCI. Oracle encourages BYOL on OCI (all Oracle products certified.	Yes – Supported for Oracle DB, middleware, etc., on EC2 and RDS (Enterprise and SE via BYOL)​.	Yes – BYOL is the primary model. All Oracle software can be run on Azure VMs with your	Yes – Fully supported as of 2024. Oracle licenses can be used on GCE VMs and Bare Metal Solution (all BYOL)​.
License-Included Services	Yes. Many OCI services offer license-included pricing (e.g. Autonomous DB, Oracle Database Cloud Service). Also, OCI programs like Support Rewards give cost relief​.	Limited. Only for Oracle Database Standard Edition on RDS (SE2 license is included in RDS pricing if chosen)​. All other Oracle software on AWS requires BYOL (Enterprise Edition RDS and EC2 = BYOL).	No (native). Azure has no built-in Oracle license-included IaaS/PaaS. However, via Oracle Database Service for Azure, you can get an Oracle-managed database with license-included or BYOL options (through Oracle-OCI partnership).	No (native). GCP has no native managed Oracle DB service. However, Oracle Database Service on Google Cloud (through Oracle-Google partnership) allows Exadata-based DB with license-included or BYOL options​. GCP’s Bare Metal servers are BYOL only.
vCPU Licensing Formula	1 OCPU (Oracle core) = 1 Processor license. An OCPU corresponds to 2 vCPUs with hyperthreading, effectively giving 2 vCPUs per license for Enterprise Ed​. Standard Ed: 4 OCPUs per license (up to 16 vCPUs for SE)​.	2 vCPUs = 1 Processor license (with hyperthreading)​. If hyperthreading off, 1 vCPU = 1 license. No Oracle core factor applied​. Standard Ed: 4 vCPUs = 1 license, max 16 vCPUs for SE, 8 for SE2​.	2 vCPUs = 1 Processor license (with hyperthreading) – same as AWS​. 1 vCPU = 1 license if hyperthreading off. No core factor. Standard Ed: 4 vCPUs = 1 license, same 16/8 vCPU limits for SE/SE2​.	2 vCPUs = 1 Processor license (with hyperthreading) – same formula​. 1 vCPU = 1 license if hyperthreading off. No core factor. Standard Ed: 4 vCPUs = 1 license, with 16 vCPU (SE) and 8 vCPU (SE2) instance limits​.
Oracle’s Policy Coverage	OCI is Oracle’s own cloud – Oracle’s standard licensing terms apply (Authorized Cloud policy is not needed for OCI). All Oracle programs fully supported on OCI.	Covered by Oracle’s “Authorized Cloud Environment” policy (AWS named explicitly)​. Must follow Oracle’s cloud licensing guidelines (vCPU counting, etc.). Oracle audits will reference this policy​.	Covered by Oracle’s Authorized Cloud policy (Azure explicitly included)​. Same guidelines as AWS. Oracle-Microsoft partnership provides additional certified solutions (interconnect, etc.).	Newly covered by Oracle’s Authorized Cloud policy as of 2024​. Follow same vCPU rules. Was unofficial before, now official. Oracle services on GCP via partnership are essentially OCI under the hood.
Support Responsibility	Oracle provides one-stop support. Software and cloud issues handled by Oracle. Support Rewards program: up to 33% of OCI spend back as credit on Oracle support bills​.	Split support: Oracle Support (with your support contract) for software; AWS for infrastructure or RDS service issues. Oracle treats AWS issues equally if licenses are valid​. License-included RDS: AWS handles support (with Oracle backline).	Split support: Oracle for software (with active support contract), Microsoft for Azure infrastructure. Oracle supports Azure deployments as authorized env (no support refusal). For Oracle DB Service for Azure, Oracle supports the database, Azure supports connectivity.	Split support: Oracle for software, Google for infrastructure. Now that GCP is authorized, Oracle will support issues on GCP like other clouds. Oracle DB Service on GCP: Oracle supports the DB (since it’s their Exadata), Google handles the underlying facility.
High Availability (HA/DR)	Fully supports Oracle RAC, Data Guard, etc. License both primary and standby if standby is running (e.g., Data Guard)​. 10-day rule applies for truly cold DR only​. RAC on OCI is allowed (must license all nodes). OCI provides managed RAC and Data Guard with license included options in Autonomous DB.	Multi-AZ RDS: standby included in license if using license-included; if BYOL, you need licenses for both primary and standby. EC2: Data Guard/failover requires licenses for all running instances. 10-day rule can cover an idle DR server for emergencies​. RAC not supported under standard policy (effectively disallowed on AWS).	No managed Oracle HA service natively. BYOL deployments must license any secondary/standby that is running. 10-day rule for a cold standby applies if you keep it powered off until failover​. Oracle RAC on Azure is not covered by policy (not recommended unless fully licensing physical cores). Azure-OCI Interconnect can be used: e.g., primary DB in OCI, app in Azure.	No native managed HA for Oracle (you set up VMs or Bare Metal with your HA config). License all active instances (standby needs license if running apply). Bare Metal allows on-prem-like cluster setups – need full licensing for RAC or active-passive nodes. 10-day rule for a truly inactive DR server if you only bring it up during failover.
Common Pitfalls	– Double counting: Don’t use one license for both on-prem and OCI; track BYOL allocations. – SE2 limits: OCI won’t stop you from oversizing an SE2 instance – ensure you stay within 8 OCPU (16 vCPU) limit. – Complacency: Even on OCI, maintain proof of license ownership for BYOL usage in case of audit.	– Hyperthreading off: If an instance has HT disabled, needs double licenses​. Some miss this and under-license. – DR licensing: Assuming a passive instance is free – if it’s running, it’s not free​. – ULA misuse: Counting AWS deployments in ULA certification – not allowed​.	– No license-included: Assuming Microsoft covers Oracle license – they don’t. Every Azure Oracle VM needs BYOL (unless using the Oracle-OCI service). – Oversizing SE2: Running Standard Edition on too large a VM (over 8 vCPUs) violates terms​. – Untracked VMs: Easy deployment can lead to rogue Oracle installs – implement tagging and monitoring.	– Pre-authorization usage: Oracle now allows GCP, but past unapproved use could be scrutinized – ensure all current usage follows the 2 vCPU=1 rule. – Bare Metal misunderstandings: Treat Bare Metal like on-prem – all cores count, and no cloud core-factor relief. – Auto-scaling: If Oracle VMs auto-scale, you must license peak – don’t assume brief usage is exempt.

Recommendations and Best Practices for SAM Managers

Overseeing Oracle licensing in a multi-cloud environment is challenging, but a proactive SAM approach can prevent compliance issues and optimize costs.

Here are key recommendations and best practices:

• Centralized Oracle License Tracking: Maintain an authoritative inventory of your organization’s Oracle licenses (by edition, options, and quantity) and map them to deployments across all environments (on-prem and each cloud). Update this whenever a new Oracle instance is launched or decommissioned. This inventory lets you see at a glance how many licenses are allocated vs available. Use cloud tagging (e.g., tag instances with “Oracle=Yes” and perhaps the license type) for tracking. A centralized view ensures you don’t accidentally oversubscribe your licenses across multiple clouds.
• Continuously Monitor Cloud Usage: Leverage cloud provider tools to monitor where Oracle software is running. For AWS and Azure, AWS Config/Azure Policy can alert when an Oracle AMI or image is launched. GCP’s cloud asset inventory can be queried for instances running Oracle (perhaps identified by metadata or naming conventions). Consider implementing AWS License Manager or third-party SAM tools that integrate with cloud APIs to track Oracle deployments in near real time​. Continuous monitoring will catch unplanned deployments or changes (like a vCPU count change) that could affect licensing, allowing quick remediation.
• Enforce the Oracle Cloud Policy Rules: As a SAM manager, educate and enforce Oracle’s cloud licensing rules within your cloud and DevOps teams. Document the 2 vCPU = 1 license rule and the specific limits for Standard Edition, and share this with cloud architects and DBAs. Implement guardrails: for example, disallow instance types that don’t have hyperthreading (or make sure the team knows to license them 1:1). If using Infrastructure-as-Code (IaC) templates (Terraform, CloudFormation) for Oracle deployments, bake in the correct instance sizing and license-related tags. By codifying compliance, you reduce the risk of human error. Periodically audit your cloud setups against Oracle’s policy – e.g., list all Oracle SE2 instances, confirm none exceed 8 vCPUs, etc.
• Leverage Cloud-Native Services When Sensible: Where possible, use cloud vendor services that simplify Oracle licensing. For instance, if you only need a small Standard Edition database and don’t want to burn a full license, running it via AWS RDS license-included might be cost-effective and removes the compliance burden for that instance. Similarly, if your organization is already paying hefty Oracle support, moving some workloads to OCI to earn Support Rewards credits can reduce net support costs. The key is to analyze cost vs compliance trade-offs: sometimes paying as you go (license-included) can be cheaper than maintaining additional perpetual licenses, especially for transient or project-based workloads. Just include those in your SAM reporting (they may not be “licenses,” but they are Oracle usage).
• Manage High Availability Licensing Strategically: Work with your architecture teams to decide on HA/DR designs that balance risk and cost. For example, suppose you can tolerate a slightly longer recovery time. In that case, a cold standby (powered off until needed) avoids a second license – this could be viable for a DR site where cost saving is paramount and you plan to use Oracle’s 10-day rule for emergencies​. If uptime is critical and you need active secondaries, plan the budget for those licenses. Document whatever strategy you choose in your SAM records so that during an audit, you can explain, “This server is unlicensed and off except for failover tests, which we keep within the allowed 10 days,” or conversely, “These servers are all fully licensed for HA.” Being deliberate in HA planning can prevent surprises later (downtime or unbudgeted license needs).
• Stay Informed on Oracle’s Licensing Updates: Oracle’s policies and cloud stances evolve. For instance, Oracle’s inclusion of GCP in the authorized policy 2024 was a significant change​. Keep an eye on Oracle’s official communications, expert blogs, and updates from advisory firms about Oracle licensing. Joining a community of Oracle SAM professionals or forums can help; the community often spots changes in policy or audit trends early. Oracle also sometimes changes its cloud licensing document wording – track versions (perhaps quarterly check Oracle’s site for a new PDF version and diff it). As one expert noted, Oracle can and will update the document, usually favoring Oracle’s interests​, so knowing the changes promptly helps you adjust your compliance approach accordingly.
• Conduct Internal Audits and License Reconciliation: Don’t wait for Oracle to audit – perform your internal audit at least annually. Reconcile the licenses you have with the deployments in each cloud. If you find a shortfall, address it proactively (this could mean reallocating licenses from a less critical system, buying additional licenses or subscriptions, or shutting down some instances). Document any assumptions – for example, if you assume two DR servers aren’t both active and thus only license one, have a record of that assumption with approval from a risk perspective. Internal audits prepare you for the real thing and demonstrate due diligence.
• Prepare for the Worst (Audit Readiness): Despite best efforts, Oracle audits are always possible (Oracle’s audit teams are notoriously active). Have an audit response plan specifically for cloud environments. For instance, I need to know how to quickly pull a list of all Oracle instances in each cloud (and who to contact for each if needed). Keep evidence of your entitlement (license agreements, Oracle Ordering Documents, support renewals) organized and accessible. In an audit, Oracle will ask for proof of licenses and usage data – supplying, for example, an AWS-generated report of all EC2 instances with their vCPU counts and a spreadsheet mapping those to licenses will streamline the process. This level of preparation can also discourage Oracle from pushing too hard, as they see you’re on top of things.
• Cost Optimization and License Recycling: From a cost management angle, Oracle licenses should be treated as expensive assets that should be fully utilized. If a project on Azure no longer needs that Oracle DB, shut it down and reclaim the license for the pool. Cloud makes it easy to spin up and down – ensure your processes include reclaiming licenses from de-provisioned instances. Conversely, suppose you’re paying for an Oracle cloud service and not using it. In that case, that’s wasted spend – monitor usage vs reservations (for instance, an autonomous DB sitting idle might be scaled down or terminated). Sometimes, consolidating workloads can free up a license: e.g., instead of two half-used Oracle servers on AWS and Azure each, maybe run both databases on one properly sized server in one cloud and turn off the other, cutting license requirements. Always align such decisions with technical feasibility and risk, but consider license efficiency.
• Training and Awareness: Include Oracle licensing awareness in your cloud governance training. Many cloud engineers and even some DBAs are not fully versed in Oracle’s licensing landmines – a short workshop or guide can prevent costly mistakes. For example, explain why a developer can’t just run an Oracle Enterprise Edition container on Kubernetes for an internal app without licenses or why enabling an Oracle feature in testing could have financial implications. This doesn’t have to be burdensome – it’s about creating a culture where people know to “stop and ask the SAM team” if they’re unsure about an Oracle deployment.
• Leverage Vendor Relationships and Contracts: If you foresee a heavy Oracle deployment in a non-OCI cloud, consider negotiating with Oracle. Sometimes, Oracle will provide written clarifications or amend contracts for specific cloud scenarios (especially for big clients). For instance, some ULAs can be negotiated to explicitly allow AWS/Azure counting. Or you might negotiate a pool of Oracle cloud subscriptions that give you flexibility. Use Oracle’s drive to sell cloud as a leverage point – Oracle might offer discounts or promotions if you shift some workload to OCI, which could be advantageous if it fits your strategy. As a SAM manager, you can provide data to executives about Oracle usage and spend across clouds to help in vendor negotiations.

Real-World Example: To underline the importance of SAM in multi-cloud Oracle management, consider the case of NASA (as reported by its Inspector General). NASA was so wary of an Oracle audit and unsure of its license deployments that it overpaid an estimated $15 million for unused Oracle licenses out of fear and lack of centralized visibility​.

This highlights that not having a handle on software assets can lead to huge unnecessary costs. In a multi-cloud context, without proper SAM controls, a company might overspend on licenses “just in case” or get hit by an audit for shortfalls. These best practices aim to avoid both outcomes – no overspending and no compliance gaps, just right-sizing and right-licensing your Oracle footprint.

Oracle Cloud licensing – Compare Oracle, AWS, Azure, and GCP FAQ

What are the main licensing models for Oracle on AWS?

AWS provides two main licensing options for Oracle: a Bring Your Own License (BYOL) model and a limited license-included model, mainly available for Oracle Standard Edition 2 through AWS RDS.

Does Azure offer Oracle a license-included option?

Azure relies solely on the Bring Your License (BYOL) model for Oracle software. Customers must have existing Oracle licenses to deploy Oracle products on Azure.

How does BYOL work with Google Cloud Platform (GCP)?

Customers must bring their own Oracle licenses (BYOL) to GCP. GCP also offers Oracle Bare Metal Solutions for more control and dedicated hardware deployments.

What is the Oracle Support Rewards Program?

The Oracle Support Rewards Program offers credits to Oracle customers using OCI. For every $1 spent on OCI, you can receive up to 33% back on your support bill, which helps reduce overall support costs.

Are Oracle Database Cloud Services available on all platforms?

Oracle Database Cloud Services are available on all major cloud platforms, including Oracle OCI, AWS, Azure, and GCP. Cloud commitments can include or cover licensing.

How are Oracle vCPUs licensed across AWS, Azure, and GCP?

When multithreading is enabled in AWS, Azure, and GCP, two vCPUs are equivalent to one Oracle Processor license. The licensing calculation remains consistent across these platforms.

Does Oracle offer a pay-as-you-go licensing model?

Oracle offers a pay-as-you-go model on OCI, allowing flexible hourly billing for Oracle services. AWS and Azure offer limited pay-as-you-go options, while GCP offers pay-as-you-go options for specific services.

What is the primary licensing difference between OCI and other clouds?

OCI offers both license-included and BYOL options, along with unique support rewards. Other cloud providers, such as AWS and Azure, mainly use BYOL, with limited license-included offerings.

Can Oracle applications run on Azure?

Oracle applications like E-business Suite, JD Edwards, and PeopleSoft can run on Azure using the BYOL model. The OCI-Azure interconnect enhances integration between Oracle and Azure environments.

Does GCP provide a license-included option for Oracle?

GCP provides Oracle Database Cloud Services with a license-included option, allowing organizations to use Oracle services without managing individual licenses.

Is Bare Metal Solutions available for Oracle on all cloud platforms?

Bare Metal Solutions is only available on Google Cloud Platform (GCP) and Oracle OCI. It offers a dedicated hardware environment for running Oracle workloads.

How does Oracle licensing differ between AWS RDS and EC2?

AWS RDS offers a limited license-included option for Oracle SE2, while EC2 instances require customers to bring their licenses (BYOL) for Oracle products, with licensing based on vCPU count.

What is the advantage of using OCI for Oracle workloads?

OCI offers various licensing models (BYOL and license-included) and unique benefits, such as the Support Rewards Program, which helps reduce support costs for Oracle customers.

Can Oracle licensing be transferred across different clouds?

Yes, Oracle licenses can be transferred to other cloud platforms under the BYOL model, provided compliance with Oracle’s cloud policies. Ensure eligibility for transferring licenses across AWS, Azure, or GCP.

What are the compliance risks of Oracle licensing in public cloud environments?

Compliance risks include improper instance sizing, misunderstanding BYOL policies, and deployment in unauthorized regions. Regular license reviews and audits help mitigate non-compliance risks.

Read more about our Oracle License Management Services.

Do you want to know more about our Oracle License Management Services?