This blog post is based on conversations I witnessed between MVPs around commissioning and more importantly de-commissioning virtual machines (VMs) hosted in Azure. Don’t worry – this blog post is not going to divulge NDA material….
…my MVP award is way too valuable to me to squander it!!
It comes down to this simple fact – you might still pay for resource usage in Azure even after you have deleted your VM….
Because if you just delete your VM – you will leave behind resources that were associated with it.
Let’s look at how we spin up a VM:
I’m not going to go into all the different configurations I’ll choose – this post is about what is left behind when I delete the VM and why I’ll pay money unnecessarily.
As until I witnessed the discussion between MVPs (a quite vehement discussion BTW but that’s not for this blog post…) I had always plonked all my VMs in one Resource Group. you know to be tidy and concise…
Anyway – our VM is being deployed – this is the bit I love:
……creating resources means I get to try stuff out. This particular VM is for a DEMO I am going to do at a client site – we’re going to build SQL Server using Desired State Configuration (DSC) – in fact we’re going to build 20 SQL Server instances – and then create 10 Availability Groups – all from Source Control and all scripted. That is definitely for another blog post.
It’s gonna be awesome!!
So in the time it takes for me to make a coffee I have a new VM:
Let’s look at the resources in our Resource group:
So I’ve done the DEMO of SQL Server DSC (blog post coming) and now we want to get rid of the VM.
This is what I used to do:
Go into Virtual Machines and hit Delete
So within about 5 minutes our VM is gone – so let’s look in the Resource Group:
So the argument was that this was “designed’ by Microsoft to get money out of people – you know by keeping the resources that are left behind.
The actual story is that Azure allows you to share resources like network configs etc and doesn’t actually know if you want to keep these things – so it allows you to piecemeal manage the resources within your resource group.
The best quote I saw was:
” All of these things are how Cloud works. Nothing to do with Azure. The same is true on AWS. Everything is treated as single resources that can be “combined” to many different things and I don’t want anybody to just go and delete anything unless I explicitly tell them to. ”
This means that yes – if you manage your VM from a VM perspective and not all the resources associated with it – you will get charged for things lying around. It’s not a completely free cloud platform – for obvious reasons.
So – if you want to remove your VM in its entirety then place it in a Resource Group and remove the Resource Group. Thus you remove all resources associated with that VM and do not get charged unnecessarily.
There might be times where you want to host associated things within a resource group 0 my advice – label them and put tags on them so that you know what belongs to what if you need to remove things.
2 thoughts on “Why you should always build an Azure based VM in a Resource Group”
Great point since a resource group is the smallest granularity for a container of related resources, yes Iike to keep all experiments and demos in their own resource group.
I also like to keep persistent inexpensive resources that help re-create the demo/experiment in a separate resource group. E.g. keyvaults, any blob storage used for artifact storage, root DNS zones etc. And you can finish a demo showing what happens when you deploy an empty resource group with -Mode Complete 😉
LikeLiked by 1 person