How to License Oracle Database Options — RAC, Multitenant, and Partitioning on AWS

The Oracle Cloud Licensing Policy: Where On-Premises Rules End

Oracle's standard licensing rules — processor counts based on core factor tables, hard partitioning allowances, virtualisation rules based on Oracle VM — do not apply when Oracle databases are deployed on AWS. Instead, Oracle's Cloud Licensing Policy applies. This policy was designed by Oracle to ensure that cloud deployments generate at least as much licence revenue as equivalent on-premises deployments, and in many cases significantly more.

The Cloud Licensing Policy establishes a flat rule for most AWS EC2 instance types: two vCPUs equal one Oracle processor licence. This rule applies regardless of the underlying physical processor type, the number of physical cores the vCPU maps to, or any AWS-specific configuration. The core factor table discounts that apply to Intel, AMD, and ARM processors in on-premises environments do not apply to AWS. A 64-vCPU EC2 instance requires 32 Oracle processor licences — no adjustment for core type or generation.

This rule has significant commercial implications. Many organisations that migrated Oracle workloads from on-premises to AWS without reviewing their licence requirements discovered they were materially under-licensed — not because they had added Oracle software, but because the licensing calculation method changed with the deployment platform.

BYOL on AWS: The Fundamental Rules

Bring Your Own Licence (BYOL) allows organisations to use existing on-premises Oracle licences for AWS deployments. This is the standard approach for running Oracle Database Enterprise Edition on EC2. Oracle's BYOL rules for AWS are clear on several points that organisations frequently misunderstand.

Active Support Is Mandatory

Oracle licences used under BYOL on AWS must have active Oracle support. Oracle will not recognise a BYOL deployment as compliant unless the underlying licences are covered by a current support contract. If you have dropped Oracle support on licences you intend to use for an AWS deployment, you will need to reinstate that support — at Oracle's reinstatement fee, which includes backdated support costs at 8% per year compound rates — before the BYOL position is compliant.

Enterprise Edition Only for Advanced Features

Standard Edition 2 is supported on AWS under BYOL for standard database deployments, but most of the database options covered in this guide — Partitioning, Advanced Compression, Advanced Security, and Multitenant beyond three PDBs — are Enterprise Edition features only. Standard Edition 2 does not support these options and cannot use them on any platform, on-premises or cloud.

Multi-AZ Doubles Your Licence Requirement

If you deploy Oracle in a Multi-AZ configuration on AWS RDS or with a standby instance on EC2, the standby instance requires separate licence coverage. Oracle's position is that the standby database is "installed and running" and therefore requires a full licence. A Multi-AZ deployment that covers a 16-vCPU primary instance requires 8 processor licences for the primary and 8 processor licences for the standby — 16 processor licences in total. Many organisations calculate only the primary instance and discover the standby gap in an audit.

Oracle RAC on AWS: The Unavoidable Constraint

Oracle Real Application Clusters (RAC) is one of Oracle's most valuable enterprise database features — providing high availability, scalability, and active-active failover for Oracle Database Enterprise Edition. On AWS standard EC2, RAC is not supported or licensable, and this is one of the most important architectural constraints that Oracle database architects must understand before any AWS migration project.

Why RAC Cannot Be Licensed on Standard EC2

Oracle's licence terms and technical support policies explicitly exclude RAC from standard third-party cloud environments including AWS EC2. Oracle will not provide technical support for RAC deployed on EC2, and Oracle LMS will not recognise such a deployment as compliant regardless of whether the customer has RAC licences in their entitlement. This is not primarily a commercial decision — it is because Oracle's RAC requires shared storage and a specific network interconnect fabric between nodes that standard EC2 instance networking cannot provide in a supported configuration.

The VMware Cloud on AWS Exception

There is one pathway to RAC on AWS: VMware Cloud on AWS (VMC). Oracle supports its full on-premises licensing model on VMC, including RAC, because VMC is treated as an Oracle-recognised VMware environment that qualifies for hard partitioning licensing rules. Under VMC, you can apply Oracle's standard processor licensing rules, use core factor tables, and deploy RAC on shared VSAN storage. The cost premium of VMC is significant, but for workloads that genuinely require RAC capabilities, it is the only supported path on AWS infrastructure.

Alternatives to RAC on Standard EC2

For organisations that need the high availability and read scalability that RAC provided on-premises, several alternatives work within Oracle's AWS licensing rules. Active Data Guard provides physical standby databases with real-time synchronisation and read-only query capability, with a separate Active Data Guard option licence required. Amazon RDS for Oracle provides managed high-availability configurations with automated failover, using Oracle Data Guard technology under the hood. Application-layer clustering — where the high availability architecture is managed at the application tier rather than the database tier — eliminates the RAC dependency entirely for some workloads.

Multitenant and CDB Licensing on AWS

Oracle's Multitenant architecture, introduced in Oracle Database 12c, allows multiple pluggable databases (PDBs) to share a single container database (CDB). The Multitenant option controls how many PDBs you can operate in any CDB, and the rules apply identically on AWS as on-premises.

The Three-PDB Free Allowance

In Oracle Database Enterprise Edition, you can operate up to three PDBs per CDB without a Multitenant option licence. This is the standard allowance included in the Enterprise Edition base licence. If you need four or more PDBs in a single CDB, you must licence the Multitenant option for every processor licence used by that CDB. The Multitenant option is licensed at the same price as the base Enterprise Edition processor licence — so deploying it effectively doubles the per-processor cost of that database.

On AWS, there is no technical enforcement of the three-PDB limit. Oracle Database on EC2 will allow you to create as many PDBs as your storage and memory permit. Compliance is entirely the responsibility of the customer. Organisations that run CDBs with five, ten, or twenty PDBs on AWS because the database allowed it — without a Multitenant option licence — are creating significant audit exposure. Oracle LMS discovers this situation through the DBA_PDBS and DBA_CON_NAME views during an audit, and claims the Multitenant option licence retroactively for every processor the CDB runs on.

RDS Oracle and Multitenant

Amazon RDS for Oracle, in its standard configuration, allows only a single PDB per database instance. This is an AWS-imposed restriction, not an Oracle licensing restriction, and it means that standard RDS Oracle deployments do not require the Multitenant option. RDS Custom for Oracle removes this restriction and allows multiple PDBs, at which point Oracle's standard Multitenant licensing rules apply and you must licence the option if you exceed three PDBs.

Oracle Partitioning on AWS

The Oracle Partitioning option — which enables range, list, hash, and composite partitioning of tables and indexes — is one of the most commonly deployed and most commonly unlicensed Oracle database options. It is also one of the most straightforward in terms of licensing rules: the Partitioning option must be licensed for every processor licence running a database where any partitioned table or index exists.

The Activation Threshold

Partitioning licensing is triggered the moment any table or index in any schema on the database is partitioned. There is no minimum partition count, no minimum usage threshold, and no grace period for newly deployed partitioning. If your application creates a partitioned table, the Partitioning option is required from that moment. The cost of the Partitioning option is approximately $11,500 per processor licence (list price), multiplied by the number of processor licences required for the database under the 2 vCPU per processor rule on AWS.

A database running on a 16-vCPU EC2 instance with one partitioned table requires 8 processor licences for the database plus 8 Partitioning option licences — at list price, approximately $460,000 for the base licence plus approximately $92,000 for the Partitioning option, before any negotiated discounts.

On-Premises Partitioning Policies Do Not Apply on AWS

Oracle's licensing policies for on-premises deployments include some specific allowances related to partitioning and Oracle's Optimal Flexible Architecture guidelines. These policies are tied to Oracle's own hypervisor (Oracle VM / Oracle Linux KVM) and do not extend to third-party cloud platforms including AWS. The only relevant policy for Oracle Partitioning on AWS EC2 is the standard Cloud Licensing Policy, which applies the 2 vCPU rule with no adjustments.

Hard Partitioning on AWS: EC2 Dedicated Hosts

AWS offers Dedicated Hosts — physical servers allocated exclusively to your account — which Oracle recognises as a form of hard partitioning. When Oracle databases are deployed on AWS Dedicated Hosts, Oracle's standard processor licensing rules apply, including the core factor table discounts for Intel and AMD processors. This can result in significantly lower licence requirements compared to standard EC2 instances for the same computational capacity.

The calculation requires knowing the specific processor type on the Dedicated Host. An Intel Xeon Scalable processor has a core factor of 0.5, meaning each physical core requires only half a processor licence. A Dedicated Host with 48 physical cores (96 vCPUs on a standard EC2 instance) would require 24 processor licences under the cloud policy, but only 24 multiplied by 0.5 equals 12 processor licences under the Dedicated Host hard partitioning path. For large Oracle deployments, this difference can represent millions of dollars in licence costs annually, and the additional cost of Dedicated Hosts is typically recovered many times over in the licence savings.

The Most Costly Compliance Mistakes on AWS

Applying on-premises core factors to EC2 vCPUs: This is the single most common mistake. Organisations that calculate Oracle licence requirements for AWS by applying Intel Xeon or AMD core factor (0.5) to the vCPU count are calculating at half the required quantity. The flat 2 vCPU rule for standard EC2 does not allow core factor adjustment.

Not licensing standby instances in Multi-AZ deployments: Every instance running Oracle — including standby, read replica, and data guard physical standby — requires full licence coverage unless a specific contractual exclusion exists. Multi-AZ and cross-region replica configurations routinely double the licence requirement relative to what was originally planned.

Creating PDBs beyond three without Multitenant option: Database teams optimising AWS RDS Custom or EC2 deployments for consolidation naturally create multiple PDBs. Without the Multitenant option, every PDB beyond three in any CDB creates an unlicensed Oracle deployment that Oracle LMS will find in an audit.

Ignoring test and development environments: Oracle does not provide free test and development licences under standard BYOL arrangements. Unless your Oracle contract contains specific language permitting non-production use without licence, every EC2 instance running Oracle — including dev, test, UAT, and staging — requires full licence coverage.

Deploying RAC on EC2 and expecting support: Organisations that have deployed Oracle RAC on EC2, whether through a lift-and-shift migration that did not account for cloud policy differences or through deliberate deployment, face two problems simultaneously: they are deploying an unsupported configuration, and they are deploying it without a valid licensing path. This situation must be resolved before Oracle runs an audit or before a critical incident surfaces that requires Oracle support engagement. Our Oracle audit defence specialists help organisations resolve this situation proactively before exposure becomes critical.

Recommended Assessment Approach

Before migrating Oracle database workloads to AWS, or if your AWS Oracle deployments have not been recently reviewed, a structured assessment covering the following areas is recommended. First, inventory all EC2 instances running Oracle software — including RDS and RDS Custom instances — and calculate the processor licence requirement using the 2 vCPU rule for standard EC2 or the Dedicated Host core factor approach where applicable. Second, identify all enabled database options — Partitioning, Advanced Compression, Active Data Guard, Multitenant, and others — and verify that each is covered by your current Oracle entitlements. Third, verify the PDB count in every CDB and confirm that any CDB with more than three PDBs has the Multitenant option licenced for the appropriate processor count. Finally, review any RAC deployments and assess the migration path to a supported high-availability alternative.

Redress Oracle licensing advisory specialists have reviewed AWS Oracle deployments for 500+ organisations and can help you assess compliance gaps, optimise licence configuration, and prevent costly audit exposure.