First published on TECHNET on Feb 21, 2018
Neil Bird here again, I am a Premier Field Engineer (PFE) in the UK Cloud & Infrastructure team. I am passionate about helping customers get the most out of Microsoft Azure and Windows Server technologies. This is the first in a series of blog posts where I will be sharing some information, scripts and approaches to help with Azure Cost Optimisation for IaaS.
Many ( if not all ) of the organisations I speak to have a strategy to migrate to public cloud in the near future, whether they are migrating their entire data centre or have a hybrid-cloud strategy, it is very easy for them to benefit from the increased Agility, Availability and Hyper-Scale offered by Microsoft Azure.
Azure provides the ability for customers to be able to very quickly and easily expand ( scale horizontally ) or shrink services dynamically depending on their business requirements. This elasticity and Azure's "pay as you go" model are a key business enabler, providing organisation with the flexibility to react to market conditions, new opportunities or internal projects with lightning speed.
For Infrastructure as a Service (IaaS) workloads, if you are spinning up ( deploying ) and tearing down ( deleting ) virtual machines ( VMs ) on a regular basis, there is a safety feature built into Azure whereby a VMs Disks are NOT automatically deleted when the VM itself is removed. This scenario ( NOT deleting the disks ) happens when a VM is deleted without deleting it's parent Resource Group, which is often the case if you have multiple VMs in the same Resource Group, possibly for RBAC delegation purposes.
For example, if you were to select a single VM in the Azure Portal and delete it ( without deleting the Resource Group ), this would mean that the OS Disk, Data Disk(s) and Network Interface associated with that VM would NOT automatically be deleted, these Disks effectively become " Orphaned " and would still incur storage costs in your subscription(s).
When you delete a virtual machine (VM) in Azure, by default, any disks that are attached to the VM aren't deleted. This feature helps to prevent data loss due to the unintentional deletion of VMs. After a VM is deleted, you will continue to pay for unattached disks.
This behaviour and some example PowerShell code to identify Orphaned Unmanaged and Managed Disks ( disks that are no longer associated with a VM ) are described in the following support article: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/find-unattached-disks
The sample PowerShell code included in the article above is very useful, however I received feedback from a couple of enterprise customers in the UK that it did NOT provide sufficient information for them to be able to make an informed decision as to whether it is safe to delete a disk or not. i.e - the "Disk URI" alone is not enough information.
Following this feedback, I decided to create a more comprehensive PowerShell script that provides the following functionality:
I wanted to share my PowerShell script with you, so that other customers can benefit from the additional disk information that can be exported when you audit your subscription(s) to Identify Orphaned Disks , the script can also Optionally Delete the disks that are identified; this is controlled using a script parameter that is off by default.
Example screenshot of the script in action :
The script requires: "AzureRM" Module v3.2 or above.
Example Syntax to Execute the Script :
Audit and Optional Delete Mode: ( The script still displays a yes/no prompt to confirm deletion )
.\azure-get-orphaned-disks.ps1 -DeleteUnattachedDisks $True
Excluding a Managed Disk : After reviewing the CSV Audit Report, if you would like to exclude one or more Managed Disks from being deleted, this is possible by creating a "Delete Resource Lock" on the Managed Disk(s). This might be relevant for scenarios such as Azure DevTest Labs that could have Managed Data Disks that are not currently attached to a VM. Or you might have a Disk that is required but is not always attached to a VM. To create a "Delete Resource Lock" from the Azure Portal, find the Managed Disk --> Settings --> Locks --> "Add". Give the Lock a Name and select the Lock type as "Delete", then "OK" to save.
Excluding an Entire Storage Account : After reviewing the CSV Audit Report, if you would like to exclude a specific Storage Account ( SA ) from being processed by the script, it is possible to temporarily create a "Read Only Lock" on the individual SA. This would prevent the deletion of All Unmanaged ( VHD ) Disks in that SA. This can be done from the Azure Portal, find the Storage Account --> Settings --> Locks --> "Add". Give the Lock a Name and select the Lock type as "Read-only", then "OK" to save. After running the script, you could delete the Read-only Lock from the SA. Note - Please make sure you do not impact other services if you create a Read-only lock on a SA, you may need to arrange a maintenance window if applicable.
Download Link :
Download the PowerShell Script from the TechNet Gallery
The goal and purpose of this script is to enable you to make an informed decision about an Orphaned Disk in your subscription(s) before deleting it. However, please make sure you perform enough due diligence during your audit / analysis and that you have backups in place prior to deleting any disks.
Feedback : Please let me know if this PowerShell script is useful by posting a comment below.
I hope you can use it to help optimise the cost of your Azure subscription(s) by deleting orphaned disks that are no longer required.
View other blog posts in the Azure IaaS - Cost Optimisation Series
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.