2 vCPU
= 1 Oracle Processor licence on AWS & Azure with hyper-threading on (Oracle ACE policy, 2026)
Bring Your Own License moves your owned Oracle licences onto AWS and Azure — but Oracle's Authorized Cloud Environment policy counts 2 vCPUs as 1 Processor licence, strips out the Core Factor Table, and lives in a policy document Oracle can rewrite. This 2026 guide sets out the BYOL counting math, the standby-and-DR traps, Oracle Database@AWS and Database@Azure, and the buyer-side moves that stop you double-paying.
Not affiliated with Oracle Corporation.
Home › Oracle Cloud Licensing › White Papers › Oracle BYOL on AWS & Azure
Oracle BYOL on AWS and Azure lets you apply owned, supported Oracle licences to cloud VMs, but Oracle's Authorized Cloud Environment policy counts 2 vCPUs as 1 Processor licence when hyper-threading is on (1 vCPU = 1 licence when off) and the Core Factor Table does not apply. That counting rule, plus standby databases that need full licences, is where buyers double-pay. Keep support active, count vCPUs forensically, and get Oracle's rule in writing before you migrate.
BYOL on AWS and Azure is a licence-counting problem before it is a migration project. Each role owns a piece of getting the count — and the contract — right before a single instance launches.
Oracle's Authorized Cloud Environment policy counts 2 vCPUs as 1 Processor licence on AWS and Azure when hyper-threading is enabled, and 1 vCPU as 1 Processor licence when it is disabled. The on-premises Core Factor Table does not apply, so an Intel core that counted as 0.5 on-prem effectively counts as a full licence per 2 vCPUs in the cloud. The same workload therefore needs more Oracle licences in AWS or Azure than it did on owned hardware.
An Authorized Cloud Environment is Oracle's policy designation for AWS, Microsoft Azure and Google Cloud, where BYOL is counted by vCPU rather than by physical core and Core Factor. Most enterprises miscount because they carry the on-prem 0.5 x86 multiplier into the cloud model — it does not survive the move. Our Oracle cloud licensing guide walks the per-product vCPU rules, and the Oracle licensing in public cloud guide shows where the counting gaps cluster across AWS, Azure and GCP.
The Core Factor Table is an on-premises multiplier that discounts physical-core counts by hardware type — 0.5 for most x86 cores. Oracle's cloud policy explicitly replaces it with a flat vCPU count and forbids stacking the 0.5 multiplier on top. So a 16-core on-prem Intel server licensed as 8 Processors becomes a 32-vCPU cloud instance counted as 16 Processor licences. Same compute, double the licences, purely because of how Oracle defines cloud counting.
This is the single most expensive surprise in a BYOL migration. Buyers budget against their on-prem Processor count, lift the workload to an equivalently sized cloud instance, and discover the licence requirement has doubled. The defence is forensic: count vCPUs per instance, confirm hyper-threading, and model the cloud count before the platform decision is made — not after the invoices arrive. Our Oracle license optimization practice rebuilds the count instance-by-instance.
Yes. The right to move owned Oracle licences to AWS or Azure under BYOL is conditional on maintaining active technical support on those licences. Let support lapse and the BYOL right falls away, the cloud deployment becomes unlicensed, and reinstating support later carries back-support fees plus a reinstatement penalty. Support is not an optional line item in a BYOL model — it is the thing that makes BYOL legal.
Buyers sometimes try to drop support on "shelfware" licences they have redeployed to the cloud, not realising that move quietly voids the entitlement they are relying on. Keep the certificate of support current, keep the CSI active, and keep evidence of both. If the goal is to cut the 22% support stream, the route is a deliberate third-party support or right-sizing strategy — not silently dropping support under live BYOL workloads.
A Data Guard standby in AWS or Azure that is open read-only, or continuously applying redo, must be fully licensed at the same edition and options as the primary. Oracle's 10-day failover rule — ten 24-hour periods per year of unlicensed failover — is built for an active-passive cluster sharing storage on-premises and does not extend to a separate cloud DR region. Most cloud DR designs therefore need their own licences, not a free pass.
This is the second classic BYOL trap. Teams assume a DR standby is "free" under the 10-day rule, stand it up in a second cloud region, and create a fully chargeable deployment. The rule is narrower than its reputation: it covers true cluster failover to a spare node in the same on-prem cluster, not a continuously recovering standby in a different data centre. A dormant, stopped instance consumes nothing; a mounted, recovering standby does. Our Oracle audit defense team regularly pushes back on back-licence claims built on misread DR rules.
Oracle Database@AWS and Oracle Database@Azure run OCI Exadata and Autonomous Database on Oracle-managed infrastructure physically inside the hyperscaler's data centres. Because the database runs on OCI infrastructure, the favourable OCI BYOL counting (1 Processor licence per 2 OCPUs) and Support Rewards apply instead of the 2-vCPU Authorized Cloud Environment rule. They convert "AWS or Azure BYOL" into a third path with OCI economics and hyperscaler adjacency.
Oracle Database@AWS reached general availability on 8 July 2025 and, by April 2026, was live in twelve AWS regions including N. Virginia, Oregon, Ohio, Frankfurt, Tokyo, Dublin, London, Mumbai, Hyderabad and Seoul. Oracle Database@Azure is generally available across 22 Azure regions — the widest hyperscaler footprint — with BYOL and Support Rewards both honoured through the marketplace. These are not native EC2 or Azure VM deployments: they are OCI inside the hyperscaler, so Oracle, not AWS or Microsoft, controls the licence terms. See the OCI vs AWS decision framework for the side-by-side counting math.
The core BYOL decision is whether to lift Oracle onto native AWS/Azure VMs under the 2-vCPU rule, or onto Database@AWS / Database@Azure under OCI counting plus Support Rewards. Lead with the licence math, then weigh adjacency and skills.
Large Enterprise Edition estate · RAC / Exadata / 23ai needed · high on-prem support bill to offset with Support Rewards · want OCI counting (2 OCPU per licence) · need a region Oracle already serves.
Small or SE2-eligible footprint · heavy native-service integration · AWS/Azure-centric skills · workload right-sized so the 2-vCPU penalty is tolerable · no need for Exadata-class features.
Take a 16-core on-prem Intel server running Enterprise Edition. On-prem, the 0.5 Core Factor makes it 8 Processor licences. Lifted to a 32-vCPU cloud instance with hyper-threading on, the same workload is counted at 16 Processor licences — double — because the Core Factor is gone. Right-sizing to 16 vCPUs before migrating halves that back to 8. The bars below show the licence requirement for the same application under each approach.
Illustrative count under Oracle's 2-vCPU ACE rule, hyper-threading enabled. Representative scenario (benchmark, not a quote) — Oracle Licensing Experts engagement data, 2026.
BYOL does not mean bring your old Core Factor — the cloud counts vCPUs, and the licence you thought you owned can cover half the cores it used to.
| Factor | AWS (EC2 BYOL) | Azure VM (BYOL) | Database@AWS / @Azure |
|---|---|---|---|
| BYOL counting (EE) | 2 vCPU / licence (HT on) | 2 vCPU / licence (HT on) | 2 OCPU / licence (OCI rule) |
| Core Factor Table | Does not apply | Does not apply | N/A (OCPU-based) |
| Support Rewards | None | None | $0.25–$0.33 / $1 |
| RAC / Exadata / 23ai | Limited (self-managed) | Limited (self-managed) | Native (OCI infrastructure) |
| Active support required | Yes | Yes | Yes |
| Region footprint (2026) | Global | Global | 12 AWS / 22 Azure regions |
| Who controls licence terms | Oracle policy | Oracle policy | Oracle (OCI inside cloud) |
| Path | Strength | Caution |
|---|---|---|
| AWS EC2 BYOL | Reuse owned licences; rich AWS ecosystem and skills | 2-vCPU penalty; no Core Factor; no Support Rewards |
| Azure VM BYOL | Reuse owned licences; Microsoft estate adjacency | Same 2-vCPU count; standby/DR licensing easily mis-modelled |
| AWS RDS License Included | No BYOL counting; AWS holds the licence | Standard Edition 2 only; not for EE at scale |
| Database@AWS / @Azure | OCI counting + Support Rewards + native adjacency | Region-limited; Oracle, not the hyperscaler, controls terms |
Oracle's Authorized Cloud Environment policy counts 2 vCPUs as 1 Processor licence when hyper-threading is enabled, and 1 vCPU as 1 Processor licence when it is disabled. This applies identically on AWS, Azure and Google Cloud. The on-premises Core Factor Table does not apply, so the same core count needs more licences in the cloud than it did on owned hardware.
No. The Oracle Processor Core Factor Table applies only to on-premises deployments. In any Authorized Cloud Environment — AWS, Azure or GCP — Oracle replaces it with a flat vCPU count and forbids stacking the 0.5 multiplier on top. Carrying the Core Factor into a cloud business case is one of the most common and costly BYOL counting errors we see.
Yes. BYOL is conditional on maintaining active technical support on the licences you move to AWS or Azure. If support lapses, the BYOL right falls away and the cloud deployment becomes unlicensed. Reinstating support later carries back-support fees and a reinstatement penalty, so support must stay in the BYOL budget for the life of the workload.
Generally no. The 10-day rule covers true active-passive cluster failover on-premises, not a continuously recovering standby in a separate cloud region. A Data Guard standby that is open read-only or applying redo must be fully licensed at the same edition and options as the primary. A dormant, stopped instance consumes nothing, but a mounted, recovering one does.
Plain BYOL on AWS EC2 runs Oracle on native AWS instances under the 2-vCPU Authorized Cloud Environment rule with no Support Rewards. Oracle Database@AWS runs OCI Exadata inside AWS data centres, so the favourable OCI counting (2 OCPU per licence) and Support Rewards apply. Database@AWS reached general availability on 8 July 2025 and covered twelve AWS regions by April 2026.
Yes. Oracle Database@Azure, generally available across 22 Azure regions in 2026, lets customers use Bring Your Own License and accrue Oracle Support Rewards exactly as they would on OCI directly. Because the database runs on OCI infrastructure inside Azure, OCI counting and Support Rewards apply rather than the 2-vCPU rule that governs plain Azure VM BYOL.
Benchmarks labelled "Oracle Licensing Experts engagement data, 2026" are drawn from our independent, buyer-side advisory work across 600+ Oracle engagements and $1.8B in Oracle spend advised, including cloud BYOL migrations on AWS and Azure. Counting rules, Support Rewards rates, and Database@AWS / Database@Azure terms are taken from Oracle's, AWS's and Microsoft's published 2025–2026 materials and corroborated against achieved client positions. Primary sources:
No NDA-bound client figures are disclosed. Representative ranges are benchmarks, not quotes.
The Oracle Licensing Experts Advisory Team is an independent, buyer-side Oracle licensing practice staffed by former Oracle insiders. We model cloud BYOL positions, defend audits, and negotiate contracts — 100% on the buyer's side, never reselling Oracle. Learn about our team → · Not affiliated with Oracle Corporation.
Take the 2026 Oracle BYOL on AWS & Azure guide into your next cloud migration review as a PDF.
We rebuild the vCPU count instance-by-instance, check support and DR exposure, weigh Database@AWS / Database@Azure against plain BYOL, and put the three-year licence-and-support delta in front of you — so the migration is priced on evidence, not Oracle's policy spin.
Oracle pricing, audit and negotiation intelligence — monthly, independent, no Oracle spin.