Azure Cost Optimisation Tips

Manging environments on Azure can be a very rewarding experience but finding the right balance between cost and performance is a tricky business. The suggestions below have come from my experience of architecting, implementing and supporting Azure based platforms for numerous customers.

Regions Variations:

Regional pricing varies greatly, the UK datacentres for instance come at a premium over the EU data centres, this isn't a blanket price difference with different VM types costing different amounts in different regions. It pays to have a look at the Azure pricing calculator for different regions in order to find the most cost-effective region for your needs. The Azure VM Price website is updated daily basis and helps track regional variations. Multi-region architectures become complex and in most cases should be avoided especially due to latency and inter-region network connectivity as this currently still requires VPN connections in each region.


  • Don’t size cloud environments like you sized your on premise environments, get your applications up there and test and retest. There are currently 27 different VM Types each with over configuration 5 options for RAM, CPU and IoPs.
  • Review frequently, new VM models come along all the time.
  • Utilise Dev\Test Labs for non-production environments, VM here are costed at an OS license free level so you pay for only running costs. This includes not only the Windows OS but SQL 2016 and other Microsoft products as well.
  • New Burstable ‘B’ Series VM sizes offer massive discounts if your VMs infrequently require high CPU.
  • Configure Auto Start-up\Shutdown routines.
  • Use MSDN rights for development, this is slightly negatated with Dev\Test labs
  • Reserved Instances: A new entry to save money for long running machines, this is an effective way of reducing costs with claims of 72% cost saving over PAYG.
  • Hybrid Use Rights: If you have applicable Microsoft licensing for Windows Server, SQL Server etc. you can use your own licenses and pay only for the base VM and storage costs. There are several terms and conditions to meet in order to utilise these, so best speak to your Licensing partner.

VM Storage:

Give it Premium Dude - Standard disks for VMs are typically a false economy

  • Premium disks are more expensive but from experience it is worth it.
  • Lower Spec machine with premium disks can in some cases produce better perfomance than higher spec machine with standard disks.
  • No Single VM SLA on VMs with standard disks.
  • Premium disks are significantly faster performance.
  • Just beware disks costs continue when VMs are turned off.
  • If you want to use standard disks for VM storage stick to LRS (local redundant storage x3 copies), GRS (global redundant storage) costs alot more and for VM based storage is effectively pointless as data disks aren't crash or application consistent when accessed in the failover region and shouldn't be consider as a backup or disaster recovery mechanism.
  • Instead configure backups and ensure the Backup Vault uses GRS (globally redundant storage x3 copies plus 3 more copies in paired region). In the event of a disaster Azure will make your backup storage available in the paired region. These backups will be crash and application consistent.
  • Managed Disks – the jury is still out for me on the blanket use of managed disks, they undoubtedly ease VM creation and management but have several short comings (can’t be exported, and site recovery doesn’t yet support them).
  • With Managed Disks you also pay no matter what. With unmanaged standard disks, you pay as you consume, with premium disks you pay in size chunks. Comes down to the use case if you have a slow growing data set stick with unmanaged disks for now.

Beware the running resources:

  • vNET Gateways cost even when not being used, if you can peer networks you should if possible.
  • Beware the Logs – especially diagnostics these can grow like wildfire and can end up costing a lot, especially if using GRS.


Sizing SQL on Azure is very different than to sizing in a typical VM based environment, performance tiers are based on DTUs which is a mix of CPU, Memory and Disk. As with VMs its best to test your application and constantly monitor.

  • Scaling up and down is seamless, the resource you are on isn’t changed you are moved onto a new instance.
  • If you have multiple database add them to an elastic pool this enables you to share DTUs.
  • Performance recommendations are provided in the portal.

High SLA and Security:

If you don't have security concerns or you need a high SLA the chances are you Azure has a lot of free or low costs services, however these can become quite expensive if you require the advanced features.

A basic webapp can cost as little as well nothing, this is great for development purposes but in production the same webapp may have to be located in a secure application service environment and could ended costing thousands of pounds a month to run.

The best cost saving optimisation is too size your environment appropriately if you are throwing more and more resource to resolve performance issues, check and double check the code for issues. Application Insights is a fantastic tool for tracking what is going on in your web applications.


  • Rocking up with credit card and consuming Azure in the default pay as you go model is the most expensive way to consume Azure and should be avoided if possible.
  • Enterprise Agreements can bring significant discounts but also bring spending commits etc.
  • Working with a CSP like Kainos can help you tailor the right package for your needs and optimise your Azure spend.

Cost Management Tools:

  • Cloudyn now available on a free tier and is listed on the Azure portal. This is a very powerful tool for tracking and optimising your Azure usage.
  • Azure Advisor is a general tool that is free to help you optimise your Azure deployments, including recommendations on security, performance and cost savings.
  • Cost Alerts are a simple way of being notified by email if costs are escalating.