To reduce Azure costs on unused and unnecessary resources, we should design with prevention in mind – considering whether we want to commit to reserved use or test with a pay-as-we-go model. We may experience situations where we already have many resources, but are unsure of their use – are these consistently used, sometimes used, never used? Before we can answer whether an unused resource (or what appears to be an unused resource) is unnecessary, we have to determine whether it’s used. In this tip, we’ll look at this challenge.
Organization of Resources by Total Cost
With strong measures to prevent unused and unnecessary resources from existing on the design side, we can focus on organizing our resources to identify unused and unnecessary resources that add to our Azure costs. As our environment grows, we may see one resource replace another resource since replacement in development can be a method to easily revert changes. One way to manage this is through tracking the total cost of each resource. In the Azure Portal, we can get this information by selection our subscription and Cost Analysis. Here, we can click on the “Cost by resource” and export the data (Excel or CSV), as we see in the below image.
Tracking resources by total costs also helps us save on Azure costs because unused and unnecessary resources that add high costs should be our major focus since these will have the largest impact. Unused and unnecessary resources that cost us less can be an eventual priority. For example, if we have 25 VMs in our environment with 5 being unused and unnecessary, but only 2 of them have high costs, those would be our first focus for disabling.
We can provide the information that we retain from this to teams within our company. The output of this information not only includes the resources and their cost, we’ll also see tagging information as well as location and resource type information that can be filters for organizing our Azure costs. We may use these categories for organizing teams – such as teams that tend to develop some resources or teams organized by tags.
Using the Azure Portal
In the Azure portal, we can obtain information about our resources related to their use to plan for our Azure costs. If we select a resource (we’ll use an example with VMs) and look at the Overview option, we’ll see data about the resource’s use over a period of time (we may dive deeper into data and performance metrics, but these provide a useful overview of a resource). In the below image, I’ve intentionally removed many details that are unrelated to where we get a resource’s use while showing where we would get information about this resource’s use (we see that I’ve selected 30 days and that we have options such as 1 hour, 6 hours, 12 hours, etc).
This helps us determine use very quickly for our Azure costs – is the resource even being used? In the below image, we see a separate resource that shows some network use over a period of time. We see that for this period of time, the resource is being used. Using these graphs may not tell us whether our use is necessary, but they can answer our first question about them being used and whether they may be using the best model for their use – reserved or a pay-as-we-go model.
We can also use these graphs to determine if our scale is appropriate for our Azure costs. If we determine use of a resource and confirm that the resource is necessary, can we improve its scale to save? This challenge may require more data, as our scale may be very high for one of its performance counters (such as memory, CPU, disk, etc), but low in another counter.
In the above image, we see a resource that hasn’t had any CPU use in the last 30 days and when we check other performance counters, we see this trend across all our performance counters. This may indicate that our resource is not being used – there may be a few exceptions where it hasn’t been used for a while, but if I see a high cost item from our organized list by cost and the resource has no use in the last 30 days, it needs to be reviewed.
Startups vs Large Organizations
In my experience of working for both startups and large organizations, the budget styles tend to differ in opposites. In the context of resource expenses, such as Azure costs, and budgeting I’ve seen that successful startups tend to be strict with their limited budget, as their concern is for validating their proof-of-concept. In the context of Azure and other cloud providers, this would mean that early in development, they favor a pay-as-they-go model because they want to retain as much financial resources as possible and ensure that they have enough customer demand before they commit to a resource contract for their supply. The majority of ideas fail and never materialize into products while the cost of resource use remain real. Applied to what we’ve seen with resource use, in these contexts we would be strict with resources that don’t show use.
Large organizations (excluding government) tend to emphasize the opposite: they have a set budget and they’re willing to commit an amount of the budget to new concepts for longer periods of time. In the context of Azure costs, this means that a year contract for reserved resources provides them with ample time (and a reduced cost when we look at the overall cost by time) to test their concept. Resources that don’t show use may be expected and may be retained until testing is done. This is because large organizations may test for longer periods even with low resource use because they have more capital to validate a concept.
The exception to both of these may be later in the business cycle, when investors in either startups or large organizations tend to be less patient.
A Word of Caution
We want to ensure that we remove resources that are both unused and unnecessary and possibly one or the other to save on Azure costs. We should take extra steps to ensure this is the case before we do, as it’s possible in companies that a developer is temporarily out and no one knows the resource’s function and the resource is actually necessary. For example, the resource may be used in a proof-of-concept and removal could impact development because the developer is away from work for a period. This is another reason I recommend beginning with the most expensive resources first, as these are more likely to involve multiple individuals within a company and allow for multiple confirmations before removal. This possible drawback of removal is another reminder of why designing our resources with costs in mind reduces further challenges.
Conclusion
We should remember that prior to organizing our resources for removal, prevention comes first in reducing Azure costs. If we don’t prevent unnecessary and unused resources from existing, this becomes a constant effort. From using pay-as-we-go to reserved resources, good design prevents these unused and unnecessary resources from existing with some minor exceptions. When we have many existing resources that we need to identify, organizing by costs helps us reduce the largest costs first when we determine use. This impacts us faster than the other approach. Finally, as we identify unused resources, or seldom used resources, we may use scale to our advantage to save on costs.
Table of contents
He has spent a decade working in FinTech, along with a few years in BioTech and Energy Tech.He hosts the West Texas SQL Server Users' Group, as well as teaches courses and writes articles on SQL Server, ETL, and PowerShell.
In his free time, he is a contributor to the decentralized financial industry.
View all posts by Timothy Smith
- Data Masking or Altering Behavioral Information - June 26, 2020
- Security Testing with extreme data volume ranges - June 19, 2020
- SQL Server performance tuning – RESOURCE_SEMAPHORE waits - June 16, 2020