This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.
With cost optimization being at the forefront of many conversations, organizations as well as individuals are constantly seeking new ways to optimize their Azure environment from an operational lens, remove the attack surface area and subsequently their spend in an automated fashion. Azure Advisor is one offering where consumers can review recommendations based on cost, security, reliability, operational excellence, and overall performance. There is a treasure trove of recommendations within each of these categories coupled with quick fixes, but some consumers want to take these recommendations a step further and leverage automation to do the heavy lifting for them.
If you have been following the tech community blog posts, there is a good probability you may come across the orphaned resources workbook. This workbook highlights many of the key areas where you can optimize different service offerings but for the most part the process to remediate is manual. The solution shared in this blog post is one example of how you can automate the remediation process based on business logic.
If you are not familiar with Azure Snapshot, it is a read-only copy of an existing disk in the Microsoft Azure cloud. We can create a snapshot of the OS (Operating System) or data disk and the subsequent snapshot can be used as a backup. It is quite common to see snapshots made before any change, to provide a method of rolling back. The snapshot can also be used to create a virtual machine at a very high level. In my experience, after a successful change, a change is closed, and the snapshots are left in the background accumulating cost over time. As time passes and the understanding of these snapshots are lost due to both staffing changes, environment changes etc there is an unwillingness to remove them. From both a security lens as well as operational lens, good hygiene is paramount as it reduces the attack surface area, removes complexity, and is cost efficient. The scripts below can be configured to remove snapshots older than 14 days in an automated fashion.
Leveraging Azure Automation or GitHub actions you could set up a trigger to run once daily or at whatever interval works best for your environment. When this script is triggered, it will automatically enumerate all subscriptions within your tenancy for snapshots that exist and have a created timestamp older than 14 days. If the above is true, it will automatically delete the snapshot/s. Caveat, this example works best when you have separate tenancy for your development and production environment. If you were using a single tenancy to carry host all workloads and they are segregated by subscription, then I recommend reviewing the examples below or you may find yourself in hot water with your change management team.
This example works well for environments where there is a strong tagging solution present. This script will enumerate all subscriptions within a tenant that have a specific tag (key value pair). In line 14 the key pair value is set to Environment: Development. Using this input, only snapshots in those subscriptions will be enumerated and subsequently snapshots older than 14 days will be deleted.
Like the script directly above this will enumerate snapshots (note: not subscriptions) that have a specific key pair value across the entire tenancy. It will then delete only those specific snapshots with the tag specified and have a created timestamp older than 14 days. Again, use this with caution if your development and production environment are in the same tenancy. You may land yourself in hot water with the change management team for making unplanned production changes.
As you can see from the above examples there are many methods that can be used to automate a solution to a problem. With the above logic, these scripts can be tailored to do a lot of the heavy lifting for cumbersome tasks. My key takeaways are to keep things simple as possible, have scale front of mind and consider who will need to provide ongoing support down track.