How Do You Optimize Azure Virtual Machines Across Cost, Security, Performance, and Reliability?

Azure Virtual Machines are usually the single largest line item on an Azure invoice -- and also where the most optimization opportunities hide in plain sight. A comprehensive VM optimization strategy works across five dimensions at once: eliminating compute waste through right-sizing and deallocation, aligning disk tiers with actual I/O demand, hardening security by removing public exposure and closing patch gaps, protecting business continuity with zone-redundant deployments and validated backups, and retiring legacy agents and end-of-life operating systems before they become liabilities.

Spotto's continuous analysis across all five Well-Architected Framework pillars surfaces these opportunities automatically -- flagging stopped-but-allocated VMs still burning compute budget, Premium SSDs running at 5% of provisioned IOPS, machines with 95%+ CPU saturation headed for an outage, and publicly exposed endpoints that have no business being on the internet. The result is a fleet that costs less, performs better, and passes audits without scrambling.

What Problem This Solves

Most Azure VM fleets accumulate inefficiency gradually. A VM gets provisioned for a migration, sized generously "just in case," and never revisited. A Premium SSD gets attached because someone copied a template. A public IP gets assigned for a quick test and stays forever. Multiply that across hundreds or thousands of VMs managed by an MSP, and the waste compounds:

For Managed Service Providers managing multiple tenants via Azure Lighthouse, these issues multiply across every customer environment. Without continuous, automated detection, optimization becomes a quarterly fire drill rather than a standing practice.

30 Recommendations Across 5 Well-Architected Framework Pillars
──────────────────────────────────────────────────────────────────────
  COST (10)             PERFORMANCE (6)       SECURITY (5)
  ├─ Stopped VMs        ├─ CPU critical        ├─ Public IP exposure
  ├─ CPU oversized      ├─ CPU high            ├─ Public access risk
  ├─ Memory oversized   ├─ CPU low/oversized   ├─ Network anomalies
  ├─ Intel → AMD        ├─ Memory high         ├─ Guest non-compliant
  ├─ Spot instances     ├─ Memory low          └─ OS patching gaps
  ├─ Disk downgrades(4) └─ Size optimization
  ├─ Disk upgrades (2)    RELIABILITY (4)      OPS EXCELLENCE (5)
  └─ MMA → AMA            ├─ No backup          ├─ Large OS disk
                           ├─ Stale backup       ├─ OS end-of-life
                           ├─ No Avail. Zones    ├─ SQL end-of-life
                           └─ No Site Recovery    ├─ SQL disk layout
                                                  └─ SQL disk caching

Azure VM SLA Quick Reference

Before diving into optimization actions, here is the SLA baseline that drives many of these decisions:

How It Works

Right-Sizing and Compute Cost Optimization: Matching Capacity to Demand

Are your VMs sized for what they actually do, or for what someone imagined they might do two years ago? Azure VM right-sizing is the highest-impact, lowest-risk cloud cost optimization for most VM fleets. It addresses six distinct patterns of compute waste.

Deallocate Stopped VMs

A VM in the "Stopped (allocated)" state continues to reserve host capacity and incur full compute charges -- identical to a running VM. It is essentially paying rent on an apartment nobody lives in. This is the easiest cost recovery in Azure:

# Find all stopped-but-allocated VMs across subscriptions
Search-AzGraph -Query @"
resources
| where type == 'microsoft.compute/virtualmachines'
| where properties.extended.instanceView.powerState.code == 'PowerState/stopped'
| project name, resourceGroup, subscriptionId, location
"@

As of June 2025, Azure enforces a minimum 5-minute billing duration per VM start. Starting and immediately stopping a VM incurs 5 minutes of compute charges.

Downsize Oversized VMs (Low CPU and Memory)

VMs with sustained CPU utilization below 20% or available memory above 70% for 95% of the past 30 days are likely oversized:

Switch from Intel to AMD

AMD EPYC-based VMs (Dasv5 series) offer approximately 10% lower on-demand pricing than Intel equivalents (Dsv5 series) at comparable performance:

On Spot pricing, the AMD advantage widens to ~24%. Blockers to check: AVX-512 dependency, Intel SGX requirements, per-socket licensing tied to specific processor vendors, and region availability for AMD SKUs.

Adopt Spot Instances for Interruptible Workloads

Azure Spot VMs offer 60-90% discounts over on-demand pricing for workloads that can tolerate interruption:

Disk Performance and Storage Cost: Matching Tier to I/O Reality

Are you paying Premium prices for Standard workloads, or throttling Standard disks on Premium workloads? Azure disk cost optimization has two directions: downgrade over-provisioned disks to save money, or upgrade throttled disks to fix performance.

Downgrade Under-Utilized Premium and SSD Disks

Premium SSD disks running at a small fraction of provisioned IOPS represent pure waste. Data disks and OS disks with consistently low IOPS utilization (below 20% of provisioned capacity) can be downgraded to smaller Premium SKUs or Standard SSD for 30-60% savings.

Upgrade Throttled Disks

Disks consistently hitting IOPS or throughput limits cause storage throttling that cascades into application latency. Upgrade options include increasing Premium SSD size (P30 to P40 doubles IOPS from 5,000 to 7,500), Premium SSD v2 for variable demand, or Ultra Disk for extreme I/O (up to 160,000 IOPS, sub-millisecond latency).

Performance Under Pressure: Detecting Saturation Before It Becomes an Outage

CPU Saturation (Critical and High)

Before scaling up, rule out runaway processes or memory leaks consuming CPU, misconfigured thread pools or connection limits, and cron jobs or scheduled tasks that overlap with peak hours.

Memory Pressure

Low available memory manifests as kernel paging, garbage collection thrashing, and out-of-memory kills. Before scaling, confirm whether high utilization is intentional (database buffer pools, in-memory caches are supposed to use most of available RAM) and investigate for memory leaks before throwing hardware at the problem. If scaling is needed, memory-optimized SKUs (Esv5 series) provide more RAM per vCPU. Target 20-30% free memory at the 95th percentile as operating headroom.

Security and Attack Surface: Reducing Exposure Before Attackers Find It

How many of your VMs are directly reachable from the internet right now -- and how many of those should be? If you manage Azure infrastructure for multiple customers, the honest answer is probably "more than you think."

Remove Unnecessary Public Exposure

Remediation path:

Close Patch and Compliance Gaps

Both issues breach PCI DSS, SOC 2, ISO 27001, and CIS benchmark requirements. Auditors flag these as high-severity findings.

Reliability and Business Continuity

When was the last time you tested a restore from backup? If the answer takes more than two seconds, that is the problem.

Enable Azure Backup

Deploy to Availability Zones

Enable Azure Site Recovery

VMs without cross-region disaster recovery depend on manual rebuilds from backup after a regional outage. ASR provides automated failover in minutes with RPO measured in configured replication intervals, at ~$25/month per protected instance (first 31 days free).

Lifecycle and Monitoring: Retiring Technical Debt

Migrate from MMA to Azure Monitor Agent (AMA)

The Microsoft Monitoring Agent (MMA/OMS) was officially retired on August 31, 2024. VMs still running MMA face higher ingestion costs, feature gaps, and increasing stability risk.

Address End-of-Life Operating Systems and SQL Server

VMs running OS versions past mainstream support no longer receive security patches. The same risk applies to SQL Server versions past mainstream support. Validate application compatibility in a non-production environment before upgrading, and check whether Extended Security Updates are available as a temporary measure.

SQL Server on VMs: Storage Architecture and Caching

SQL Server disk misconfiguration is one of the most common -- and most fixable -- performance problems in Azure VM environments.

Cost Impact Summary

Use-Case and Scenario Coverage

Recommended Rollout Sequence

Automation: Weekly VM Fleet Health Check

# Weekly Azure VM fleet health check
# Run as an Azure Automation runbook on a weekly schedule
# Requires: Az.ResourceGraph, Az.Compute, Az.Monitor modules

Connect-AzAccount -Identity

# 1. Find stopped-but-allocated VMs
$stoppedAllocated = Search-AzGraph -Query @"
resources
| where type == 'microsoft.compute/virtualmachines'
| where properties.extended.instanceView.powerState.code == 'PowerState/stopped'
| project name, resourceGroup, subscriptionId, location,
          vmSize = tostring(properties.hardwareProfile.vmSize)
"@

# 2. Find VMs with public IPs
$publicIpVms = Search-AzGraph -Query @"
resources
| where type == 'microsoft.network/publicipaddresses'
| where isnotempty(properties.ipConfiguration.id)
| extend nicId = tostring(split(properties.ipConfiguration.id, '/ipConfigurations/')[0])
| join kind=inner (
    resources
    | where type == 'microsoft.compute/virtualmachines'
    | mv-expand nic = properties.networkProfile.networkInterfaces
    | extend nicId = tostring(nic.id)
) on nicId
| project vmName=name1, publicIp=properties.ipAddress
"@

# 3. Find VMs without backup
$noBackup = Search-AzGraph -Query @"
resources
| where type == 'microsoft.compute/virtualmachines'
| join kind=leftanti (
    recoveryservicesresources
    | where type =~ 'microsoft.recoveryservices/vaults/backupfabrics/protectioncontainers/protecteditems'
    | where properties.backupManagementType == 'AzureIaasVM'
    | extend vmId = tolower(tostring(properties.sourceResourceId))
) on \$left.id == \$right.vmId
| project name, resourceGroup, subscriptionId, location
"@

Write-Output "=== VM Fleet Health Check ==="
Write-Output "Stopped (allocated): $($stoppedAllocated.Count) VMs"
Write-Output "Public IP attached:  $($publicIpVms.Count) VMs"
Write-Output "No backup:           $($noBackup.Count) VMs"

Common Questions About Azure Virtual Machine Optimization

How do I find stopped-but-allocated VMs across all subscriptions?

Use Azure Resource Graph with properties.extended.instanceView.powerState.code == 'PowerState/stopped'. This query works across all subscriptions accessible to the caller, including Lighthouse-delegated tenants. Deallocated VMs show PowerState/deallocated and do not incur compute charges.

How much can I save by right-sizing VMs?

Typical range: 30-50% per VM when dropping one or two size tiers. Example: D8s_v5 (8 vCPU / 32 GiB) at ~$280/month to D4s_v5 (4 vCPU / 16 GiB) at ~$140/month. Across 200 oversized VMs at 40% average savings: ~$22,400/month. Always validate against 4-6 weeks of telemetry including peak periods, batch runs, and month-end processing.

Is it safe to downgrade Premium SSD to Standard SSD?

For workloads with low I/O demand (less than 20% of provisioned IOPS), generally yes. Key considerations: single-instance SLA drops from 99.9% to 99.5%, boot time may increase slightly, and backup/ASR replication windows may extend. Always snapshot the disk before migrating and test in non-production first.

What about Reserved Instances and Savings Plans?

Right-size first, then commit. Reserving an oversized VM locks in waste for 1-3 years. After right-sizing, evaluate Reserved Instances for stable workloads (up to 72% savings) or Savings Plans for dynamic environments (up to 65% savings).

How do I prioritize which VMs to optimize first?

Start with the highest-cost, lowest-risk wins: (1) Deallocate stopped VMs, (2) Downgrade under-utilized Premium disks, (3) Right-size oversized VMs with consistent low utilization, (4) Migrate MMA to AMA, (5) Address security gaps.

Should I move all VMs to Availability Zones?

Not all VMs warrant zone-redundant deployment. Production workloads with SLA requirements: yes, target 99.99%. Dev/test environments: probably not worth the added cost and complexity. Stateful single-instance workloads: evaluate ASR as an alternative to multi-zone deployment.

What to Do Next

Summary