Why Standard EC2 Instances Create Unlimited Oracle Licence Exposure

Oracle's licensing policy for cloud environments follows the same logic as for on-premises virtualisation: if Oracle software runs on infrastructure where it could potentially execute on any physical host, all physical hosts must be licensed. Standard AWS EC2 instances run on physical hosts that are shared across many AWS customers. AWS can and does migrate EC2 instances between physical hosts for maintenance, capacity management, and failure recovery. Oracle's position is that because you cannot determine or control which physical host your EC2 instance runs on at any given time, you are technically exposed to unlimited licence obligations.

In practice, Oracle does not attempt to audit AWS infrastructure and cannot compel AWS to provide physical host inventories. However, Oracle does require customers to self-certify their AWS deployment in licence management tools. Organisations that deploy Oracle Database on standard EC2 instances and represent their licence position as limited to the vCPUs in their EC2 instances — without using Dedicated Hosts — are making a misrepresentation that creates audit risk. Our Oracle virtualisation licensing guide explains the logical basis for Oracle's rule and how it applies across different cloud providers.

The Dedicated Host Rule: Oracle's Only Approved AWS Path

In January 2017, Oracle published the Authorised Cloud Environments policy that formally recognised AWS EC2 Dedicated Hosts as a compliant mechanism for sub-capacity Oracle licensing on AWS. When you provision an EC2 Dedicated Host, you receive a physical server in AWS's infrastructure that is dedicated to your account. No other customer's workloads run on that physical host.

Oracle's counting rule for Dedicated Hosts: count all physical processor cores on the Dedicated Host, not just the vCPUs of the EC2 instance. Apply the standard Intel core factor (0.5) to the physical core count. For example, an r5.4xlarge instance on a Dedicated Host with 48 physical cores requires 24 Oracle Processor licences — regardless of the fact that the EC2 instance itself has only 16 vCPUs.

The AWS-specific core factor: Oracle published a specific AWS Core Factor Table for Dedicated Hosts. Intel Xeon hosts use the 0.5 factor. AMD EPYC-based hosts also use 0.5. Always check the specific host type processor generation to apply the correct factor.

Oracle on RDS: Licence-Included and BYOL Options

AWS RDS for Oracle offers two commercial models. Licence-Included: AWS handles the Oracle Database licence as part of the hourly RDS rate. You pay a higher per-hour rate but do not need your own Oracle Database licences. Oracle Standard Edition 2 and Enterprise Edition are available as RDS Licence-Included. This model is simpler from a compliance perspective — Oracle licences the deployment through AWS directly, and your obligations are to AWS, not to Oracle directly.

BYOL for RDS: You can apply your own Oracle Database licences to RDS instances. The BYOL model for RDS is more complex than for EC2: RDS BYOL uses instance-based counting, and Oracle has specific rules about which RDS instance families are eligible for BYOL. Importantly, BYOL for RDS requires that your licences are on active Oracle Premier Support or at minimum Sustaining Support.

Key restriction: Oracle Database Enterprise Edition on RDS BYOL is only available for Multi-AZ deployments when using BYOL. Single-AZ BYOL is not permitted for EE. This constraint frequently surprises organisations migrating from on-premises single-instance EE deployments. See our Oracle support cost reduction guide for options on managing support obligations.

Multi-AZ, Standby Instances, and Licence Double-Counting Risk

RDS Multi-AZ deployments create a hot standby replica in a second Availability Zone. Under Oracle's licence agreement, the standby instance must also be licensed if it can serve read traffic or if it can become primary without a licence change. Standard RDS Multi-AZ failover creates a situation where the standby instance becomes primary automatically — which means both the primary and standby require separate licence entitlements.

AWS reads passive standby databases differently from Oracle's terms. Organisations that model their RDS Multi-AZ deployment as requiring only the primary instance licence are underestimating their Oracle licence obligation by 50 percent.

Aurora with Oracle compatibility does not exist (Amazon Aurora is MySQL/PostgreSQL compatible). Any AWS service that is truly Oracle-compatible is either RDS for Oracle or self-managed Oracle on EC2. Organisations that deploy MySQL or PostgreSQL as Oracle alternatives on AWS do not have Oracle licence obligations for those deployments. See our comparison of Oracle and third-party database support for context on compatibility and support trade-offs.

Practical Steps to Achieve Compliant Oracle Licensing on AWS

For Oracle Database on EC2: provision EC2 Dedicated Hosts rather than standard instances; document the physical core count for each Dedicated Host; apply the Intel core factor (0.5 for current Xeon generations); maintain a licence mapping that records which Dedicated Host carries which Oracle product licences; ensure Oracle Database Options (Partitioning, Advanced Compression, etc.) are separately tracked and licensed.

For RDS Oracle: use Licence-Included for simplicity if cost is secondary to compliance certainty; if using BYOL, validate eligibility of your specific licences; ensure Multi-AZ deployments have licences covering both primary and standby instances; confirm Premier Support status for all BYOL licences.

Migrate long-term Oracle Database workloads to OCI: if Oracle Database is a strategic workload that will remain on Oracle for 3 to 5 years, migration to OCI with BYOL provides better economics than AWS Dedicated Hosts AND better compliance certainty. The sub-capacity counting on OCI VM shapes (counting only shape OCPUs, not physical host cores) results in 50 to 70 percent fewer processor licences than AWS Dedicated Host counting. See our Oracle BYOL to OCI guide and OCI versus AWS and Azure pricing comparison for detailed analysis. Download our Oracle total cost optimisation white paper for a framework you can use with your internal finance team.