Building a Cost Optimisation Strategy for Azure

The five-layer framework

An effective Azure cost optimisation strategy consists of five sequential layers. Teams that skip to layer three without completing layers one and two typically find their savings erode within months as new waste accumulates and reservations are purchased for the wrong SKUs.

Layer 1: Visibility first

You cannot optimise spend you cannot see or attribute. Before touching a single resource, establish the data infrastructure that will make every subsequent decision evidence-based.

Mandatory resource tags. Define and enforce a tagging standard. The minimum viable set: environment (prod/staging/dev), team, and project. Use Azure Policy to require these tags on all resource groups and deny resource creation without them. Tags on resource groups are inherited by resources in Azure Cost Analysis, so group-level tagging covers resources that do not support direct tags (e.g., some networking resources).

# Enforce required tags using a built-in Azure Policy initiative
az policy assignment create \
  --name "require-cost-tags" \
  --display-name "Require cost allocation tags" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99" \
  --params '{"tagName": {"value": "team"}}' \
  --scope /subscriptions/{subscription-id}

Budget alerts. Set a budget for each subscription and for each team’s resource group scope. Configure alerts at 80% and 100% of the monthly budget. Add a forecast alert at 100% — this triggers when Azure predicts you will hit the budget before month-end, giving you time to act rather than just acknowledge an overspend after the fact.

Cost Analysis dashboard. Build a shared Cost Analysis view showing: total spend by team (tag), top 10 resources by spend, month-over-month trend, and forecasted month-end spend. Share this with engineering leads and finance. Visibility without an audience does not drive behaviour change.

Layer 2: Eliminate waste

Waste elimination is the highest-return activity in the early stages of cost optimisation because savings are permanent and require no ongoing financial commitment. Common waste categories:

• Orphaned resources: unattached managed disks, unassigned public IPs, empty App Service Plans, old snapshots. Find them with CLI queries and Azure Advisor. Delete them.
• Over-provisioned VMs: VMs running at under 5% CPU are flagged by Advisor. Validate with 30-day P95 metrics in Azure Monitor, then rightsize to the appropriate SKU and family.
• Idle dev and test environments: Dev VMs that run 24/7 but are only used 8 hours a day are paying for 16 hours of idle compute. Auto-shutdown schedules in Azure VM settings stop this immediately.
• Underused App Service Plans: A Premium v3 P2 App Service Plan hosting two low-traffic apps that together use 2% CPU is a common finding. Consolidate apps or downgrade the plan.

# Set auto-shutdown for a dev VM at 7pm UTC
az vm auto-shutdown \
  --resource-group myResourceGroup \
  --name myDevVM \
  --time 1900 \
  --email "devteam@example.com"

# Find unattached disks and calculate their estimated monthly cost
az disk list \
  --query "[?diskState=='Unattached'].{Name:name, SizeGB:diskSizeGb, SKU:sku.name, RG:resourceGroup}" \
  --output table

Layer 3: Commit for savings

Once workloads are rightsized and stable, purchasing commitment discounts is the most impactful single action available for reducing Azure costs on predictable workloads.

Reserved Instances (RIs). A 1-year reservation on a VM or database saves approximately 36–40% vs pay-as-you-go. A 3-year reservation saves approximately 56–72% depending on the SKU and region. RIs are purchased at the subscription or billing account scope and apply automatically to matching running VMs.

Before purchasing RIs:

• Confirm the workload has been running at the same SKU for at least 30 days post-rightsizing.
• Verify the SKU family has instance size flexibility so the reservation is not wasted if you later resize within the same family.
• Choose shared scope (applies across all subscriptions in the billing account) for maximum utilisation, unless you need to allocate costs to specific subscriptions for chargeback.

Savings Plans. Azure Compute Savings Plans apply a commitment (e.g., $10/hour of compute spend) at a billing account scope to any eligible compute service — VMs, App Service, Azure Functions on Premium plan, AKS, Azure Container Instances. The discount is slightly lower than an equivalent RI (around 35–65% depending on term and commitment level) but covers a broader range of SKUs, making them a better fit for teams with variable workload shapes.

Layer 4: Architecture changes

Some cost savings require architectural changes rather than configuration changes. These take longer but can deliver structural reductions that compound over time.

Scale-to-zero services. Replace always-on VMs or App Service Plans with services that scale to zero when not in use. Azure Functions on Consumption plan, Azure Container Apps, and Azure Container Instances all scale to zero and generate zero cost during idle periods. For workloads with significant off-peak time, this can reduce compute costs by 60–80%.

Right compute for the job. Not every workload needs a VM. A background job that processes a queue every 5 minutes is better served by an Azure Function than a VM. A set of microservices that could run as containers on Azure Container Apps will cost significantly less than the same services running on individually provisioned VMs.

Storage tier optimisation. Move data that is not accessed frequently to Cool or Archive blob storage tiers. Hot tier costs approximately $0.018/GB/month in East US; Archive costs approximately $0.00099/GB/month. For large datasets with infrequent access, lifecycle management policies automate tiering without manual intervention.

Database right-sizing. Azure SQL Database on a GP_Gen5_4 (4 vCores, General Purpose) costs approximately $368/month. If the workload is under 50% utilisation, dropping to GP_Gen5_2 saves approximately $184/month. For variable workloads, Azure SQL Serverless scales vCores dynamically and can pause automatically, reducing cost to near zero during idle periods.

Layer 5: Govern to sustain savings

Without governance, savings regress. New engineers create oversized VMs, orphaned resources accumulate again, and commitment discounts expire without renewal. The governance layer automates the prevention and detection of cost drift.

Azure Policy guardrails. Policies that prevent deployment of non-approved VM SKUs in dev subscriptions, require tags on all resources, and block deployment to expensive regions prevent new waste from accumulating. Policies with Deny effect are the strongest form — they block the deployment entirely rather than flagging it after the fact.

Automated Advisor review. Schedule a weekly automated pull of Advisor recommendations and log them to a storage account or send them to a Teams or Slack channel. New recommendations are automatically surfaced without anyone needing to check the portal manually.

Reserved Instance expiry alerts. Set calendar reminders 90 days before RIs expire. Renewal decisions require business input — do not let them lapse back to pay-as-you-go pricing by default.

Month-by-month rollout plan

The following is a realistic phased implementation plan for a team starting from zero cost optimisation maturity:

• Month 1: Define and enforce tagging standard using Azure Policy. Set subscription-level budget alerts. Export billing data to a storage account. Build a basic Cost Analysis dashboard shared with engineering leads and finance.
• Month 2: Run CLI queries and Azure Advisor to identify all orphaned resources. Delete unattached disks, unassigned public IPs, empty App Service Plans, and old snapshots. Enable auto-shutdown on all non-production VMs.
• Month 3: Review Advisor rightsizing recommendations. Validate with 30-day Monitor data. Begin resizing the highest-cost over-provisioned VMs. Target: complete rightsizing on all VMs flagged with high-confidence recommendations.
• Month 4: Review the previous 30 days of post-rightsizing data. Identify all VMs and PaaS services that are stable candidates for Reserved Instances. Engage finance to approve RI purchases. Purchase 1-year RIs for confirmed production workloads.
• Month 5: Begin architecture review for the highest-cost workloads. Identify candidates for scale-to-zero services, storage tier migration, and right compute. Create backlog items for architectural changes.
• Month 6: Implement Policy-based guardrails (allowed VM SKUs in dev, required tags, approved regions). Set up automated Advisor recommendation reporting. Deliver first formal chargeback or showback report to business units.
• Month 7 onwards: Monthly FinOps review cadence. Quarterly RI and Savings Plan review. Ongoing architecture changes executed through engineering sprints.