Short answer: An Azure constrained vCPU VM caps the active, licensable vCPUs to a fraction of the physical cores while keeping the full memory and I/O of the larger size. Because Oracle counts only active vCPUs at 2 per Processor license, constraining a 64-vCPU VM down to 16 active vCPUs cuts the Oracle license requirement from 32 to 8 Processor licenses — up to a 75% reduction for memory-bound databases.
Key Takeaways
- Azure constrained vCPU VMs (sizes like E64-16s_v5) expose a reduced active vCPU count while retaining the full RAM, storage throughput, and network bandwidth of the parent size.
- Oracle counts only the active vCPUs under its Authorized Cloud Environment rule of 2 vCPUs per Processor license — the constrained count, not the physical cores.
- Constraining a 64-vCPU VM to 16 active vCPUs drops the Oracle requirement from 32 to 8 Processor licenses — a 75% cut — while the database keeps all 512 GB of RAM.
- The saving applies to option licenses too: Partitioning, Advanced Security, and the management packs are all counted on the same reduced Processor base.
- Across 600+ engagements, memory-bound Oracle databases moved to Azure without constrained sizing over-license CPU by 2–4x on average (Oracle Licensing Experts benchmark, 2026).
What Is an Azure Constrained vCPU VM?
An Azure constrained vCPU VM is a standard Azure virtual machine size in which Microsoft caps the number of active (and therefore licensable) vCPUs to a fraction of the parent size's physical cores, while keeping that parent's full memory, storage throughput, and network bandwidth. Microsoft created these sizes specifically for high-per-core licensed software such as Oracle Database and SQL Server. The naming convention encodes the split: an E64-16s_v5 is built on the 64-vCPU E-series chassis but exposes only 16 active vCPUs, while retaining the 512 GB of RAM that the full E64s_v5 carries.
The point is to break the false coupling between memory and CPU that standard VM sizing forces on you. A standard VM ties RAM to core count — to get 512 GB you must rent 64 cores. For a database that needs the memory but uses a fraction of the CPU, that means paying Oracle for dozens of idle cores. Constrained sizing lets you buy the memory and storage profile your workload actually needs and license only the cores it actually runs.
Oracle's field teams will not volunteer this. When Oracle sizes your Azure migration, the default is a standard VM with cores tied to memory — the configuration that maximizes your Processor count and Oracle's revenue. Constrained vCPU sizing is a documented Microsoft feature, not a loophole, but it only helps if you specify it before deployment. Right-sizing is buyer-side work; Oracle's playbook is to let you over-provision and then count what you provisioned.
How Does Oracle Count Licenses on Azure?
Microsoft Azure is an Authorized Cloud Environment under Oracle's Licensing Oracle Software in the Cloud Computing Environment policy — the same policy that governs AWS. On Azure, Oracle ignores the on-premise Core Factor Table and counts vCPUs directly: with hyperthreading on, 2 vCPUs equal one Oracle Processor license; with hyperthreading off, 1 vCPU equals one license. Azure's compute is hyperthreaded, so the working ratio is 2 vCPUs per license. The critical detail for constrained sizing is that Oracle counts the active vCPUs the VM exposes — not the physical cores of the underlying chassis. That is exactly what a constrained VM reduces.
So the chain is simple and unhedged: choose a constrained VM, the active vCPU count falls, the Oracle Processor count falls in direct proportion, and the memory and storage stay intact. The same reduced Processor base then flows through to every Oracle option you license per Processor — Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, In-Memory and the rest — multiplying the saving across your whole option stack.
Constrained vs Standard vCPU: The License Math
The table below shows the same memory and storage profile delivered two ways — a standard VM versus its constrained equivalent — and what each costs in Oracle Processor licenses. The workload is identical; only the active vCPU count, and therefore the license bill, changes.
| Azure VM size | Active vCPUs | RAM | Oracle Processor licenses (2:1) | License reduction |
|---|---|---|---|---|
| E64s_v5 (standard) | 64 | 512 GB | 32 | — |
| E64-32s_v5 (constrained) | 32 | 512 GB | 16 | 50% |
| E64-16s_v5 (constrained) | 16 | 512 GB | 8 | 75% |
| E32s_v5 (standard) | 32 | 256 GB | 16 | — |
| E32-8s_v5 (constrained) | 8 | 256 GB | 4 | 75% |
Read the E64-16s_v5 row carefully. It carries the same 512 GB of RAM as the full E64s_v5 but needs only 8 Processor licenses instead of 32. At Oracle Database EE list pricing plus 22% annual support, eliminating 24 Processor licenses is a seven-figure saving over a typical contract term — before counting the option licenses that ride on the same Processor base.
Sizing an Oracle migration to Azure?
Our Oracle license optimization service profiles your databases, matches each to the right constrained VM size, and models the Processor count Oracle will apply — before you commit to a shape that over-licenses idle cores.
Which Oracle Workloads Benefit Most from Constrained vCPUs?
Constrained sizing pays off whenever a workload is memory-bound or I/O-bound rather than CPU-bound — which describes the majority of enterprise Oracle databases. Large OLTP systems with big buffer caches, data warehouses that need throughput more than raw cores, and consolidation targets that demand RAM headroom all fit the profile. The test is straightforward: if your on-premise Oracle server runs at low average CPU utilization but uses most of its memory, constrained sizing will cut your Azure license bill with no performance loss.
The workloads that do not benefit are genuinely CPU-bound: heavy analytical processing, batch engines, or systems already running hot on cores. For those, constraining vCPUs would starve the workload. The discipline is to measure real utilization first — a forensic, evidence-based exercise — and size to demand. Guessing from the old server spec is how enterprises end up paying Oracle for cores no query ever touches.
Will Oracle Accept Constrained vCPU Counts in an Audit?
Yes — provided you keep the evidence. Oracle's cloud policy counts active vCPUs, and Microsoft publishes the constrained vCPU count for every such VM size as official product documentation. That documentation is your audit defense: it proves the VM exposes only the active vCPUs you licensed, regardless of the larger chassis underneath. To defend the position, retain three things: the Azure VM size specification showing the constrained active vCPU count, your configuration records over time, and the version of Oracle's cloud policy in force at deployment.
This is where buyers get caught. Oracle's LMS scripts measure what is deployed at the moment they run; if a constrained VM was ever temporarily resized to a standard size — for a migration burst or a misconfigured change — the higher count becomes audit exposure for that period. Lock the VM size, log every change, and treat constrained sizing as a controlled configuration, not a set-and-forget setting. Our Oracle audit defense team builds exactly this evidence file as standard.
A manufacturer migrating a 40-core on-premise Oracle estate to Azure was quoted a standard E64s_v5 design requiring 32 Processor licenses. Their databases averaged under 20% CPU but needed the full memory. We re-specified the migration on E64-16s_v5 constrained VMs, cut the requirement to 8 Processor licenses, and documented the position for audit defense. See our client case studies for comparable Azure outcomes.
How to Deploy Oracle on Azure Constrained vCPUs Correctly
Treat this as a controlled, evidence-based process — the same discipline we apply on every Azure engagement:
- Measure real CPU utilization over a representative period for each database. Size to the 95th-percentile demand, not the legacy server.
- Map each workload to the constrained VM size that delivers the required memory and I/O at the lowest active vCPU count.
- Calculate the Processor count at the 2-vCPU ratio and reconcile it against the licenses you own on active support.
- Confirm hyperthreading status on the chosen size — almost all Azure sizes are hyperthreaded, giving the favorable 2:1 ratio.
- Lock the VM size and log changes so a temporary resize never silently inflates your audit exposure.
- Document the policy version and the Microsoft constrained-vCPU specification as your defense file.
For the full cloud framework, see our Oracle Cloud Licensing Guide, the companion vCPU counting guide, and the AWS EC2 vs RDS counting comparison. Our Oracle compliance review closes any gap before Oracle's audit team finds it.
Frequently Asked Questions
What is an Azure constrained vCPU VM?
It is a standard Azure VM size where Microsoft caps the active, licensable vCPUs to a fraction of the physical cores while keeping the full memory, storage, and bandwidth of the larger size. For example, an E64-16s_v5 exposes 16 active vCPUs but retains the 512 GB RAM of the 64-vCPU parent. Microsoft built these sizes for per-core licensed software like Oracle.
Do Azure constrained vCPUs reduce Oracle license counts?
Yes. Oracle counts only the active vCPUs, not the underlying cores. Under the Authorized Cloud Environment rule of 2 vCPUs per Processor license, a VM constrained to 16 active vCPUs needs 8 licenses instead of the 32 a full 64-vCPU VM requires — up to a 75% reduction for memory-bound databases.
Is Oracle's Core Factor Table used on Azure?
No. On Azure, an Authorized Cloud Environment, Oracle ignores the Core Factor Table and counts vCPUs: 2 vCPUs per Processor license with hyperthreading on, or 1 vCPU per license without. Constrained sizing lowers the active vCPU count that feeds this calculation.
Will Oracle accept constrained vCPU counts in an audit?
Yes, with evidence. Oracle's policy counts active vCPUs, and Microsoft documents the constrained count for each size — that documentation supports the lower requirement. Keep the VM size specification, configuration logs, and the policy version in force at deployment. Constrained sizing is a documented Microsoft feature, not a workaround.
Which Oracle workloads benefit most from constrained vCPUs?
Memory-bound and I/O-bound databases benefit most. Many enterprise Oracle systems need large RAM and fast storage but modest CPU. Constrained VMs deliver the memory and I/O of a large VM while licensing only the cores the workload uses, eliminating licenses paid for idle CPU. Genuinely CPU-bound workloads do not benefit.
Does the saving apply to Oracle options too?
Yes. Options licensed per Processor — Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, In-Memory — are counted on the same reduced Processor base. Cutting the active vCPU count cuts the Processor requirement for the database and for every per-Processor option, multiplying the saving across the stack.