Oracle Database Licensing on AWS: BYOL Rules, Compliance Risks & Cost Reality

BYOL Fundamentals on AWS: What the Term Actually Means

Bring Your Own Licence (BYOL) means you deploy Oracle Database software on AWS infrastructure using your existing Oracle licence entitlements — rather than consuming Oracle software licences that AWS provisions through its Oracle licensing agreements. In principle, BYOL allows enterprises to leverage existing Oracle investments in the cloud without paying Oracle twice.

In practice, BYOL on AWS triggers a set of Oracle licensing rules that are fundamentally different from on-premises deployments. The critical point: Oracle does not recognise AWS as providing the same hard partitioning capabilities available in your data centre. The licence rules that apply on AWS infrastructure are determined by Oracle's licensing policy — not by what AWS's architecture makes technically possible, and not by what your AWS account team tells you.

Oracle has never certified AWS EC2 as a hard partitioning technology. This has significant consequences for how many licences you are required to hold when running Oracle Database on EC2 instances. Understanding this distinction is the difference between a compliant AWS Oracle deployment and an undisclosed seven-figure compliance gap.

Oracle's Official Position on AWS

Oracle's authoritative statement on cloud licensing is contained in its "Licensing Oracle Software in the Cloud Computing Environment" policy document. The key provisions for AWS are unambiguous: AWS is listed as an "Authorized Cloud Environment" — but this does not mean Oracle provides preferential licensing treatment on AWS. It means Oracle permits deployment on AWS subject to specific counting rules.

The counting rule for Processor licences on AWS EC2 is: one vCPU = one required processor licence when the 0.5 Core Factor does not apply. This is materially different from on-premises, where one physical core on an Intel Xeon server requires only 0.5 processor licences. On AWS, unless you are using an Authorised Dedicated Host (see below), your licence requirement is driven by vCPU count at a 1:1 ratio — not by the physical hardware underneath your instance.

For Named User Plus (NUP) licensing, the rules are unchanged: you must licence the greater of 10 NUP per processor or your actual named user count. The processor count for NUP minimum purposes on AWS is calculated using the vCPU-based approach described above.

How Oracle Counts vCPUs on EC2 — and the Hyper-Threading Consideration

AWS presents vCPUs to EC2 instances. By default, each AWS vCPU corresponds to a single thread on the underlying host's physical processor. On most current Intel and AMD Xeon/EPYC processors running AWS hypervisor, Hyper-Threading is enabled, meaning each physical core generates two threads — two vCPUs.

Oracle's policy states that if two vCPUs correspond to a single physical core with Hyper-Threading, you need only licence one processor licence for that pair of vCPUs. In practice, AWS provides the ability to disable Hyper-Threading per instance (or configure the instance to show actual physical core counts), and Oracle accepts this configuration as reducing the processor licence requirement by 50%.

However, exercising this requires specific EC2 configuration: you must launch instances with the Hyper-Threading disabled option, and you must document this configuration. If your compliance review does not capture the Hyper-Threading configuration of each EC2 instance running Oracle Database, you may be inadvertently calculating your licence requirement at twice the actual figure — or your Oracle LMS audit team may claim you owe twice what you actually owe if your documentation does not demonstrate Hyper-Threading is disabled.

AWS Dedicated Hosts: The Path to On-Premises Licence Treatment

AWS Dedicated Hosts provide physical server capacity dedicated exclusively to your organisation. Oracle recognises AWS Dedicated Hosts as a mechanism for applying on-premises Core Factor calculations — specifically, Intel Xeon at 0.5 Core Factor — rather than the vCPU-based counting that applies to shared EC2 infrastructure.

To qualify for Dedicated Host treatment in Oracle's view, you must meet specific configuration requirements: the host must be dedicated solely to your tenancy, the EC2 instances running Oracle must be pinned to the Dedicated Host, and you must maintain documentation of the host's physical CPU configuration (socket count, cores per socket, processor model) to support the Core Factor calculation.

Dedicated Hosts carry a premium AWS cost — you pay for the entire host regardless of utilisation. For large Oracle Database deployments, the licence savings from Dedicated Host Core Factor treatment frequently outweigh the premium AWS infrastructure cost. For small deployments with a handful of Oracle instances, the economics rarely justify the overhead.

Even on Dedicated Hosts, Oracle's Processor licence requirement covers the physical cores of the entire host — not just the cores allocated to Oracle VM instances on that host. If you provision a Dedicated Host with 64 physical cores and run Oracle on one VM with 8 vCPUs, Oracle requires you to licence all 64 physical cores at 0.5 Core Factor = 32 processor licences. Dedicated Hosts are beneficial only when the host is densely utilised by Oracle workloads.

Oracle on Amazon RDS: What You Give Up and What You Pay

Amazon RDS for Oracle provides a managed Oracle Database service. Oracle is available on RDS under two licensing models: Licence Included (Oracle sells the licence through AWS, typically at a premium embedded in the RDS hourly rate) and BYOL (you supply Oracle Database Standard Edition 2 or Enterprise Edition licences).

Under RDS BYOL, Oracle's vCPU counting rules apply directly. RDS does not offer Dedicated Host configurations. Your licence requirement for RDS Oracle is driven by the vCPU count of your RDS instance class, at Oracle's cloud counting rules. You cannot apply the 0.5 Core Factor to reduce this. You must also ensure your RDS deployment's Oracle Database edition matches your licence entitlement — SE2 on a db.m6i.16xlarge instance (64 vCPUs) is not permitted under Oracle SE2 licensing, which caps at 16 vCPUs (equivalent to 8 physical cores at 0.5 Core Factor in on-prem terms).

Database Options and Management Packs present a separate challenge on RDS. Oracle Diagnostics Pack and Oracle Tuning Pack features are surfaced through the RDS console and Performance Insights. If your team has enabled Performance Insights and uses query-level metrics, Oracle may argue this constitutes use of Diagnostics Pack functionality — requiring an additional licence you may not have provisioned. This is an active audit risk in RDS environments.

AWS Audit Exposure: How Oracle Discovers Cloud Deployments

Oracle's LMS audit scripts — particularly USMM — can collect inventory from cloud instances as effectively as from physical servers. If Oracle issues an audit and your AWS environment is within scope, Oracle's scripts will enumerate EC2 instances, their vCPU configurations, and installed Oracle software. Cloud deployments do not reduce your audit exposure. In some respects they increase it, because the speed and scale of cloud provisioning makes it easier to spin up Oracle instances without corresponding licence tracking.

Oracle also identifies undisclosed cloud deployments through third-party data sources, including AWS Marketplace activity logs (where Oracle has commercial relationships with AWS), and through mergers and acquisitions due diligence processes that expose cloud infrastructure. Several high-profile Oracle audit claims in recent years originated from AWS environment discoveries where the organisation assumed its cloud Oracle usage was invisible to Oracle's LMS team.

The most effective defensive posture is proactive: conduct your own AWS Oracle inventory before Oracle does, establish a documented and defensible licence position, and — if you have material AWS Oracle exposure — engage with Oracle proactively rather than waiting for an audit letter. Our Oracle Audit Defence practice manages both proactive remediation and active audit response for AWS Oracle environments.

Database Options & Management Packs on AWS

Oracle Database Enterprise Edition options — Advanced Security Option, Partitioning, Real Application Clusters, Active Data Guard, In-Memory Database — and Management Packs (Diagnostics Pack, Tuning Pack) require separate licence purchases on AWS exactly as they do on-premises. The BYOL model does not bundle any options or packs; you must positively licence each one for every processor licence in scope.

The compliance risk that Oracle's LMS team focuses on in AWS environments is accidental options enablement. Oracle Database, when deployed on EC2 from Oracle's own AMI images in the AWS Marketplace, may have certain features pre-configured. If your DBA team enables a feature without understanding its licensing status — say, enabling the In-Memory column store via the INMEMORY_SIZE parameter — Oracle's USMM scripts will detect the feature usage and include it in an audit finding.

Oracle Diagnostics Pack is the most commonly accidentally-enabled option. It gates access to Active Session History, AWR (Automatic Workload Repository), ADDM (Automatic Database Diagnostic Monitor), and certain V$ views that DBAs naturally use for performance troubleshooting. In cloud environments where monitoring and observability tooling is automatically configured, Diagnostics Pack functionality is routinely consumed without specific licence coverage. Oracle's audit detection rate for accidental Diagnostics Pack usage on AWS is high — this is a structured part of their LMS script output.

Read our detailed analysis in Oracle Diagnostics Pack Licensing: The Accidental Compliance Trap.

True Cost Modelling: On-Premises vs AWS Oracle Database

The decision to run Oracle Database on AWS versus on-premises is not purely an infrastructure question. Oracle licensing costs frequently make AWS Oracle deployments more expensive than equivalent on-premises configurations — particularly for large, processor-intensive workloads. Understanding the full cost requires modelling both Oracle licence and support costs alongside AWS infrastructure costs.

These figures illustrate why moving Oracle Database to standard EC2 without careful licence planning can double your Oracle licence obligation compared to on-premises. Our Oracle Cloud Advisory service provides detailed financial modelling before migration decisions are finalised — identifying whether OCI (with its Bring Your Own Licence and Support Rewards programme) represents a materially better economic outcome than AWS for Oracle workloads.

For enterprises where Oracle OCI makes commercial sense, our advisors can model the full Oracle Cost of Ownership including Support Rewards, OCI credits, and Universal Credits pricing. See our Oracle Cloud Licensing Guide for comprehensive coverage of OCI licensing mechanics.