The core factor does not travel, and that doubles the bill
Oracle Database on Amazon Web Services is counted by vCPU, not by core, and the Oracle core factor table does not travel with the workload. That single rule means the same physical hardware carries roughly twice the Oracle license requirement on AWS that it carries in your own data center. AWS sits on Oracle's Authorized Cloud Environment list: two vCPUs equal one processor with hyperthreading on, one vCPU equals one with it off, and the 0.5 multiplier is simply gone.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on roughly 30 to 40 Oracle on AWS estates reviewed 2024 to 2025.
Executive summary
Lifting an unchanged estate to EC2 doubles the Oracle requirement on identical hardware. A 48 core server needs 24 processor licenses on premises at the 0.5 core factor and 48 on AWS, because the multiplier stops at the Authorized Cloud Environment boundary and you gain nothing in exchange.
Two vCPUs equal one Oracle processor where hyperthreading is on, one vCPU equals one where it is off, so disabling hyperthreading on EC2 halves your compute and saves not a single license.
Named User Plus keeps its 25 per processor minimum, counted on the AWS processor number, so an 8 processor instance already carries a 200 user floor before anyone logs in.
Memory density is the largest single license lever on EC2, and it moves the bill by up to sixteen times.
Most Oracle databases are memory bound, not thread bound, and teams reach a memory target by buying a bigger instance in the family they already use, which on AWS buys Oracle licenses it does not need.
Reaching 256 GiB on a memory dense x2iedn instance needs 4 processor licenses; the same 256 GiB on an r6i needs 16, and on a compute optimized c6i, 64, roughly 190,000 dollars against 760,000 against 3,040,000 in EE list.
In the estates we reviewed, moving a memory bound database from a general purpose family to a memory dense one removed 40 to 70 percent of the processor count with no commercial negotiation at all.
RDS is a compliance decision dressed as a deployment option, and the choice sticks for the life of the instance.
License included is Standard Edition 2 only, with the audit obligation sitting with AWS; bring your own license runs SE2 or Enterprise Edition, counted on the instance class vCPU, with the audit obligation staying with you in full.
The policy caps SE2 at 8 Amazon vCPUs, and that ceiling, not performance, is what usually forces a database onto Enterprise Edition, which is a jump to a different price list with a separate options catalog, not an increment.
The RDS traps are the standby and the replica: Multi AZ under bring your own license needs entitlement for both nodes, and read replicas run Active Data Guard, a separately licensed EE option billed on the replica's vCPU as well as the primary's.
The policy governs counting on EC2 and RDS and nothing else, and its boundaries are where the arguments happen.
Engineered Systems, most Applications, Java, VMware Cloud on AWS and Oracle Database@AWS all sit outside the vCPU mapping: Java prices on the employee metric, Oracle Database@AWS is licensed as an Oracle cloud service.
And VMware Cloud on AWS is contested, with the practical position that a dedicated bare metal software defined data center counts as physical hosts under the partitioning rules.
The cloud policy carries the same educational purposes footer as the partitioning document, which cuts both ways: it is not a clause you signed, and Oracle applies it consistently anyway, so count to the policy and negotiate the commercial terms instead.
Inside and outside the Authorized Cloud Environment boundary
| Deployment | Governed by | How it counts |
|---|---|---|
| Database or Middleware on EC2 | Cloud licensing policy | vCPU mapping, no core factor |
| RDS for Oracle, bring your own license | Cloud licensing policy | vCPU of the instance class |
| RDS for Oracle, license included | AWS service terms | Per instance hour, no Oracle entitlement |
| Java SE on AWS | Java Universal Subscription | Employee metric, not vCPU |
| Oracle Applications on EC2 | Program specific terms | Application metric, read the ordering document |
| VMware Cloud on AWS | Contested, treat as VMware | Physical hosts in the software defined data center |
| Oracle Database@AWS | Oracle cloud service terms | Service metric or bring your own license |
The three governing rules are short: two vCPUs equal one processor with multithreading on, one vCPU equals one with it off, and the 0.5 Intel and AMD multiplier does not apply to AWS compute at all. The edge cases catch most estates.
Reserved Instances and Savings Plans are AWS commercial commitments that reduce the Oracle footprint by zero; a Spot instance carries a full processor obligation for as long as it runs; a Data Guard standby applying redo is installed and running, so it is licensed idle or not.
An Auto Scaling group is counted at its peak concurrent instance count, not the average; and Dedicated Hosts and bare metal are still counted on instance vCPU, so the core factor relief does not reappear on metal.
The full cross hyperscaler ruleset sits in Oracle licensing in cloud environments.
Converting vCPUs to licenses, and the memory lever
- The arithmetic is mechanical: take the instance vCPU count, halve it where hyperthreading is on, round up. An r6i.8xlarge at 32 vCPUs is 16 Oracle processors; an x2iedn.2xlarge at 8 vCPUs and 256 GiB is 4.
- The hyperthreading trap: an r6i.4xlarge is 8 processors at 16 vCPUs with threads on, and still 8 processors at 8 vCPUs with threads off, because the policy switches to one to one the moment multithreading is disabled. Turning threads off halves the compute and never saves a license.
- Memory density is the largest lever: reaching 256 GiB costs 4 processors on x2iedn, 16 on r6i, 32 on m6i and 64 on c6i. Same memory, same database, up to a sixteen fold spread in Oracle list cost, and the instance hour premium on the dense family is nowhere near enough to close it.
- Clock speed is the second lever: a throughput bound workload can often run on half the vCPUs of a general purpose family on a high frequency one. Graviton is not an option, Oracle Database is not offered on AWS ARM classes, and burstable T family credits do not reduce the count, which is set by the vCPU the instance presents.
- Run the comparison on total cost, not instance rate, and price the same physical machine both ways before you sign the migration business case. AWS does not change what Oracle costs per core; it changes how many cores Oracle is allowed to count, and the answer is all of them. The multiplier rules sit in the core factor analysis.
Oracle multicloud and universal credits
Bring your own license and universal credits across AWS, Azure, and Google Cloud, worked end to end.
Get the white paper →The audit traps that recur on AWS estates
Oracle targets AWS estates because the vCPU question is widely misread and easy to verify remotely, and five findings account for most of what we see. Hyperthreading state is assumed rather than checked, so the two vCPU rule gets applied to an instance running single threaded, or the reverse.
An oversized instance solves a memory problem by doubling the license footprint for capacity nobody uses. A forgotten read replica or cross region standby runs with no matching license source.
Options spread from a golden image, Partitioning, Advanced Compression or the Diagnostics Pack enabled in an AMI and inherited by every instance built from it. And the Named User Plus floor is counted against on premises processors rather than the AWS number.
The defense moves are the mirror image: inventory the tenancy properly with every binary, region, replica and Auto Scaling peak dated; run the options scan per instance and reconcile every flag to an entitlement; verify hyperthreading from the running instance rather than the instance name.
Reconcile an active Customer Support Identifier behind every deployed license; and price the gap before Oracle does, because a settlement opened on your numbers lands very differently from one opened on the auditor spreadsheet.
On discounts, Oracle treats AWS as competitive ground, with Enterprise Edition base at 60 to 75 percent off, options at 40 to 70, and the support renewal uplift holdable at 0 against an 8 percent default with discipline.
Treat the support line as the real negotiation, because a license discount is a single event while the uplift compounds for as long as you hold the estate; the wider commercial levers sit in Oracle cloud negotiations.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Oracle on AWS estates, 2024 to 2025
Across roughly 30 to 40 Oracle on AWS estates Fredrik Filipsson reviewed in 2024 and 2025, the licensed core count ran 20 to 35 percent above what the workload actually required, and the standard advice failed the same way each time.
The standard advice is that moving Oracle to AWS is a cost reduction because you retire hardware and stop paying for a data center. We disagree, at least on the Oracle line:
Median licensed cores removed, through memory dense families, right sized vCPU counts, and options stripped to actual use, not through relocation.
The Oracle license multiple on an unchanged lift and shift to EC2, from losing the 0.5 core factor and gaining nothing in exchange.
The migrations that saved money on Oracle did so through re-sizing, not relocation: memory dense instance families, right sized vCPU counts, options stripped back to what was actually used, and steady state databases moved to bring your own license.
The buyers who treated AWS migration as an infrastructure project and left the Oracle sizing to the platform team paid for the mistake twice, once in licenses and once in the support stream that follows them.
RDS carries its own reversed intuition: license included looks safer because the compliance question disappears, but on any database running more than a few hours a day the premium inside the hourly rate ran 10 to 18 percent above a bring your own license position.
So meter real running hours for two billing cycles and split the estate deliberately, license included for spiky and short lived, bring your own license for steady state.
The related entitlement question underneath all of it sits in the bring your own license guide, and the on premises counterpart in the partitioning policy.
Your first five moves
- Recount the processors from the vCPU, not the old on premises number: the core factor is gone, so a carried forward count is almost always wrong, usually by half.
- Test every memory bound database against a memory dense family: the largest single saving available, and it needs no commercial negotiation, removing 40 to 70 percent of the processor count in our reviews.
- Run the options usage scan and strip what is not used: every flagged option needs an entitlement or a documented reason it is switched off, especially anything inherited from a golden image.
- Split the RDS estate on metered hours: license included for spiky and short lived, bring your own license for steady state, decided on two billing cycles of real running hours.
- Open the Oracle conversation on your data: priced, documented and reviewed independently before anyone at Oracle asks for a script output. The Oracle practice runs it buyer side.
Frequently asked questions
Is AWS an Authorized Cloud Environment for Oracle Database?
Yes. Amazon Web Services sits alongside Microsoft Azure and Google Cloud on Oracle's cloud licensing policy list.
The policy governs the vCPU to processor mapping for Database, Middleware and a defined set of Oracle Technology programs, while Engineered Systems, most Oracle Applications, Java, VMware Cloud on AWS and Oracle Database@AWS all sit outside it and count under their own rules.
How do I count Oracle processors on an EC2 instance?
Take the instance vCPU count, halve it where hyperthreading or multithreading is enabled, and round up. Two vCPUs equal one Oracle processor with threads on, one vCPU equals one with threads off, and the 0.5 core factor that applies on premises does not apply on AWS at all.
So a 32 vCPU r6i.8xlarge is 16 Oracle processors, and the Named User Plus minimum of 25 per processor is counted on that AWS number.
Does moving Oracle to AWS save money?
Not by relocation alone. Lifting an unchanged Oracle estate to EC2 typically doubles the processor requirement because you lose the 0.5 core factor and gain nothing in exchange.
The migrations that saved money in our reviews did so through re-sizing: memory dense instance families, right sized vCPU counts, options stripped to actual use, and steady state databases on bring your own license. Median licensed cores removed was 28 percent, none of it from the move itself.
Why does memory density change the Oracle license count on AWS?
Because the license is bought per vCPU, and different instance families deliver very different memory per vCPU.
Reaching 256 GiB costs 4 processor licenses on a memory dense x2iedn, 16 on an r6i, 32 on an m6i and 64 on a compute optimized c6i, a sixteen fold spread for the same memory and the same database.
Since most Oracle databases are memory bound, choosing the dense family removes 40 to 70 percent of the processor count with no negotiation.
How does licensing work on Amazon RDS for Oracle?
RDS ships in two modes. License included is Standard Edition 2 only, with the Oracle license in the hourly rate and the audit obligation on AWS. Bring your own license runs SE2 or Enterprise Edition, counted on the instance class vCPU, with the audit obligation on you.
The policy caps SE2 at 8 Amazon vCPUs, and that ceiling usually forces the step to Enterprise Edition, which is a different price list with a separate options catalog, not an increment.
Does disabling hyperthreading on EC2 reduce Oracle licenses?
No. Disabling hyperthreading switches the policy from the two vCPU mapping to a one to one mapping, so the Oracle processor count stays identical while you halve the compute you get for it. An r6i.4xlarge is 8 Oracle processors whether it runs 16 threaded vCPUs or 8 single threaded ones.
Disabling threads is a legitimate performance move on some workloads and is never a licensing saving on Oracle.
