Cost Optimisation Strategies in Azure

Getting visibility first

You cannot optimise what you cannot see. Before attempting any cost reduction, invest two to four weeks in establishing cost visibility across your Azure environment.

Azure Cost Management + Billing provides cost analysis, budget alerts, and an advisor with specific recommendations. Navigate to the Cost Management blade in the Azure portal and enable the Cost Analysis view. Filter by subscription, resource group, service, and tag to understand where money is being spent.

Tagging is the foundation of cost attribution. Every resource should have at minimum a cost-centre, environment, and team tag. Enforce tags with Azure Policy so that resources cannot be created without them. Once tags are present, Cost Management can split costs by cost centre or team in a single view.

# Apply a cost-centre tag to all resources in a resource group
az tag update \
  --resource-id /subscriptions/SUB_ID/resourceGroups/myRG \
  --operation merge \
  --tags cost-centre=engineering environment=production team=platform

# Create an Azure Policy to enforce required tags
az policy definition create \
  --name require-cost-tags \
  --display-name "Require cost-centre, environment, and team tags" \
  --rules '{
    "if": {
      "anyOf": [
        {"field": "tags[cost-centre]", "exists": false},
        {"field": "tags[environment]", "exists": false},
        {"field": "tags[team]", "exists": false}
      ]
    },
    "then": {"effect": "deny"}
  }' \
  --mode Indexed

Right-sizing compute

The single largest source of waste in most Azure subscriptions is over-provisioned VMs. It is common to see production workloads running on Standard_D8s_v3 (8 vCPUs, 32 GB RAM) where the workload rarely exceeds 15% CPU and 8 GB RAM. Downsizing to Standard_D2s_v3 (2 vCPUs, 8 GB RAM) would reduce the cost by 75%.

Azure Advisor’s “Cost” recommendations tab surfaces VMs whose 7-day average CPU utilisation is below a configurable threshold (default 5%). Review these recommendations and right-size or shut down underutilised VMs. For managed services (App Service plans, Azure Kubernetes Service node pools), check the plan utilisation metrics and downgrade the SKU if headroom is consistently large.

# Get Advisor cost recommendations for a subscription
az advisor recommendation list \
  --category Cost \
  --query "[?impactedField=='Microsoft.Compute/virtualMachines'].{Resource:impactedValue, Impact:impact, Savings:extendedProperties.annualSavingsAmount}" \
  --output table

# Resize a VM to a smaller SKU (requires stopping the VM first)
az vm deallocate --resource-group myRG --name my-vm
az vm resize --resource-group myRG --name my-vm --size Standard_D2s_v3
az vm start --resource-group myRG --name my-vm

Reserved Instances and Savings Plans

Reserved Instances (RIs) are a billing commitment: you agree to use a specific VM family in a specific region for 1 or 3 years, and Azure charges you a significantly lower hourly rate. You are not locking yourself into a single VM — you can exchange reservations and they apply automatically to any running VM that matches the scope. Reservations are appropriate for any workload that runs continuously: production databases, web servers, application servers.

Azure Savings Plans are more flexible — they commit to a spending level per hour across compute services (VMs, Container Instances, Azure Functions Premium plan) regardless of family or region. Savings Plans offer lower discounts than RIs (around 15–35%) but are appropriate when your workload mix varies significantly over time.

Purchase reservations based on your lowest baseline usage, not your peak. If your environment runs 8 VMs at minimum and scales up to 20, buy 8 RIs. The remaining 12 instances pay on-demand rates, which is correct — you want the on-demand flexibility for variable capacity.

Autoscaling to eliminate idle capacity

Many workloads have pronounced traffic patterns: heavy during business hours, light overnight and on weekends. Running at full peak capacity 24/7 wastes 60–70% of compute spend on capacity that is idle most of the time. Autoscaling dynamically adjusts the number of instances to match actual demand.

Configure autoscale with a schedule-based rule for predictable patterns and a metric-based rule to handle unexpected spikes. The schedule rule scales out before anticipated peak load (avoiding the 5-minute autoscale lag) and scales in after it subsides. The metric rule catches unscheduled traffic spikes.

# Schedule-based scale-out for business hours (weekdays, 8am-6pm UTC)
az monitor autoscale rule create \
  --resource-group myRG \
  --autoscale-name myAutoscale \
  --scale to 8 \
  --condition "Percentage CPU > 0 avg 1m"

# Schedule to scale down overnight
az monitor autoscale profile create \
  --resource-group myRG \
  --autoscale-name myAutoscale \
  --name night-profile \
  --count 2 \
  --min-count 2 \
  --max-count 4 \
  --recurrence-days Monday Tuesday Wednesday Thursday Friday \
  --recurrence-hours 20 \
  --recurrence-mins 0 \
  --timezone "UTC"

Storage tiering and lifecycle management

Azure Blob Storage offers four access tiers: Hot (immediate access, highest storage cost), Cool (infrequent access, lower storage cost, access fee per operation), Cold (rare access, very low storage cost), and Archive (near-zero storage cost, several hours to rehydrate). Data that starts in the Hot tier should migrate to cooler tiers as it ages.

Blob lifecycle management policies automate this migration. Define a policy that moves blobs older than 30 days to Cool, older than 90 days to Cold, and older than 365 days to Archive. For a typical log storage workload, this can reduce storage costs by 70–80% with no manual intervention.

{
  "rules": [
    {
      "name": "lifecycle-rule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {"daysAfterModificationGreaterThan": 30},
            "tierToCold": {"daysAfterModificationGreaterThan": 90},
            "tierToArchive": {"daysAfterModificationGreaterThan": 365},
            "delete": {"daysAfterModificationGreaterThan": 2555}
          }
        }
      }
    }
  ]
}

Budgets and anomaly alerts

Azure Cost Management budgets define spending thresholds that trigger email or action group alerts. Set a budget for each subscription and for important resource groups. Configure alerts at 80% of budget (warning) and 100% of budget (action required). Action groups can trigger an Azure Function or Logic App that automatically suspends non-critical workloads when a budget is exceeded.

Cost anomaly detection in Azure Cost Management uses machine learning to identify unexpected spending changes. It sends daily emails when it detects a cost pattern significantly outside normal bounds — useful for catching accidental resource creation, runaway autoscale, or an expensive API call being made unexpectedly often.