Oracle Database Licensing in the Cloud: The AWS, Azure and OCI Trap

Oracle's standard position is simple: if you want to run Oracle Database in the cloud, you need licenses for the cloud. But many enterprises believe their existing on-premises Enterprise Edition licenses — sometimes with dozens of options — entitle them to run Oracle in AWS or Azure at no additional software cost. That's the trap.

Oracle's BYOL (Bring Your Own License) policy allows you to use on-premises licenses in the cloud under specific, narrow conditions. The conditions vary by cloud provider, the version of the database, and crucially, how Oracle has configured the virtual machines in that cloud environment. Getting the calculation wrong by even one processor metric unit can result in a full compliance finding in an Oracle License Management Services audit.

How Oracle BYOL Works — The Baseline Rules

Oracle's BYOL policy for cloud deployments is governed by the Oracle Cloud Licensing Policy document, which Oracle updates periodically without sending notifications to customers. The core rule is that you can use existing Oracle processor licenses in Authorized Cloud Environments (ACEs), but the counting methodology is different from on-premises.

On-premises, Oracle licensing counts physical processor cores multiplied by a Core Factor (typically 0.5 for Intel x86). In AWS and Azure, Oracle counts vCPUs — and the default ratio is 2 vCPUs per processor license. This means a server with 16 vCPUs requires 8 processor licenses. On-premises with a physical 16-core server, you'd need only 8 cores × 0.5 = 4 processor licenses. The same Oracle workload in the cloud requires twice the licenses, before you even add options like Partitioning, Diagnostics Pack or Real Application Clusters.

AWS: The Most Common Trap

AWS is where we see the most Oracle cloud licensing violations. The primary reason is that enterprises migrating to AWS typically use lift-and-shift approaches, selecting instance types based on compute and memory requirements rather than Oracle licensing implications. The result: they end up on non-ACE instances or miscounting the license requirement.

On AWS, Oracle BYOL works on specific EC2 instance families. The permitted instance types for BYOL are defined in Oracle's policy document and generally include dedicated host configurations. When running on shared tenancy (the default), Oracle's position is that you must license all physical cores on the underlying host — not just your instance's vCPUs. This is the "soft partitioning" problem.

Oracle considers AWS Elastic Load Balancing, Auto Scaling groups, and containerised deployments on EC2 as soft partitioning. Soft partitioning does not limit the processor count for licensing purposes. In Oracle's interpretation, if you run Oracle Database in an auto-scaling group across a fleet of EC2 instances, you must license every processor in every instance that could potentially run Oracle — even if Oracle is only active on two instances at any given moment.

Our Oracle negotiation team consistently finds that enterprises running Oracle Database on standard EC2 instances believe they're compliant because they count their instance vCPUs. They're not. Oracle's LMS scripts, when run in an AWS environment, return the full physical host core count — and enterprises suddenly discover they need 10 to 20 times more licenses than they thought.

Azure: Microsoft's Licensing Benefit Muddies the Water

Azure has an important difference from AWS: Oracle and Microsoft have a co-location agreement (formalised in their 2019 interconnect partnership) that makes Oracle workloads on Azure slightly more favourable. The OracleDB@Azure service, launched in late 2023, runs Oracle Database Service directly in Azure datacentres but on Oracle-owned hardware, which means OCI licensing rules apply rather than Azure BYOL rules.

For standard BYOL on Azure Virtual Machines (not OracleDB@Azure), the rules are similar to AWS: 2 vCPUs equal 1 processor license. The key difference is that Azure Hyper-V with limited vCPU configurations has historically been considered hard partitioning by Oracle — but Oracle has been increasingly challenging this position in audits since 2022. Do not assume your Azure VM-based Oracle deployment is automatically compliant without a forensic review.

If you're on Azure and considering Oracle, OracleDB@Azure deserves serious evaluation. It allows you to use existing Oracle licenses at OCI ratios (where BYOL typically provides a 50% price reduction on Oracle Cloud Infrastructure compared to buying new licenses), while keeping the data in Azure for compliance and latency reasons. We regularly negotiate OracleDB@Azure contracts as part of broader Oracle EA negotiations.

OCI: Oracle's Preferred Destination (And Their Best Offer)

Oracle Cloud Infrastructure is where Oracle wants your workloads, and they price it accordingly. OCI's BYOL discount is the most generous of any cloud: you receive a 50% reduction on the compute cost of Oracle Database Cloud Service when you bring your own licenses. For Oracle Autonomous Database, the BYOL discount is also significant.

On OCI, Oracle uses a hyperthreaded virtual core (OCPU) as the unit of measurement. One OCPU equals one physical core, and for BYOL purposes, each OCPU requires one processor license (at the standard core factor). This is a meaningful difference from AWS and Azure where 2 vCPUs = 1 license: on some OCI instance shapes, you're getting better value per license than on-premises.

The catch with OCI is vendor dependency. Oracle's pricing on OCI egress, compute, and ancillary services is not competitive with AWS or Azure. If you migrate to OCI for Oracle Database, you're increasingly tying your infrastructure decisions to Oracle's roadmap. The cloud cost negotiation calculus requires careful modelling of the full stack — not just the database licensing savings.

The BYOL Authorised Cloud Environment Rules: Platform Comparison

The Oracle LMS Script Problem

When Oracle's License Management Services team initiates an audit, they provide scripts for you to run against your environment. In a cloud deployment, these scripts — particularly the Oracle LMS CPU script — return the physical host characteristics, not your instance characteristics. On AWS shared tenancy, that means the script reports all physical cores on the underlying EC2 host, which could be 64 or 96 cores when you've only deployed a 4 vCPU instance.

This is not a theoretical problem. We've seen enterprises receive audit findings of $8M+ because their Oracle Database ran on shared-tenancy EC2 instances and Oracle counted the full physical host. The enterprise believed they needed 4 processor licenses (2 vCPUs ÷ 2). Oracle's position was 48 processor licenses (96 physical cores × 0.5 core factor).

If you're running Oracle Database in AWS today on shared-tenancy instances, you need an immediate forensic review of your position. Our software audit defence team includes former Oracle LMS personnel who understand exactly how these scripts interpret cloud environments. We can assess your exposure before Oracle does.

Options and Oracle Database Alternatives

The Oracle cloud licensing complexity has accelerated enterprise interest in alternatives — particularly PostgreSQL, Amazon Aurora PostgreSQL, and Azure Database for PostgreSQL. Many enterprises running Oracle Database Standard Edition 2 (SE2) or using a limited subset of Enterprise Edition features are finding that a migration to PostgreSQL eliminates the Oracle licensing cost entirely.

We're not reflexively anti-Oracle. For complex transactional workloads heavily dependent on Oracle-specific features — Real Application Clusters, Advanced Compression, Database Vault — migration is expensive and risky. But for enterprises running Oracle primarily as a relational database engine with standard SQL, the licensing cost differential is difficult to justify when comparable open-source options exist at zero license cost in any cloud.

If you're considering alternatives, the negotiation approach changes: rather than negotiating a better Oracle deal, you're negotiating Oracle down while migrating away. Oracle typically becomes more flexible on pricing when they believe you might leave. Our multi-vendor negotiation service regularly uses migration credibility to reduce Oracle's final offer by 25-40%.

What Enterprise Buyers Should Do Before Any Oracle Cloud Deployment

Before you deploy a single Oracle Database workload in the cloud, you need clarity on five things. First, confirm whether the instance types you plan to use are on Oracle's ACE list for that cloud provider. Second, determine whether you'll use shared tenancy or dedicated hosts, and model the cost difference. Third, audit your existing on-premises Oracle licenses to establish your BYOL entitlement baseline. Fourth, verify that your support contract covers cloud deployments (some older contracts have gaps). Fifth, run the Oracle LMS scripts in your target environment before going live to see exactly what Oracle would count in an audit.

If you skip any of these steps, you're assuming a compliance posture that Oracle's licensing policy may not support. The risk is disproportionate: Oracle's standard response to a compliance finding is to charge list price for the missing licenses — often three to five years of back support on top.

How NoSaveNoPay Approaches Oracle Cloud Licensing

We've helped dozens of enterprises navigate Oracle cloud licensing decisions. Our approach combines forensic compliance analysis with active commercial negotiation. On the compliance side, we run a full entitlement analysis against your planned cloud deployment topology to identify gaps before Oracle does. On the commercial side, we negotiate directly with Oracle's cloud team to secure BYOL terms, support contract language, and cloud pricing that matches how you actually intend to deploy.

Our team includes former Oracle Cloud Infrastructure sales executives and former Oracle LMS auditors. We understand Oracle's internal goals — their cloud revenue targets, their audit programme quotas, and the flexibility that exists within Oracle's sales motion that customers almost never see on their own.

The average enterprise we engage on Oracle cloud licensing negotiation saves 28-35% on their projected Oracle cloud spend — through a combination of better BYOL terms, reduced support costs, and right-sizing the deployment architecture to match Oracle's compliance requirements at minimum cost. Under our gainshare model, you keep 75% of every dollar saved. If we find no savings, you pay nothing.

Related Reading

• Oracle License Review 2026: What to Expect and How to Prepare
• Oracle Java Licensing: The $2M Surprise Bill (And How to Avoid It)
• Oracle ULA Exit Strategy: How to Certify Without Overpaying
• Oracle EA Negotiation Playbook — Free White Paper
• Software Audit Defence Service
• Cloud Cost Negotiation Service
• How Our Gainshare Model Works