Azure Cost Control in Detail

There isn’t a magic button that can be pressed in Azure to reduce cost. The right level of spend in Azure is achieved as the sum of many frugal decisions. The right spending level is found by looking carefully in these three areas:

  • Processes. The processes put in place for standing up resources in Azure.  This includes approvals, cost estimates and other decision points.
  • Architecture. There are several choices that need to be made to implement a solution in Azure.  Performance, feasibility, experience, and fit are all important criteria.  Cost is sometimes not considered in this.  It’s not the only consideration but it is important.
  • Operations. A process of continuously measuring performance and resource allocation against cost and service level.

Improving practices in each of these areas or at least incorporating cost into the decision-making process will reduce cloud costs.

Reforming Existing Deployments

Often a point is reached where the Azure spend is considered a problem.  It might be that the spend is as it should be but without management the bill will almost always increase if only gently.  When deadlines pressure delivery or performance problems are faced often money is spent with Azure to address these issues.  The next problem comes along and reviewing spend is often pushed to the side.  This is normal in a busy team stretched for resources.  But a review of spend can reduce outgoings leading to savings or more often re-allocation of spend to more productive areas.  Why spend money with Microsoft when you can spend it building and improving service delivery?

There are several steps that can be taken to reduce overall spend:

  • Understanding existing spend. Review the current and historic bills looking for big ticket items and areas where spend has grown.  Understand the resources in Azure and which projects or services they are part of.  You may need to improve tagging to improve visibility of spend.
  • Assess Current Resourcing. Ask questions about each project or solution to understand whether there is room for improvement.
  • Build a list of reforms. Work through each project and understand opportunities for reduction in resourcing and spend.  Prioritise these and understand what the spend should look like if the reform is enacted.
  • Progressively reform the environment. Work on the list, re-prioritising and adding new items as they are identified.
  • Continuously Measure. Measure daily, weekly, and monthly to track reductions in spend against expectations.  We care about what we measure, and we measure what we care about.
Lets consider the first two…

Understanding Existing Spend

Azure billing works in a hierarchy.  All spend is contained within a Subscription.  Within each subscription are several Resource GroupsResource Groups contain Resources which are of a Resource TypeResources have one or more Meters which belong to Meter Categories.  A Meter for a VM might be hours or minutes of runtime.  For storage it might be the amount of storage.  Bills are made up of counts of units (Measures) of Meters for Resources within Resource Groups within Subscriptions.  The counts usually involve a period which might be hours or could be a charge per month.  Each Subscription has one or more Invoices which represent the total spend over discrete periods (usually a month) for all Resources in the Subscription.

This is all rather complicated.  Understanding Azure charges is difficult since each Invoice has tens or hundreds of thousands of line items.  Understanding them in aggregate is useful since grouping by resource type lets you focus on areas of concern.  Storage or Virtual Machines or SQL Services are useful.  But this won’t tell you what the resources are used for, its necessary to label the Resources to track and aggregate spend.  This is where Tags come in.

Assess Current Resourcing

Compared with Understanding Existing Spend, assessing your current resourcing is much more difficult.  Without knowing whether you are spending the right amount or not you can’t plan to reform.  For each of the applications or solutions you should ask a series of questions:

Is this system as small as it can be and only as big as it must be?
Use monitoring tools to eliminate headroom.
Right-sizing is an important consideration.  Usually there are provisioning points that can be lowered.  For instance, DTUs are the unit of provisioned performance for some SQL Server deployments.  If these are too high (relative to historical performance) then there is wasted spend.
Does this system need to run 24 hours a day, 7 days a week
Can the system be turned on and off easily to address only certain operational hours?
Many services can be turned off to conserve use.  Non-production environments can either be disabled/terminated out of hours or they can be reduced in scope and performance level.  Where possible this should be considered.
Are there more cost-effective ways to deploy components?
Deploying MS SQL Server on servers is inefficient, it may be more cost-effective to deploy it as a PaaS service.  Maybe deploy one with several databases instead of many SQL services.
It might be that architectural components of an application are immovable.  They might have specific reasons or constraints that mean they must be part of a solution.  It’s important though to look for the most cost-effective way to deploy the component.  Don’t just consider the Azure component, think about labour and the effort/risks involved in management.
Could we swap out components with different ones to lower cost?
Is it necessary to use licensed software for various purposes?  Would FOSS options be more cost effective?  For instance, sometimes MS SQL Server is used where services like PostgreSQL or MySQL may be a better choice.
Some components are commercially licensed when they don’t need to be.  Is it necessary to use Microsoft SQL as a database platform when MySQL may service adequately.  Microsoft SQL comes with licensing costs that are far higher than Open-Source database platforms.
Where can we eliminate servers from our architecture?
Servers or Virtual Machines are not very “cloudy”.  Where could they be eliminated and replaced with App Services or container deployments, possibly even serverless.
Servers are rigid, fixed-size resources that cost a lot to operate in Azure.  If they can’t be removed, then consider the size and family of the server.  Is a D series server necessary or is a B series (burstable) perfectly serviceable for far lower cost?  Additionally, if servers are required for long periods, then consider 1- or 3-year reservations to reduce overall cost.
What performance level is demanded from the business?  Are we meeting it or exceeding it?
This includes uptime, availability, performance and so on.  Each of these is achievable in the cloud to any level needed but sometimes over-provisioning occurs.
Azure offers high levels of service availability.  Some configurations come at a considerable cost, however.  Be careful to match the deployment options to the appetite for resiliency the business demands.  Previously with on-premises environments it has been difficult to meet expectations.  In the cloud the reverse is often true.


VMWare vs Proxmox in enterprise

What is proxmox? Proxmox is an open-source virtualization platform that integrates virtual machines (VMs) and containers into a unified solution. It is Debian/Linux based, uses

Delve Deeper »


We’re all about enterprise apps.  Assessment, modernisation, maintenance, migration and even new builds.

Reach out to use and we’ll work out how we can help.