The Oracle License Math Before You Migrate to RDS

The Migration Pitch vs. Reality

The AWS pitch for RDS for Oracle sounds straightforward: stop managing the database infrastructure, let AWS handle patching and backups, and bring your existing Oracle license via BYOL. Infrastructure cost goes down, operational burden goes down, total cost goes down.

The reality is more complicated. AWS RDS for Oracle BYOL requires you to license Oracle based on the number of vCPUs on the RDS instance, using Oracle's processor licensing rules. If you're currently running Oracle on physical servers with a small number of licensed sockets — which is common in on-premises environments where teams have carefully minimized their Oracle footprint — moving to RDS can expose you to significantly more Oracle license cost than you're paying today.

We've reviewed Oracle-to-RDS migration proposals where the infrastructure savings were real ($200K/year in hardware and hosting costs), but the Oracle licensing delta was $340K/year more than the current on-premises spend. The net result: the migration made the bill worse, not better, and nobody ran the numbers before the project kicked off.

How Oracle Processor Licensing Works

Oracle sells Database licenses primarily on a per-processor basis. The "processor" unit is defined by Oracle's Processor Core Factor table — not by vCPU count in the cloud. The factor varies by chip architecture:

• Intel Xeon (most AWS instance families): factor of 0.5
• AMD EPYC (some AWS instance families): factor of 0.5
• IBM POWER: factor of 1.0
• Sun UltraSPARC T1/T2: factor of 0.25

The formula for on-premises physical servers: Processor Licenses = Physical Cores × Core Factor.

A 2-socket Intel server with 16 cores per socket = 32 physical cores × 0.5 = 16 Oracle processor licenses. Oracle Enterprise Edition at list price is $47,500 per processor license, so this server requires $760,000 in Oracle EE licenses (plus 22% annual support). Most organizations negotiate substantial discounts off list, but the core math is the same.

The Cloud Licensing Problem: No Partitioning Benefit

On physical servers, Oracle allows hard partitioning as a way to limit license exposure. Running Oracle on a capped LPAR (IBM Power with LPARs enabled for hard partitioning), or on an Oracle VM environment configured for hard partitioning, means you only license the cores allocated to the Oracle partition — not the entire physical server.

On AWS, Oracle does not recognize virtualization as hard partitioning. The official Oracle policy: when running Oracle in cloud environments (AWS, Azure, GCP) on non-Oracle hypervisors, you must license all vCPUs on the instance, using a factor of 0.5 per vCPU (with a minimum of 1 processor license per 2 vCPUs).

This is the trap. Here's a concrete example:

• Current on-premises: Oracle EE on a 2-socket server, 8 cores per socket, hard-partitioned LPAR using only 4 cores for Oracle = 4 cores × 0.5 = 2 Oracle processor licenses
• RDS for Oracle BYOL on db.r5.4xlarge (16 vCPUs): 16 vCPUs × 0.5 = 8 Oracle processor licenses

That's 4x the Oracle license exposure for a migration that was sold as "just lifting the database to the cloud."

RDS for Oracle License Included vs. BYOL

AWS offers two licensing models for RDS for Oracle:

License Included (LI): AWS bundles the Oracle license cost into the RDS hourly rate. You pay more per hour, but Oracle licensing is AWS's problem. Available for Oracle SE2 (Standard Edition 2) only, not Enterprise Edition.

Bring Your Own License (BYOL): You supply the Oracle license. Available for Oracle SE2 and EE. The RDS instance cost is lower, but you're responsible for ensuring your Oracle license covers the vCPU count on the instance.

License Included for SE2 is a clean model: AWS handles Oracle compliance. The problem is that SE2 has hard limits — maximum of 1 socket (or 2 sockets for RAC), and a 16-thread limit in 19c. If your workload requires EE features (Advanced Compression, Partitioning, RAC, Advanced Security, Diagnostics/Tuning Pack), SE2 isn't an option.

For EE workloads with BYOL, the math gets complicated quickly:

-- Oracle license exposure by RDS instance type (EE, BYOL)
-- Formula: vCPUs * 0.5 = processor licenses required

db.m5.xlarge   (4 vCPU)  =  2 processor licenses
db.m5.2xlarge  (8 vCPU)  =  4 processor licenses
db.r5.2xlarge  (8 vCPU)  =  4 processor licenses
db.r5.4xlarge  (16 vCPU) =  8 processor licenses
db.r5.8xlarge  (32 vCPU) = 16 processor licenses
db.r5.16xlarge (64 vCPU) = 32 processor licenses

-- Oracle EE list price: $47,500 per processor license
-- Annual support: 22% of license value
-- 5-year cost at db.r5.4xlarge (8 licenses):
--   License:  8 * $47,500 = $380,000
--   Support year 1-5: $83,600/year = $418,000
--   Total 5-year license cost: $798,000
-- (Plus actual RDS instance and storage costs)

The Right Way to Model Total Cost

Before any Oracle-to-RDS migration, build a full cost model with three components:

Component 1: Current Oracle license position. How many Oracle processor licenses do you currently own? What edition? What options (Partitioning, Advanced Compression, etc.)? What's the current annual support cost? Your Oracle CSI (Customer Support Identifier) has this information; pull it from MOS (My Oracle Support) or ask your Oracle license rep for a formal license position review.

Component 2: Required Oracle license position on RDS. Map your target RDS instance size to vCPUs, apply the 0.5 factor, and calculate how many processor licenses you need. Compare against what you currently own. If you need more licenses, calculate the cost at your actual negotiated price (not list — most enterprises are at 50-70% discount).

Component 3: Infrastructure delta. The RDS instance cost, storage, I/O, and data transfer costs minus your current hosting costs. This is where the savings typically live.

The migration makes financial sense only if Component 3 savings exceed the Component 2 licensing delta. If you're going from 4 licensed processors to 16 licensed processors, you need a substantial infrastructure savings to justify the move.

Strategies to Control Oracle License Exposure on RDS

If the migration makes architectural sense but the licensing math is unfavorable, there are several approaches to reduce exposure:

Right-size aggressively before migrating. The best time to negotiate a smaller Oracle footprint is before you move to the cloud, not after. If your database is running on an oversized on-premises server, work with your Oracle rep to reduce the license count to match actual usage. Then migrate to an RDS instance sized to match that reduced license count.

Use Dedicated Hosts to potentially claim hard partitioning. AWS Dedicated Hosts provide physical server isolation, but Oracle's position on whether Dedicated Hosts qualify as hard partitioning for licensing purposes is ambiguous as of this writing. Oracle's formal guidance is that hard partitioning is only recognized on Oracle-approved technologies. Consult your Oracle licensing specialist before claiming hard partitioning on Dedicated Hosts — Oracle audits cloud deployments and this is a common audit finding.

Evaluate Oracle SE2 with License Included. If your workload can run on SE2 (no EE-specific features required), the License Included model eliminates Oracle compliance exposure entirely. SE2 LI on RDS is appropriate for databases under moderate transaction load that don't use Oracle's premium options.

Consider Oracle on EC2 with Dedicated Hosts for large EE workloads. For large Oracle EE deployments where you need to control license count, EC2 with Dedicated Hosts gives you more control over the physical core count. You still need Oracle licensing, but you can potentially limit exposure to specific core counts by using instances that fill a Dedicated Host at the core count you want to license.

Model a migration off Oracle entirely. For workloads where Oracle EE features aren't truly required — where Oracle was chosen a decade ago and nobody has revisited the decision — Aurora PostgreSQL or RDS PostgreSQL often handles the workload. The migration cost is real, but so is permanently eliminating Oracle license spend. Our article on Oracle-to-Aurora migrations covers the conversion process in detail.

The License Audit Risk You're Accepting

Oracle audits cloud deployments more aggressively than on-premises environments. The LMS (License Management Services) team has cloud discovery tools that can identify Oracle instances running in AWS through integration with AWS APIs. If your cloud deployment exceeds your license position, Oracle's standard position is to require you to true up — purchase the additional licenses at full negotiated price, plus back-support for up to 5 years.

The financial exposure from an Oracle audit finding on an incorrectly sized cloud deployment can easily exceed the cost of doing the license math correctly before migration. Budget time for a proper license review as a mandatory pre-migration step.

A Sample Migration Cost Model

To make this concrete: assume a financial services firm running Oracle EE 19c on a 4-socket physical server with 12 cores per socket = 48 physical cores. They have 24 Oracle processor licenses (48 × 0.5). Annual Oracle support: ~$250K. On-premises hosting cost: ~$180K/year. Total annual Oracle-related spend: ~$430K.

Migration target: RDS db.r5.8xlarge (32 vCPUs) = 16 processor licenses. They own 24, so they have excess licenses. But if they size up to db.r5.16xlarge (64 vCPUs) for performance headroom, they need 32 processor licenses — 8 more than they own. At their negotiated price of $25K per EE license, that's $200K in additional license cost, plus $44K/year in additional support. The infrastructure savings are $100K/year. Year 1 net: -$144K. It takes over 2 years just to recover the additional license cost, even with infrastructure savings running.

The right answer in this scenario: either stay on db.r5.8xlarge (within existing license position) or evaluate whether the workload actually needs EE on that hardware footprint at all.