Microsoft announced the general availability of two Azure Virtual Machines CPU controls on August 19, 2026: disabling simultaneous multithreading or hyper-threading, and selecting a configurable constrained vCPU count.

The first option lets a supported VM expose one thread per physical core instead of the usual two. The second lets a team activate fewer vCPUs than the VM size normally provides while retaining the size's memory, storage, and I/O capabilities.

These controls address two different pressures. Latency-sensitive and high-performance workloads may benefit from avoiding contention between sibling hardware threads. Memory-heavy databases and enterprise applications may need the RAM and bandwidth of a large VM but not all its CPU capacity, especially when software is licensed per core.

The flexibility is real, but so are the boundaries. Microsoft does not reduce the Azure infrastructure price when cores or threads are disabled. Customers are still billed for the original VM size. Any saving must come from workload performance, software licensing, consolidation, or operational simplicity.

Two Controls, Two Different Outcomes

Simultaneous multithreading allows one physical CPU core to present more than one logical processor. The threads share parts of the core, which can improve total throughput when one thread would otherwise leave execution capacity unused.

Disabling SMT changes that topology. Setting `vCPUsPerCore` to `1` gives the guest one visible thread per physical core. Microsoft positions this for workloads that benefit from more consistent latency or exclusive use of core resources.

Configurable constrained cores changes the number of vCPUs available to the guest. The team selects one of the supported lower counts for the chosen VM size through `vCPUsAvailable`.

The controls can be used separately or together:

• Disable SMT while keeping the physical-core capacity represented by the size

• Keep SMT enabled but expose fewer vCPUs

• Disable SMT and also select a lower vCPU count

Those are not interchangeable configurations. Each produces a different guest topology, scheduling behavior, and licensing footprint. Benchmark the exact combination that will run in production.

Why Configurable Cores Matter for Database Workloads

Large database servers are often selected for memory, cache capacity, storage throughput, network bandwidth, or disk limits rather than raw CPU demand.

Historically, Azure offered predefined constrained-vCPU sizes for some VM families. For example, a constrained variant could retain the memory and I/O profile of a larger E-series size while exposing one-half or one-quarter of its standard vCPU count.

The new configurable model makes the CPU choice more explicit. Microsoft says Azure guides customers through valid vCPU counts for a supported size instead of forcing every useful combination to exist as a separately named SKU.

Potential candidates include:

• SQL Server installations with high memory demand

• Oracle database workloads licensed by processor metrics

• SAP systems whose memory and I/O needs exceed CPU demand

• Analytics servers with large working sets

• In-memory applications that are not CPU-bound

Do not turn a technical CPU setting into an automatic licensing conclusion. Licensing rules differ by product, edition, agreement, mobility rights, minimum core requirements, and measurement method. Confirm the permitted count with the software publisher and your licensing team before calculating savings.

The Azure VM Charge Does Not Shrink

Microsoft is explicit: there is no Azure VM pricing change for these features.

The customer pays for the vCPU count in the original VM specification, even when the guest sees fewer active vCPUs or one thread per core. Azure is still reserving the memory, storage limits, network capacity, physical core allocation, and other capabilities of the selected size.

That means a constrained configuration can increase the infrastructure cost per active vCPU. It is justified only when another benefit outweighs that premium.

Build the business case with separate lines for:

• Azure compute cost

• Operating-system licensing

• Database or application licensing

• Required memory and I/O tier

• Expected performance

• Operational overhead

• High availability and disaster recovery copies

If the workload can simply move to a smaller standard VM without losing necessary memory or bandwidth, that may be cheaper. Configurable cores are most valuable when CPU is the one dimension that should shrink while the rest of the VM stays large.

Disabling SMT Is a Benchmarking Decision

Turning off SMT is not a universal performance optimization.

Some applications improve because sibling threads no longer compete for core resources. Others lose throughput because the second hardware thread was making productive use of otherwise idle execution capacity.

Measure both configurations with production-like data, concurrency, and NUMA behavior. Useful signals include:

• P50, P95, and P99 request latency

• Transactions or jobs completed per second

• CPU ready time and utilization

• Lock, latch, and scheduler waits

• Memory bandwidth and cache behavior

• Storage latency and queue depth

• Network throughput

• Performance per Azure dollar

• Performance per licensed core

A lower average latency can hide a lower maximum throughput. A better synthetic benchmark can hide worse behavior during backup, index maintenance, checkpoint, garbage collection, or batch windows.

Keep the test long enough to cover those phases.

Deployment Uses VM Hardware Profile Properties

For infrastructure as code, the controls live in `hardwareProfile.vmSizeProperties` on the virtual machine resource.

The two important values are:

• `vCPUsPerCore: 1` to disable SMT or hyper-threading

• `vCPUsAvailable` to set a supported lower vCPU count

Microsoft documents Azure CLI, PowerShell, and ARM template paths. The ARM resource must use API version `2021-07-01` or later for these properties.

Treat the topology as version-controlled infrastructure. Do not configure production VMs manually and hope the setting survives rebuilds.

Add policy or deployment validation that records:

• VM size and region

• Requested vCPU count

• Threads per core

• Image source

• Scale-set orchestration mode

• Licensing model

• Workload owner and approval

The operating system should report the expected processor topology after deployment. Include that check in provisioning validation.

Supported Values Depend on the Size and Region

Azure does not accept an arbitrary number of vCPUs.

Microsoft exposes valid values for a VM SKU through its capabilities. The Azure CLI `az vm list-skus` command can return the `vCPUsConstraintsAllowed` field for a size in a location.

Important rules in the current documentation include:

• vCPUs can be reduced but not increased beyond the size's default

• SMT can be disabled only when the size enables it by default

• A hyper-threaded size requires an even custom vCPU count

• The two controls can be combined

• Unsupported combinations are rejected

Query support in the target subscription and region during deployment planning. Do not assume a configuration tested in one region or VM generation will remain valid for every other environment.

Microsoft says the capabilities are available in all Azure regions, but size support and valid constrained counts still need to be checked.

Changes Require Lifecycle Planning

CPU options can be selected during VM creation or a resize operation. They are not a live guest setting that an operator can toggle without infrastructure impact.

Microsoft documents that an existing allocated VM must be deallocated for the update. Resizing causes a reboot, so the change requires a maintenance window or a rolling replacement strategy.

When resizing within a family that supports the feature, Azure carries the settings forward by default. Moving to a size that does not support them can be blocked or return an error.

For a stateful workload, plan the change as carefully as any VM resize:

• Confirm backups and recovery

• Drain or fail over application traffic

• Check cluster quorum and replica health

• Deallocate or replace one node at a time

• Validate guest topology after boot

• Run a health and performance test

• Confirm licensing inventory

• Keep a tested rollback configuration

An availability set, scale set, database cluster, or SAP landscape may need its own sequencing rules.

Image and Scale-Set Support Has Limits

Microsoft's current Learn page says VM Scale Sets with Uniform orchestration are supported at GA. It also lists first-party Azure Marketplace images such as Windows Server, Ubuntu, Red Hat, and SUSE, plus custom images.

Specialized Marketplace offers, including SQL Server on Azure Virtual Machines images, are listed as unsupported at this time.

That limitation matters because SQL Server is one of the most obvious licensing scenarios. A team may need to use a supported base image and install the workload through an approved automation path, but that can change SQL IaaS Agent extension behavior, license reporting, patching, backup, and support expectations.

Verify the exact image workflow with Microsoft before redesigning a production SQL estate around the feature.

The Learn page also contains conflicting portal guidance: it describes a Customize cores interface and later says portal support is coming. Treat the resource provider and tested command-line or template behavior as the source of truth for automation, and confirm what is visible in your tenant.

Governance Must Track the Logical Topology

Inventory systems often record only the Azure SKU. That is no longer enough.

Two VMs with the same size can expose different active vCPU counts and threads-per-core settings. Cost allocation, capacity planning, performance baselines, and licensing evidence need the effective topology as well as the nominal size.

Extend asset records and dashboards with:

• Nominal VM vCPUs

• Active guest vCPUs

• Threads per core

• Physical-core interpretation

• Software license basis

• Date and approver of the configuration

• Benchmark result and rollback threshold

Alert on drift between infrastructure code, Azure resource properties, guest discovery, and the licensing inventory.

Who Should Care?

Infrastructure teams should care because VM size is no longer the complete CPU configuration.

Database administrators should care because they can retain memory and I/O while matching CPU capacity more closely to the workload.

Performance engineers should care because disabling SMT changes throughput and tail-latency behavior.

FinOps and licensing teams should care because Azure compute charges remain fixed while third-party licensing may change.

Platform security teams should care because image and scale-set support determines which hardened deployment paths are available.

Practical Cloud Engineer Takeaway

Start with one non-production workload whose memory or I/O requirement clearly exceeds its CPU requirement.

Query the target region for supported vCPU constraints. Capture the current topology, performance, Azure price, and software license calculation.

Deploy three controlled variants where supported: the default VM, SMT disabled, and a constrained-vCPU configuration. Use the same image, disks, network, dataset, and test window.

Compare tail latency, throughput, maintenance behavior, and total cost. Confirm the guest sees the intended processor count and that the software publisher recognizes it for licensing.

Then automate the chosen properties through your normal IaC module. Add topology validation, a maintenance procedure for future resize operations, and inventory fields for the effective CPU configuration.

Do not migrate a fleet based only on a promising licensing spreadsheet. A constrained design succeeds when the application still meets its service objective under peak load and failure conditions.

Bottom Line

Azure Virtual Machines now provide generally available controls for disabling SMT and selecting supported constrained vCPU counts.

The features let performance-sensitive workloads run with one thread per physical core and let memory- or I/O-heavy software use fewer active vCPUs without giving up the rest of a larger VM's capabilities.

They do not reduce the base Azure VM bill. Their value comes from workload behavior, software licensing, or a better match between CPU and the other resources a VM provides.

Adopt them with measurements, explicit licensing validation, version-controlled hardware profile settings, support checks for the exact size and image, and planned downtime for changes.

The new control is useful because it separates CPU topology from the VM size. That same separation means architecture, cost, inventory, and operations must all record both.

Sources

Microsoft Azure Compute announcement, published August 19, 2026: https://techcommunity.microsoft.com/blog/azurecompute/announcing-general-availability-of-disable-multithreading-and-configurable-const/4547908

VM vCore Customization documentation: https://learn.microsoft.com/en-us/azure/virtual-machines/vm-customization

Constrained vCPU sizes for database workloads: https://learn.microsoft.com/en-us/azure/virtual-machines/constrained-vcpu

SQL Server on Azure VM licensing models: https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/licensing-model-azure-hybrid-benefit-ahb-change

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz