Oracle Licensing on AWS RDS: Rules, BYOL vs License Included, and Cost Traps

How Amazon RDS for Oracle Works

Amazon RDS for Oracle is AWS's managed database service for Oracle Database. AWS handles the infrastructure, patching, backups, and availability management, while you retain control of database configuration, users, and application connections. RDS for Oracle supports Oracle Database Standard Edition 2 (SE2) and Enterprise Edition (EE), subject to the licensing constraints described below.

The primary appeal of RDS over self-managed Oracle on EC2 is reduced operational burden — AWS handles OS patching, database backups, and Multi-AZ failover automatically. The licensing complexity, however, remains entirely the customer's responsibility in the BYOL model. Understanding the interaction between AWS's infrastructure management and Oracle's licence requirements is the core challenge of RDS Oracle licence management.

The Two RDS Oracle Licensing Options

License Included (LI)

In the License Included model, AWS bundles the Oracle software licence into the per-hour RDS instance price. You pay a higher hourly rate than a comparable EC2 instance, but you do not need to hold a separate Oracle licence. AWS licences the Oracle software on your behalf and is responsible for licence compliance on the AWS side of the infrastructure.

The critical restriction: License Included is available only for Oracle Database Standard Edition 2. Oracle Database Enterprise Edition is not available under the License Included model. If your application requires EE features (Real Application Clusters, Advanced Security, Partitioning, or any EE-only option), License Included is not a viable option, and you must use BYOL.

License Included also carries a restriction on use: the AWS service terms (Section 10.3.1) specify that the included Oracle licence is for your internal use only. You may not use an RDS License Included instance to provide database services to external third parties or as part of a hosted service offering for customers. Organisations providing managed services or hosting Oracle applications for clients must use BYOL.

Bring Your Own Licence (BYOL)

In the BYOL model, you apply your existing perpetual Oracle Database licences (SE2 or EE) to the RDS instance. You pay the base RDS infrastructure cost without a licence surcharge, but you must hold sufficient Oracle licences to cover the RDS instance and remain compliant with Oracle's licence terms. The BYOL model requires the associated Software Update Licence and Support (SULS) to be active — Oracle support escalating at 8% per year must be current for the licences applied to RDS.

BYOL is the only model available for Oracle Database Enterprise Edition on RDS. For SE2, BYOL is an alternative to License Included and may be more cost-effective if you already hold SE2 licences with active support.

vCPU Counting Rules for RDS BYOL

When applying BYOL licences to Amazon RDS for Oracle, Oracle's Authorised Cloud Environment policy governs how Processor licences are counted. The standard on-premises counting method (physical cores × Core Factor) does not apply. Instead, Oracle applies a vCPU-to-Processor conversion.

For Oracle Enterprise Edition BYOL on RDS: 2 vCPUs on the RDS instance equal 1 Oracle Processor licence. An RDS instance with db.r6g.4xlarge (16 vCPUs) requires 8 Oracle Processor licences. The Core Factor Table is not used in Authorised Cloud Environments — the 2:1 vCPU ratio replaces it entirely.

For Oracle Standard Edition 2 BYOL on RDS: SE2 is licensed per server in Oracle's standard on-premises model. In the RDS context, AWS defines SE2 as requiring licences based on the RDS instance size, with Oracle permitting up to 16 vCPUs on SE2 instances (corresponding to 2 processor sockets in the on-premises model). SE2 BYOL on RDS is therefore subject to both the socket limit constraint and the vCPU-based counting for the specific RDS instance class selected.

Multi-AZ Deployments and Licence Doubling

Multi-AZ deployment is one of the most common and most expensive Oracle licence traps in the RDS environment. When you enable Multi-AZ on an RDS for Oracle BYOL instance, AWS automatically creates and maintains a synchronous standby replica of your primary database in a different Availability Zone. The standby instance is fully managed by AWS and provides automatic failover in case of a primary failure.

From Oracle's licence perspective, the standby RDS instance is an Oracle Database installation that is installed and capable of running Oracle software. Oracle therefore requires the standby instance to be licensed with the same licence count as the primary instance. Multi-AZ BYOL effectively doubles your Oracle Processor licence requirement compared to a single-AZ deployment.

For an organisation running a db.r6g.4xlarge RDS EE BYOL instance (8 Processor licences) with Multi-AZ enabled, the total Oracle licence requirement is 16 Processor licences — 8 for primary, 8 for standby. Organisations that enable Multi-AZ on BYOL instances without accounting for the standby licence requirement are underl icensed from the moment they enable the feature.

The Multi-AZ licence requirement applies regardless of whether the standby instance has ever been used, has ever processed a query, or has ever received a failover. Oracle's position is that installation equals use for licence purposes. The standby instance is installed and ready — that is sufficient.

Comparing License Included vs BYOL: Cost Analysis Framework

Deciding between License Included and BYOL for Oracle SE2 on RDS requires a comparison of total cost over the expected instance lifetime.

License Included Cost Structure

LI pricing bundles the Oracle SE2 licence cost into the hourly RDS instance rate. As a rough guide, the LI surcharge over the equivalent base infrastructure cost represents approximately 30 to 50 percent premium on smaller instance types. For a continuously running instance over a three-year period, this premium is significant. However, LI requires no upfront Oracle licence investment, no ongoing Oracle support fee (that is AWS's obligation), and no exposure to Oracle licence audits on the licensed products.

BYOL Cost Structure

BYOL pricing charges only the RDS infrastructure cost (typically 30 to 50 percent lower than the LI equivalent). However, you must hold SE2 licences with active SULS support. Oracle support fees escalate at 8% per year. Over a three-year period, the compounding support cost can be substantial, particularly for organisations that purchased SE2 licences several years ago at a time when support fees were lower in absolute terms.

BYOL becomes cost-effective when: you already hold SE2 licences with active support; the licences are not being fully utilised on-premises and can be repurposed for RDS without purchasing new licences; or you have a ULA or PULA that covers SE2 at no incremental licence cost.

The Break-Even Calculation

To determine whether BYOL or LI is more cost-effective for your specific situation, calculate the total cost of each model over the planned instance lifetime, including LI hourly rates (including the licence surcharge), BYOL hourly rates plus the amortised Oracle licence cost, annual SULS support at 8% escalation, and any new licence purchase cost if BYOL requires acquiring additional licences. The model that produces the lower total cost over the planned period is the right choice — and the answer varies significantly by instance size, utilisation pattern, and existing licence position.

Common Oracle RDS Licensing Mistakes

Enabling Multi-AZ BYOL without accounting for standby licences. This is the most common and most expensive Oracle RDS mistake. Multi-AZ doubles the Processor licence requirement. Before enabling Multi-AZ on BYOL instances, confirm you hold sufficient licences for both primary and standby.

Using LI for EE workloads. License Included is not available for Enterprise Edition. Organisations that select RDS EE without understanding the BYOL requirement face an immediate compliance gap. EE on RDS requires BYOL with active EE Processor licences and support.

Applying on-premises Core Factor counting to RDS. The Oracle Core Factor Table does not apply in Authorised Cloud Environments. The RDS BYOL licence count is based on vCPUs at a 2:1 ratio, not physical cores. Applying the Core Factor to RDS vCPUs produces an incorrect — and lower — licence count.

Not accounting for RDS instance changes. When an RDS instance is resized to a larger instance type with more vCPUs, the Oracle licence requirement increases proportionally. Instance resize decisions should be reviewed against the BYOL licence position before implementation.

Treating RDS LI as eliminating all Oracle audit risk. LI eliminates audit risk for the specific Oracle products covered by the LI licence (SE2 in this case). It does not eliminate audit risk for Oracle software deployed elsewhere in the estate — on EC2, on-premises, or in other cloud environments. A comprehensive Oracle licence management programme covers the full estate, not just RDS.

RDS Oracle and ULA Certification

Organisations under a ULA that includes Oracle Database EE should assess whether RDS BYOL deployments made during the ULA term should be included in the certification count. ULA certification counts all Oracle deployments at the certification date — including RDS BYOL instances. Customers who have deployed Oracle on RDS BYOL during a ULA term should include those deployments in their pre-certification inventory and maximise any outstanding deployment capacity before the certification date.

Remember: every Oracle deployment added before ULA certification converts to perpetual licence value at no additional licence cost. This includes RDS BYOL instances. Customers who have unused ULA deployment capacity and planned RDS expansions should time those deployments before certification rather than after, to maximise the perpetual entitlement captured at certification.

Practical Recommendations for RDS Oracle Licence Management

Run a quarterly inventory of all RDS Oracle instances, capturing instance class, vCPU count, Multi-AZ status, and licensing model (BYOL or LI). Map BYOL instances against Oracle licence entitlements to confirm sufficient coverage. Flag any instance resizes that have changed vCPU count since the last review. Ensure Multi-AZ BYOL instances have twice the licence coverage of the instance's primary vCPU count.

For new RDS deployments, perform the BYOL vs LI cost analysis using your current licence position and SULS rates before provisioning. Do not default to BYOL because it appears cheaper on the infrastructure side — the total cost including Oracle support must be included. Do not default to LI for SE2 without confirming whether existing BYOL licences can be repurposed at a lower total cost.