Sometimes a VM is not just a VM (Or: what to note when creating a VM in Azure)

Most of us, when getting into the public cloud world, the first action we do is to create a new VM.
Creating a VM is the “Hello World” of the cloud industry, and is considered a must-have knowledge for any self proclaimed cloud expert.
However, it turns out that creating a VM is far from being a straight forward process, and there are a lot of things you have to pay attention to, if you don’t want to burn a hole in your pocket at the end of the month.
I’ve already wrote about Why you should never look at the full price of a VM in Azure, and I know this saved a lot of people a lot of bucks, and today I want to talk about another aspect of creating a VM in Azure.

So you want to create a VM…

And naturally, the first thing you do is going to the Virtual Machines page in the portal, click Add+, and fill in the details.

Since you’ve read my previous post about saving costs of a VM you make sure to turn on the Auto Shutdown feature, thus saving more than 50% of the price.

You then pass validation, click Create, and see this:

VM Deployment

So what do we have here?

Well, it turns out that even though we asked for one resource (the VM), Azure was kind enough to bless me with no less than 5 new shiny resources.

So what did we get?

Here is what we have here:

  • Virtual Machine – Duh…
  • Virtual Network – Where the VM will be placed
  • Network Interface – So the VM will be able to connect to the VNet
  • Public IP Address – So I’ll be able to connect to the VM from the comfort of my home
  • Network Security Group – To protect the VM from unwanted inbound connections (note that by default the NSG does quite a poor job of protecting the VM, and you HAVE to modify it to make it effective).

So as you can see – we asked for one resource – and got five.

And the question, of course, is…

Why should I care?

Great question! Glad you asked.

So the answer here is twofold:

  1. Cost. These puppies cost money. Well, not all of them, but some of them. For example – public IP costs money. Not much, agreed, but still. In addition, disks also cost money, and even though the OS disk is not on the list – the default for Azure is to create Premium SSD disks for new VMs, which increases the cost by tens of dollars.
    But that’s not the most important aspect. The thing that really should get your attention is…
  2. Deleting VMs. And this is where the real fun begins. Say you’ve had enough with your VM, and you want to delete it. What would you do? Naturally – go to the VM page in the portal and click Delete. Now, note the message Azure shows you:
    VM Delete MsgAzure is kind enough to specifically point out that “associated resources (disks, virtual networks, etc.) will not be deleted.”.
    Problem is – no one really reads this message, right? We interpret it as: “Are you sure?”, click “Yes” and forget about the VM, and all its associated resources.
    But they’re still there, sucking our money and portal real estate.

Now, you might be wondering –

Why is that so?

Why sis Microsoft decide to separate the resources from the machine? Why not delete them all with the VM?

Well, there’s actually a very good reason for that.

For example: Say you want to replace the VM with App Service, but you want the end user to not know that. One of the things you want to make sure of, is that the App Service will keep the IP address the VM had. That would be quite difficult if the IP is deleted together with the VM.

Another example – Say you want to move the VM to another VNet. Unfortunately, there isn’t a built-in option for that. The only way to do that is to delete the VM, and create a new one based on its disk. That wouldn’t be possible has the disk been deleted.



Remember – VM is not a single resource. It always comes with an entourage of associated resources. You have to remember that when estimating your costs, and even more – when deleting the VM.

Happy VMing!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.