Azure VM pricing: calculate the full monthly cost

Azure VM pricing starts with an hourly compute rate, but the monthly bill can also include disks, networking, software, backups, and monitoring. To estimate a deployment, specify the VM size, region, operating system, pricing model, and billable hours, then add the services that support it.

This guide shows how to build that estimate and check it against actual spending. The worked example uses Microsoft public retail prices checked on October 29, 2026, in US dollars. It is an illustration, not an account-specific quote or a promise that a particular VM is available.

What determines Azure virtual machine pricing?

A VM size defines a combination of resources and limits. Compare CPU architecture, virtual CPUs, memory, disk throughput, and network requirements before comparing prices. A cheaper instance that cannot finish the job within its deadline may cost more per completed task.

Record these inputs for each estimate:

• Exact VM size: keep the full identifier, such as Standard_D2s_v5, rather than a broad label such as “two-core VM.”
• Azure region: use the region where the workload will run, and check availability and quota separately.
• Operating system and image: distinguish the base compute rate from Windows, paid Linux distributions, and Marketplace software charges.
• Quantity and billable hours: include every instance and the periods when compute remains allocated.
• Purchase model: separate pay-as-you-go, reservations, savings plans, and Spot assumptions.
• Currency and agreement: public retail pricing may differ from negotiated rates and the amount billed in your currency.

Keep a normal month and a busy month in the estimate. For a batch workload, describe jobs per month and measured time per job. For an application, include the instances needed to handle peak traffic and the availability design. Treat an untested utilization assumption as something to validate.

Build the full monthly cost estimate

For a pay-as-you-go deployment, start with VM count × hourly rate × billable hours. Then add each supporting service. A lower compute rate changes only one part of the calculation.

Persistent disks and stored copies

List the operating-system disk and every data disk, including their tier, provisioned capacity, and redundancy. Add snapshots and backup storage where used. Consult the managed disk pricing page for the selected disk model; capacity, performance, and transaction charges vary by type.

A VM's temporary storage and a persistent managed disk have different purposes. Do not count temporary storage as the only place for data you must retain. Our Azure Storage guide explains the broader storage choices without mixing their prices into a single VM rate.

Network access and data movement

Record outbound data, traffic between regions, and any charged network resources in the design. Public IP addresses, NAT Gateway, load balancers, VPN Gateway, and Azure Bastion need their own checks when used. Do not assume that a VM's advertised network throughput includes every network service or transfer charge.

Use the Azure Pricing Calculator to add the relevant products and quantities. Price a realistic traffic pattern: where the data starts, where it goes, and how much moves each month. A monthly export can change the result even when VM hours stay constant.

Software, operations, and recovery

Check paid images and application licenses separately. Include backup protection, retained recovery points, log ingestion and retention, security services, and any support plan in scope. These charges depend on the features you enable and the data they process. Include applicable taxes when preparing the amount your organization expects to pay.

Give every estimate line an owner and an assumption. “Logs: to be measured” is more useful than silently assigning zero. For a Windows workstation, account for the access method as well as the VM. Our Remote Desktop on Azure guide explains the connection options and setup.

A dated Azure VM cost example

Consider one Linux Standard_D2s_v5 VM in East US, using pay-as-you-go public retail rates in USD, with no paid image premium. Microsoft lists this Dsv5 size with 2 vCPUs, 8 GiB of memory, and no local temporary storage. Assume one P10 LRS Premium SSD managed OS disk, with 128 GiB of provisioned capacity, retained for the whole month.

On October 29, 2026, the Azure Retail Prices API returned $0.096 per hour for the base D2s v5 compute meter in East US and $19.71 per month for the P10 LRS Premium SSD Managed Disks meter. The calculation excludes Windows, Spot, and Low Priority meters.

• Compute for 730 billable hours: 730 × $0.096 = $70.08.
• One P10 managed disk for the month: $19.71.
• VM-and-disk subtotal: $89.79.

This is a subtotal, not the complete invoice. Add the network, software, backup, monitoring, support, and tax amounts that apply to the deployment. No Azure workload was deployed to produce this illustration.

The 730-hour month is a planning convention. A 31-day calendar month has 744 hours, so use the hours in your actual billing period when precision matters. Likewise, an estimate based on one disk does not include a second data disk or a backup copy.

What changes with a working-hours schedule?

Suppose the same pay-as-you-go VM has exactly 176 billable hours, equivalent to 22 eight-hour workdays, and is deallocated for the remaining time. Compute becomes $16.90 after rounding; keeping the same disk brings the subtotal to $36.61. The disk remains in the estimate even while the VM is deallocated.

This scenario assumes no reservation or savings-plan commitment. It also assumes the 176 hours include all billed states, not just productive application time. Verify the actual schedule, startup periods, and retained resources before using the number as a budget.

Stopped versus deallocated: check the billing state

Under Microsoft's VM state billing rules, starting, running, stopping, and stopped (allocated) states incur compute charges. Shutting down inside the guest operating system can leave the VM allocated.

Deallocation releases the compute allocation and stops that VM usage charge. It does not remove retained disks or every associated network resource. Check the resulting state and the remaining resources after a scheduled shutdown. Existing commercial commitments still need their own cost assessment.

Choose a pricing model that fits the workload

Pay-as-you-go for uncertain or short-lived use

Pay-as-you-go is a useful starting point when you do not yet know the required size or schedule. Measure a representative workload before committing to a longer term. Compare total cost per useful result, including idle allocation, rather than optimizing the hourly rate alone.

Reserved instances for a stable baseline

Azure VM reservations apply discounted compute pricing to eligible usage under a one- or three-year commitment. Matching rules, scope, region, and instance-size flexibility matter. VM reservations do not cover every software, storage, or network charge.

Base the purchase on usage that is likely to remain throughout the term. Compare the commitment cost with an honest pay-as-you-go schedule, especially for development environments that run only part of the week.

Savings plans for eligible hourly compute spending

An Azure savings plan for compute exchanges a fixed hourly spending commitment over one or three years for discounted eligible usage. Unused hourly commitment expires; it does not roll into the next hour. Usage beyond the commitment is charged at the applicable on-demand rate.

The compute plan excludes software, networking, and storage charges. Check the expected hourly baseline across eligible resources before buying. Deallocating a VM does not erase the commitment.

Spot VMs for work that can tolerate interruption

Azure Spot VMs use spare capacity with variable pricing and can be evicted. They have no availability SLA. Evaluate them for jobs that can checkpoint, retry, or wait for capacity, and include recovery work in the cost estimate.

A low Spot rate is not a dependable price for an uninterrupted service. If eviction deallocates the VM, retained disks can continue generating charges. Check the eviction policy and recovery process before treating Spot as the default.

Azure Hybrid Benefit when licenses qualify

Azure Hybrid Benefit for Windows Server requires eligible licenses with active Software Assurance or qualifying subscriptions. Check the license count, coverage period, and applicable terms before enabling it. An existing Windows license does not automatically qualify.

Check the estimate after deployment

1. Save the estimate with its date, region, currency, VM size, image, schedule, and purchase model.
2. Run a representative workload and record useful output, elapsed time, memory use, and required disk and network performance.
3. Compare actual resource charges with the estimate, including associated services outside the VM line.
4. Investigate missing services, idle allocation, traffic growth, and unused commitments before changing the architecture.
5. Assign a person to review changes and refresh the estimate when the workload changes.

Configure Azure Cost Management budgets and alerts, but do not treat a budget notification as a spending cap. A budget by itself does not stop resources, and cost reporting is delayed. Any automated response needs its own configuration and operational review.

Questions to settle before approving the cost

Does the hourly VM price include its OS disk?

Do not assume so. In the worked example, the managed OS disk is a separate monthly line. Check what the selected VM and image include, then add persistent disks and other required services explicitly.

Is a reserved VM always cheaper?

A discounted rate can still produce a higher total if you commit to capacity you rarely use. Compare the full commitment with the workload's expected pay-as-you-go hours, then check eligibility and benefit utilization.

How do I compare Azure with another provider?

Use the same workload, location requirements, operating hours, storage, data transfers, and recovery expectations. Measure completion time or service performance where possible. Record differences in included services before comparing totals; matching CPU counts alone does not establish equivalent performance.