Two of the more challenging causes of an increase in Azure costs are unused and unnecessary resources. Unused and unnecessary resources may not always be the same, even though they can overlap. If we know the difference between these resource categories or when these resources categories overlap then we will see improvements in preventing these from adding to our costs. In addition, when we think about unused resources, we should consider options that we have with Azure to optimize for these, as an unused resource may still be necessary sometimes. In this tip, we’ll look at these topics to assist us with reducing our Azure use.
What Are Unused and Unnecessary Resources?
When we consider unused resources, which may be impacting our Azure costs, we want to first differentiate between unused and unnecessary while acknowledging that there may be some overlap with these.
- Unused resources. This category covers resources that serve no function in our architecture for a possible wide variety of reasons, such as their functionality being replaced or the functionality being completely unused (this could be temporary). A common example that we see is a team of developers created a resource that we use, but the team is replaced (or leaves), and a new team replaces the old resource with a new design with different resources. Our architecture uses the new design, but we still have the old design in place, affecting our Azure costs
- Unnecessary resources. This category covers resources that may or may not be in use, but is superfluous for our design – in some cases, functionality has replaced its need, but it still exists. A common example of this would be functionality that we have built and deployed in production, but this functionality has been replaced by other functionality, even if it still exists. In other cases, this type of functionality may be unused by clients, but hasn’t been deprecated. I include this because this category also affects our Azure costs in that we are paying for functionality that is not serving business value
Consider a scenario where we have an App Service that we’ve replaced with a new App Service and we keep the old App Service. It may (or may not) be unused, but the new App Service has made it unnecessary. There may be contexts in which we want to keep this unnecessary resource for a period of time before removing
We can save on Azure costs by removing unused and unnecessary resources, whereas other candidates may require more insight
In some cases, a resource may be both unused and unnecessary – extra copies of backups of applications that may not be able to be constructed due to requirements of old platforms are both unused and unnecessary – we couldn’t recreate these if we wanted. These are easy candidates for removal, as they are not used and they are unnecessary.
When looking at our Azure costs, unnecessary and unused may look the same
In the above image, we see an edited image breaking down costs – some of these may be unused while some may be unnecessary. For example, we may find that our use of virtual machines can be replaced with App Services – meaning our virtual machines are unnecessary because we have a superior replacement that will cost us fewer dollars and reduce our Azure costs. And we may also find that after we use App Services, we may find Function Apps serve us better at reducing our costs, making our App Services unnecessary.
In a different scenario involving unused resources, we may have virtual machines that we no longer use at all. These may have affiliated storage accounts for data storage, meaning that we can remove both the unused virtual machines and storage accounts once we’ve validated that these resources are no longer used and are impacting our Azure costs. But if we discovered that we used the virtual machines for one hour per day, these resources would only be unused in the context of a time period.
In general, developers and administrators can keep resources in existence just in case something happens, even if it’s impossible to restore those resources in their past state. Many of us have seen backups from versions of software that no longer exist and shouldn’t exist because they had numerous security problems or bugs, making the storage of these backups pointless. Even in these situations where we feel it may be obvious that storage won’t assist, we may still receive some pushback due to past habits.
Flat Cost vs. Cost Per Use
When we think about Azure costs, we should also consider a flat cost versus cost per use with resources. One of the best ways to avoid the challenge of unused and unnecessary resources is prevention and our design with flat costs or cost per use is one way to prevent this problem. An example is the Azure virtual machine model of pay-as-you-go versus reserved virtual machines (note that Azure will sometimes update its pages, so the comparison was present at the time of this article). What we term as unused in the example of virtual machines may be the fact that clients only need the virtual machine on 2 hours per day, so we have 22 hours of unused resource use. By contrast, we may need the virtual machine on every hour of the day because we know the pattern of use is throughout the day. In the pay-as-we-go model, we pay for capacity use, whereas with the reserved model, we have the equivalent of a contract with a virtual machine that we use.
While we may be tempted to reduce our Azure costs by encouraging the use of pay-as-we-go with all resources, we must remember that the pay-as-we-go model may not always be an option with resources and that we may receive a better deal with the reserved model. As we see from Microsoft, we may receive up to a 72% price reduction if we can predict our costs ahead of time. We can think about both of these models in the context of unit and security tests on a virtual machine where both the pay-as-we-go model and the reserved model may work for us with various testing scenarios:
- If our unit and security tests run on a cadence that is a few times per month, we will more than likely choose to pay-as-we-go. This is because we’ll be able to reduce our Azure costs by paying for the few times a month when we use the resources
If we constantly run unit and security tests throughout the day and re-use the same virtual machine for all testing, we may prefer to use reserved instances since the reserved instances will cost us less if our use is predictable in the context of a budget
If our VM had this must idle time, the pay-as-we-go model would help us reduce our Azure costs
In general, I recommend reviewing the Azure cost material and comparing it with your needs along with testing ahead of time to ensure that our choice is correct. The below questions also make a good starting point when we comparing the options of pay-as-we-go versus reserved in situations where these are options:
- Are we in the proof-of-concept state or have we already proven this concept?
- Do we have an estimate of our expected load and how could we show that (the latter part being more appropriate for startups)? With startups that don’t have any estimates of load, the pay-as-we-go model for Azure costs may be more appropriate if the budget is also unknown
- Do we have a set budget for a year or longer and is this subject to be changed quickly? Reserved can be cheaper, but we’re also committed
- Are we moving to Azure from on-premise? Since this scenario means we have data points on our load, the reserved model may be more appropriate, unless our on-premise application is cyclical
Conclusion
As we’ve seen, unused and unnecessary resources in Azure may pose problems to our Azure costs. By identifying how these resource categories can differ along with situations where these resource categories overlap, we’ve seen design methods for reducing these from existing in the from the beginning. By considering models of cost-per-use versus flat costs, we’ve seen that we can prevent some of these issues before they begin. We’ve also seen why we want to consider our workloads, as we may get much better pricing with flat costs when we know this during our design.
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