Azure Pricing Models Explained: Pay-As-You-Go vs Reserved vs Savings Plans vs Spot

Azure pricing isn't complicated once you understand the four models. But most beginners pick the wrong one, either overpaying with pay-as-you-go when a reservation would save 40%, or locking into a reservation for a workload that turns out to be temporary.

This guide explains each pricing model with real numbers, real scenarios, and a decision framework you can actually use.

The Four Pricing Models

Pay-As-You-Go: The Starting Point

PAYG is the default. You use a VM for 3 hours, you pay for 3 hours. No commitment, no discount, no risk.

Real pricing example (Canada Central):

• Standard_B2s VM: ~$0.054/hour, which is ~$39/month if running 24/7
• Standard_D4s_v5 VM: ~$0.192/hour, which is ~$140/month if running 24/7

PAYG makes sense when:

• You're learning or experimenting: spin up, test, delete, with no waste
• Workloads are unpredictable: you don't know if you'll need the resource next month
• Short-term projects: 1 to 3 months of compute isn't worth a reservation

PAYG does NOT make sense when:

• You're running production 24/7: you're leaving 30-72% savings on the table
• Your workload is predictable: if you've run the same VMs for 6+ months, you know the pattern

Reserved Instances: The Biggest Savings

Reservations lock in a specific VM size in a specific region for 1 or 3 years. In exchange, you get significant discounts.

Real pricing example (Standard_D4s_v5, Canada Central):

That's $612/year saved on a single VM with a 1-year reservation. Across 10 production VMs, that's $6,120/year, which is real money.

When reservations make sense:

• Steady-state production workloads: the VM runs 24/7, same size, same region
• Database servers: SQL, MySQL, or PostgreSQL managed instances with predictable capacity
• You can commit for 1+ years: if the project might be cancelled in 6 months, don't reserve

When reservations are risky:

• You might resize: reservations are tied to a VM family but can be exchanged
• You might move regions: reservations are region-specific
• Your workload is shrinking: you'll pay for capacity you don't use

Savings Plans: Flexibility with Commitment

Savings Plans are newer than reservations and more flexible. Instead of committing to a specific VM, you commit to a dollars-per-hour spend level. Azure applies the discount to whatever compute you're running.

Real pricing example:

• Commit to $0.10/hour across all compute
• Applies to VMs, App Service, Container Apps, and Functions Premium
• If you exceed $0.10/hr, the excess is billed at PAYG rates

When savings plans beat reservations:

• You use multiple compute services: Functions, App Service, and VMs all covered by one plan
• You resize VMs frequently: the discount follows your spend, not a specific VM size
• You deploy across regions: savings plans can be scoped to a subscription, not region-locked like some reservations

When reservations beat savings plans:

• Maximum discount: reservations for specific VMs can save more (up to 72% vs 65%)
• Predictable, single-service workload: one big database server that won't change

Spot VMs: Extreme Savings, Extreme Risk

Spot VMs use Azure's unused capacity at up to 90% discount. The catch: Azure can reclaim your VM with 30 seconds notice when it needs the capacity back.

Real pricing example:

• Standard_D4s_v5 PAYG: ~$0.192/hour
• Spot price: ~$0.019/hour (90% cheaper)

Spot VMs work for:

• Batch processing: render jobs, data pipelines, or ML training that can checkpoint and resume
• CI/CD build agents: if a build gets evicted, just restart it
• Scale-out workloads: VMSS with a mix of PAYG for baseline and Spot for burst capacity

Spot VMs do NOT work for:

• Production web servers: users see downtime when Azure evicts your VM
• Databases: data corruption risk on unexpected termination
• Anything that can't handle a sudden shutdown

The Decision Framework

Is the workload running 24/7 and staying for 1+ year?
├── Yes: Reserved Instance (single service) or Savings Plan (multi-service)
└── No
    ├── Is it fault-tolerant and can handle eviction?
    │   ├── Yes: Spot VM
    │   └── No: Pay-As-You-Go
    └── Will it run for 1 to 6 months?
        └── Pay-As-You-Go (evaluate for reservation after 3 months)

Five Mistakes That Cost Real Money

Leaving dev/test VMs running overnight. A D4s_v5 running 24/7 costs $140/month. If your team only uses it 8 hours on weekdays, auto-shutdown saves 76%, about $106/month per VM.

Reserving before understanding usage. Don't buy reservations in month one. Run PAYG for 60 to 90 days, then use Cost Management and Advisor reservation recommendations. Azure will tell you exactly which VMs would benefit.

Ignoring orphaned resources. Unattached managed disks, unused public IPs, empty App Service Plans, and stopped-but-not-deallocated VMs all incur charges. Run a monthly cleanup.

Picking the wrong VM family. B-series VMs (burstable) are 60% cheaper than D-series for workloads that don't need sustained CPU. If your app idles most of the time with occasional spikes, B-series is the right choice.

Not tagging resources for cost allocation. Without tags, you can't answer "which team costs how much." Start with environment, team, and cost-center tags enforced by Azure Policy.

Practice Cost-Aware Deployments

The best way to understand Azure pricing is to deploy resources and watch the cost accumulate in real time. These labs give you sandbox environments where you can experiment without worrying about your personal Azure bill:

Certification Connection

Azure pricing models are tested in both AZ-900 (Fundamentals) and AZ-104 (Administrator). AZ-900 tests conceptual understanding. AZ-104 tests practical application, asking which pricing model you would recommend for a given scenario.

For a full study plan, read How to Use Practice Exams to Pass AZ-104.