Short answer: Oracle licensing on AWS Dedicated Hosts follows Oracle's Authorized Cloud Environment policy — Oracle counts vCPUs, not physical cores, and the Core Factor Table does not apply. With hyper-threading on, 2 vCPUs equal one Oracle Processor license. A Dedicated Host exposes the physical server, but it gives no Oracle licensing discount versus a shared EC2 instance.
Key Takeaways
- AWS Dedicated Hosts use vCPU counting. Under Oracle's Authorized Cloud Environment policy, 2 vCPUs with hyper-threading on equal one Oracle Processor license — physical-core visibility does not change the rule.
- The Core Factor Table does not apply on AWS. The 0.5 factor that halves on-premise Intel core counts is unavailable, so equivalent compute consumes roughly double the licenses.
- Dedicated Hosts give no Oracle licensing advantage. For Oracle Database, a Dedicated Host and a default shared EC2 instance are counted identically — the Dedicated Host just costs more.
- Standard Edition 2 is the exception. SE2 is licensed by socket with a maximum, so host-level socket control on a Dedicated Host can matter for SE2 compliance.
- Lift-and-shift inflates license counts. Across our engagements, customers who moved Oracle Database to AWS without right-sizing used an average of 1.8x more Processor licenses than on-premise (Oracle Licensing Experts, 2026).
AWS Dedicated Hosts are one of the most misunderstood constructs in Oracle cloud licensing. Because a Dedicated Host hands you the physical server — sockets, cores, host affinity — engineers reasonably assume Oracle will let them license it like on-premise hardware, applying the Core Factor Table to physical cores. That assumption is wrong for Oracle on AWS, and acting on it produces under-licensing that surfaces in audit. This guide walks through how Oracle actually counts, when a Dedicated Host earns its premium, and how to avoid paying for licenses you do not need.
How Does Oracle License Software on AWS Dedicated Hosts?
Oracle licenses software on AWS Dedicated Hosts by counting vCPUs under its Authorized Cloud Environment policy. With hyper-threading enabled, two vCPUs equal one Oracle Processor license; with hyper-threading disabled, one vCPU equals one license. The Dedicated Host exposes physical sockets and cores, but Oracle still counts the vCPUs assigned to instances running Oracle software — not the host's total core inventory.
An AWS Dedicated Host is a physical EC2 server allocated entirely to one customer, exposing the underlying sockets, physical cores, and host affinity. It exists primarily so customers can satisfy license terms that require physical-core visibility — for example, certain Microsoft and per-socket products. For Oracle, that physical visibility is irrelevant to the count: the Authorized Cloud Environment policy overrides physical-core math with vCPU math, and AWS is a named authorized cloud in that policy.
Customers routinely provision Dedicated Hosts believing they have "bought back" on-premise core-factor economics. Oracle's audit teams know this misconception well — and quietly let it ride until the audit, when the vCPU count is reasserted and the shortfall becomes a back-license claim. The Dedicated Host gives you isolation, not a discount. Treat the vCPU count as the only number that matters for Oracle.
Does the Oracle Core Factor Table Apply on AWS Dedicated Hosts?
No. The Oracle Core Factor Table does not apply on AWS, including Dedicated Hosts. The Core Factor Table is the on-premise multiplier — typically 0.5 for modern Intel and AMD cores — that reduces the number of Processor licenses physical cores consume. Under Oracle's Authorized Cloud Environment policy, that table is explicitly excluded for AWS and Azure, and Oracle counts vCPUs directly instead.
This single exclusion is the most expensive surprise in Oracle cloud migrations. On-premise, a server with 16 physical Intel cores at the 0.5 core factor needs only 8 Oracle Processor licenses. On an AWS Dedicated Host presenting those same cores as 32 hyper-threaded vCPUs, Oracle counts 16 Processor licenses — double the on-premise requirement for identical hardware. Our Oracle vCPU counting guide works through these calculations across AWS, Azure, and GCP.
| Deployment | Counting basis | Core factor applied? | Processor licenses required |
|---|---|---|---|
| On-premise server | 16 physical cores | Yes (0.5) | 8 |
| AWS Dedicated Host | 32 vCPUs | No | 16 |
| AWS shared EC2 instance | 32 vCPUs | No | 16 |
| AWS EC2, HT disabled (16 vCPU) | 16 vCPUs | No | 16 |
Should I Use Dedicated Hosts or Default EC2 Instances for Oracle?
For Oracle Database Enterprise Edition, default shared-tenancy EC2 and Dedicated Hosts are counted identically — by vCPU under the Authorized Cloud Environment policy — so a Dedicated Host delivers no Oracle licensing advantage. It costs more per hour and adds capacity-management overhead. Choose a Dedicated Host only when a non-Oracle reason justifies it: compliance isolation, other vendors' BYOL terms, or socket-bound Standard Edition 2.
The decision should be made on total cost, not on a mistaken belief that Dedicated Hosts unlock the Core Factor Table. If your driver is purely Oracle cost reduction, the right levers are right-sizing the instance, disabling hyper-threading where the engine supports it, or evaluating OCI — where Oracle applies its own, more favorable counting. Compare those paths in our Oracle BYOL on AWS EC2 vs RDS guide.
How Does Oracle Standard Edition 2 Work on AWS Dedicated Hosts?
Standard Edition 2 is the one place where a Dedicated Host can genuinely help. Oracle Database SE2 is licensed per socket, with a maximum of two sockets (or one socket per Oracle's AWS-specific SE2 rules, which cap SE2 at a defined vCPU ceiling). Because a Dedicated Host gives you control over the physical socket topology and instance placement, it can keep an SE2 deployment inside Oracle's authorized boundaries when a shared instance might not.
Under Oracle's Authorized Cloud Environment rules, SE2 on AWS is constrained to a maximum number of vCPUs that maps to Oracle's socket limit. Exceeding that ceiling either forces an upgrade to Enterprise Edition pricing or creates a compliance gap. SE2 placement and shape selection on AWS is genuinely intricate, and getting it wrong is costly. Our Oracle SE2 cloud socket rules guide covers the precise vCPU ceilings.
Running Oracle on AWS Dedicated Hosts?
Our Oracle Cloud advisory service verifies your exact vCPU-based license count and tells you whether a Dedicated Host is helping or just costing you more.
Can I Use the Core Factor Table on AWS Bare Metal Instead?
This is contested territory. AWS bare metal instances (the .metal shapes) expose the full physical server with no hypervisor, which leads some advisors to argue that Oracle's on-premise rules — including the Core Factor Table — should apply because there is no virtualization layer to abstract the cores. Oracle's Authorized Cloud Environment policy, however, still nominally counts vCPUs even on AWS.
The practical reality: any claim that you can apply the 0.5 core factor on AWS bare metal is high audit risk and must be validated against your specific Oracle contract before you rely on it. Oracle has shown no willingness to formally concede core-factor treatment on AWS, and an LMS auditor will assert the vCPU count by default. If bare-metal core-factor savings are material to your business case, get the position confirmed in writing before deployment. Our Oracle compliance review service stress-tests these positions against current Oracle policy and audit behavior.
How Does BYOL Work for Oracle on AWS Dedicated Hosts?
BYOL (Bring Your Own License) on AWS means applying perpetual Oracle licenses you already own to your EC2 or Dedicated Host deployment, rather than buying license-included capacity. On AWS, BYOL is the standard model for Oracle Database EE because AWS does not resell Oracle Database licenses. The licenses must be on active Oracle support, and the vCPU count must be fully covered by your entitlement.
The compliance discipline is identical to any authorized cloud BYOL: each license covers one running deployment, the vCPU footprint sets the required count, and third-party support breaks BYOL eligibility because Oracle requires active support for cloud use. For the full mechanics of moving licenses to the cloud, see our Oracle BYOL guide and the cluster Oracle Cloud Licensing Guide.
A financial services firm provisioned 40 AWS Dedicated Hosts for Oracle Database, expecting on-premise core-factor economics. A pre-audit review showed Oracle would count vCPUs — a projected 96-license shortfall. By right-sizing shapes and consolidating workloads before Oracle's review, the firm closed the gap without buying additional licenses. See our cloud migration case studies for similar outcomes.
Frequently Asked Questions
How does Oracle license software on AWS Dedicated Hosts?
AWS Dedicated Hosts fall under Oracle's Authorized Cloud Environment policy, so Oracle counts vCPUs, not physical cores: with hyper-threading on, 2 vCPUs equal one Oracle Processor license. The Core Factor Table does not apply. A Dedicated Host exposes the underlying physical server, but Oracle still licenses by the vCPUs allocated to instances running Oracle software, not the host's full core count.
Does the Oracle Core Factor Table apply on AWS Dedicated Hosts?
No. Under Oracle's Authorized Cloud Environment policy, the Core Factor Table does not apply to AWS, including Dedicated Hosts. Oracle counts vCPUs directly. The 0.5 core factor that reduces on-premise Intel core counts is unavailable in AWS, which is why lift-and-shift migrations frequently increase Oracle license consumption versus on-premise deployments.
What is an AWS Dedicated Host?
An AWS Dedicated Host is a physical EC2 server fully dedicated to a single customer, giving visibility into and control over the underlying sockets, physical cores, and host affinity. It is commonly used for license-sensitive workloads and for BYOL of vendors that require physical-core visibility. For Oracle, however, the Authorized Cloud Environment vCPU rules still apply.
Should I use Dedicated Hosts or default EC2 instances for Oracle?
For Oracle Database, default shared-tenancy EC2 and Dedicated Hosts are counted the same way — by vCPU under the Authorized Cloud Environment policy — so Dedicated Hosts give no Oracle licensing advantage. They cost more and add management overhead. Choose them only for non-Oracle BYOL needs, compliance isolation, or socket-bound Standard Edition 2 scenarios where host control matters.
Can I use the Core Factor Table on AWS bare metal instead?
This is contested. AWS bare metal instances expose full physical hardware, and some advisors argue the Core Factor Table should apply because no virtualization layer abstracts the cores. Oracle's Authorized Cloud Environment policy still nominally counts vCPUs. Treat any core-factor claim on AWS as high audit risk and validate it against your specific contract before relying on it.
How much can Oracle on AWS Dedicated Hosts cost versus on-premise?
Because the Core Factor Table does not apply, equivalent compute on AWS typically consumes about twice the Oracle Processor licenses of an on-premise Intel deployment. Across our engagements, customers moving Oracle Database to AWS without right-sizing consumed an average of 1.8x more Processor licenses than their on-premise baseline (Oracle Licensing Experts, 2026).