Recently I’ve started to play around with Azure, Microsoft’s cloud. In this blogpost, I’ll be sharing some of my initial findings, which might prevent you from making the same rookie mistakes as I made ;)

First of all, compared to other cloud providers such as Vultr and Digital Ocean, Azure is quite expensive. However, should you have a MSDN account, you might be eligible for free Azure credit up to $150 per month! For more information, visit https://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details

The Azure control panel might be overwhelming at first, but it’s pretty intuitive once you start using it. Basically the workflow is from left to right, i.e. if you click on an option, a new screen opens to the right.

Image credit: http://pumpingco.de/your-own-game-server-on-azure-create-a-dedicated-counter-strike-server/

So without further ado, here’s my list of top tips & tricks for Azure rookies:

• Even though IPv6 is supported for Azure VMs is available in most regions, you cannot assign a IPv6 directly to a VM. It can only be assigned to a load balancer. Additionally, you may not upgrade existing VMs to use IPv6 addresses. You must deploy new VMs. Lastly, you cannot add IPv6 load balancing rules in the Azure portal. The rules can only be created through the template, CLI, PowerShell.
  Source: https://docs.microsoft.com/nl-nl/azure/load-balancer/load-balancer-ipv6-overview

• If you want to save money by switching off VMs you don’t use during certain times (for example during the night or outside office hours) you can have Azure automatically switch off these servers. However, if you want Azure to also automatically start these servers (for example in the morning), you either need to create a Automation Runbook or (re)create the server in a so-called DevTest lab.
  VMs in a DevTest lab support auto-start and auto-stop out-of-the-box. For more information, visit: https://docs.microsoft.com/en-us/azure/devtest-lab/devtest-lab-set-lab-policy#set-auto-shutdown
  VMs created outside a DevTest lab only support auto-stop out of the box. If you want a normal VM to auto start, you need to use a Automation Runbook or re-create the VM in a DevTest lab. For more information, visit: https://automys.com/library/asset/scheduled-virtual-machine-shutdown-startup-microsoft-azure

• VMs are automatically allocated a dynamic WAN (‘internet facing IP address’) in order to communicate with the internet. This causes the IP address to change when you stop and start the VM, for example using auto-start/auto-stop as described above. You can specify a DNS domain name label for a public IP resource, which creates a mapping for domainnamelabel.location.cloudapp.azure.com to the public IP address in the Azure-managed DNS servers. For instance, if you create a public IP resource with contoso as a domainnamelabel in the West US Azure location, the fully-qualified domain name (FQDN) contoso.westus.cloudapp.azure.com will resolve to the public IP address of the resource. This is particularly helpful in case of using a dynamic IP address.
  Should you not want this, you can assign a static IP to the VM. However, you cannot specify the actual IP address assigned to the public IP resource. Instead, it gets allocated from a pool of available IP addresses in the Azure location the resource is created in. For more information, visit: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-ip-addresses-overview-arm
  
  It’s possible to delete the VM and preserve the static IP address, for example to assign to another/new VM. In order to do so, do not delete the entire resource group that is associated with the IP address. Instead, shutdown the VM, then delete the NIC associated with the static IP you want to preserve. Then delete all other components in the resource group except for the IP you want to preserve. Please do note that IP addresses cannot change resource groups, so in order to re-use the IP address, you need to create a new VM (or load balancer) in the same resource group as the IP address.

• VMs in a DevTest lab are deployed without a Network Security Group (also known as a firewall) within Azure. They only come with the default Windows Firewall running on the machine itself. Should you want a NSG/Firewall within Azure as well, you can deploy one yourself in the same resource group and assign it to the VNet of the VM you created in the DevTest lab. Please do note that this requires you to forward ports in twofold; one time within the VM itself in the Windows Firewall and the second time from within the NSG/Firewall in the Azure portal.
  
  
  Image credit: http://pumpingco.de/your-own-game-server-on-azure-create-a-dedicated-counter-strike-server/
  
  This is also the case with normal VMs (i.e. VMs that are not created in a DevTest lab) as they come with a NSG/firewall by default.

• Azure offers two types of storage disks: SSD (Premium storage) and conventional HDD (Standard storage). SSD disks come in 3 sizes, 128GB, 256GB, 512GB. HDD disks have a flexible/user chosen size which can vary up to 1TB. You need to create a software RAID in order to get a large volume/disk.
  Premium Storage supports DS-series, DSv2-series, GS-series, and Fs-series VMs. You can use both Standard and Premium storage disks with Premium Storage supported of VMs. But you cannot use Premium Storage disks with VM series which are not Premium Storage compatible (for example the A-series or Av2-series).
  If you’re using standard storage, you’ll only be charged for the data you’re storing. Let’s say you created a 30 GB VHD but storing only 1 GB of data in it, you will only be charged for 1 GB. All empty pages are not charged.
  HOWEVER, if you’re using SSD (premium storage) you pay for the FULL SSD disk regardless of how much data you stored and empty pages are charged… so it becomes expensive pretty quick. For more information, visit https://azure.microsoft.com/nl-nl/blog/azure-premium-storage-now-generally-available-2/ and https://docs.microsoft.com/en-us/azure/storage/storage-premium-storage

• Azure Storage provides the capability to take snapshots of your VMs. In order to take snapshots of your VM, you need a Recovery Services vault. A Recovery Services vault is an entity that stores all the backups and recovery points you create over time. The Recovery Services vault also contains the backup policy applied to the protected files and folders.
  Previously, when you created a backup vault you had the option to select locally redundant storage (LRS) or geo-redundant storage (GRS). This has now changed and you do not have the option during the vault creation.

  Now, by default, your vault will be created in a GRS, which costs (way) more than LRS (almost double!). If you want to switch to LRS, you must do so after the vault has been created but PRIOR to registering any items to the vault. You cannot switch the storage type of your Vault after you registered any items to it! To do this, simply access the Configure tab of your backup vault and change the replication from the default of GRS to LRS. Don’t forget to click Save…
  
  For more information, visit: https://docs.microsoft.com/en-us/azure/backup/backup-configure-vault

• When you create a VM in Windows Azure you are provided with a temporary storage automatically. This temporary storage is “D:” on a Windows VM and it is “/dev/sdb1” on a Linux VM and is used to save the system paging file. This temporary storage must not be used to store data that you are not willing to lose, as there is no way to recover any data from the temporary drive. The temporary storage is present on the physical machine that is hosting your VM. Your VM can move to a different host at any point in time due to various reasons (hardware failure etc.). When this happens your VM will be recreated on the new host using the OS disk from your storage account. Any data saved on the previous temporary drive will not be migrated and you will be assigned a temporary drive on the new host. Because this temporary storage drive is present on the physical machine which is hosting your VM, it can have higher IOPS and lower latency when compared to the persistent storage like data disk. The temporary storage provided with each VM has no extra cost associated with it for storage space as well as for transactions. For more information, visit: https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/
  If your application needs to use the D drive to store data, you can to use a different drive letter for the temporary disk. However, you cannot delete the temporary disk (it’ll always be there), you can only assign it a different drive letter. For instructions on how to do so, visit https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-classic-change-drive-letter

• Azure VMs run on VHDs which can be downloaded and run locally in Hyper-V. For more information, visit https://www.petri.com/download-azure-vm-hyper-v

• When you create a new VM in a Resource Group by deploying an image from Azure Marketplace, the default OS drive is 127 GB. Even though it’s possible to add data disks to the VM, sometimes you need to expand the OS drive ‘because of reasons’. Instructions on how to do so can be found here: https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-expand-os-disk

• Microsoft Azure VMs often include licensing built right in, but not for everything. For example, you do not need to acquire a separate license for Windows Server 2016 Datacenter within the VM, as it is included in the per minute charge for the Virtual Machine already. For more information, visit https://blogs.technet.microsoft.com/uspartner_ts2team/2014/08/31/microsoft-azure-vms-often-include-licensing-built-right-in-but-not-everything/ and http://www.microsoftlicensereview.com/?cat=5051

That’s it for now!