If your Azure bill has been creeping up faster than your headcount, you are not alone. Most early-stage to mid-market clients we audit are paying 20 to 35 percent more than they need to, without any change to performance, reliability or developer velocity. Here is the checklist we use.
Step 1: tag everything, then look at it
Most cloud bills are unreadable not because the cloud is complicated but because nothing is tagged. Enforce three tags as a policy (Azure Policy or AWS SCP): cost-centre, environment (prod/staging/dev), and owner. Then open Azure Cost Management or AWS Cost Explorer and group by those three tags. Within an afternoon you will know where 90 percent of your money is going.
Step 2: reservations and savings plans on the steady-state
If you have any workload that has been running 24/7 for the last 90 days and will continue to do so, it should be on a 1 or 3 year reservation or savings plan. Typical savings: 30 to 60 percent for compute. There is no downside as long as the workload is genuinely steady-state.
- Azure: reserved VM instances, reserved SQL Database / Cosmos DB throughput, App Service savings plan
- AWS: EC2 savings plans, Compute savings plans (cover Fargate too), RDS reserved instances
Step 3: spot or preemptible for batch and CI
If your workload can tolerate interruption (CI/CD runners, batch processing, data pipelines, dev environments), spot instances are 70 to 90 percent cheaper than on-demand. The trick is to architect for interruption: checkpointing, retries, queue-based work distribution. For CI specifically, your runner orchestrator (GitHub Actions, GitLab) almost certainly supports spot pools natively.
Step 4: kill the zombies
Run a 'zombie report' once a quarter:
- Unattached managed disks (you stopped a VM but did not delete the disks)
- Unattached public IPs (a load balancer was deleted but the IP is still allocated)
- Old snapshots and backups (retention policies that nobody set to expire)
- Idle test/dev environments (auto-shutdown was not configured)
- Forgotten storage accounts holding old logs and exports
The first time we run this for a client we typically find 5 to 12 percent of their monthly bill in pure waste. The recurring saving is real and zero-risk.
Step 5: right-size and modernise
Most lift-and-shifted VMs are 2 to 4 sizes too big. Use Azure Advisor or AWS Compute Optimizer's recommendations as a starting point, but apply judgement: aim for 50 to 70 percent average CPU utilisation, leaving headroom for spikes. For any workload that fits, move from VMs to managed services (App Service, Container Apps, AKS, Lambda, Fargate) where you stop paying for idle capacity.
Step 6: storage tiering
Hot storage on a blob you read once a year is one of the easiest wastes to fix. Set lifecycle policies to move data to Cool, Cold or Archive tiers based on age or last-access. For Azure: lifecycle management on storage accounts. For AWS: S3 Intelligent-Tiering or explicit lifecycle rules.
Step 7: track it
Set a monthly cloud cost number per cost-centre and review it monthly with the engineering lead. Set an alert at 110 percent of the previous month so a runaway resource group does not surprise you. This is the cheapest, highest-impact 30 minutes you can put in your diary.
Realistic 60-day savings target
On a clean engagement we typically deliver: 8 to 15 percent saving from zombies and right-sizing in week 1, 15 to 25 percent additional from reservations and savings plans by week 4, 5 to 10 percent additional from storage tiering and modernisation by week 8. Total: 28 to 50 percent. Your mileage will vary, but if your number is under 20 percent something is wrong with the analysis, not the cloud bill.