There are many lists out there of common mistakes people make in Microsoft Azure. In this article, we are going to specifically focus on the ones that Managed Service Providers (MSPs) make in Azure, as they can be somewhat different and unique to this space.
1. Selecting Non-optimal VM Sizes for Servers and Session Hosts
There are many use cases for Virtual Machines in Azure, but MSPs, who typically service Small and Medium Size businesses, would probably use them for just a few purposes. Some examples of roles that virtual machines are typically used as domain controllers, file servers, application servers, database servers, remote desktop session hosts and Windows Virtual Desktop (WVD) hosts.
It is very common for someone unfamiliar with VM families and SKUs to randomly pick any VM size that is similar in core count and memory required for their needs. However, it is important to know there is a big difference, for example, between D2sv3 and DS3v2. Although VM SKUs look similar, perhaps even the same in core count and memory, it is important to understand the differences and pick the right one. Picking a non-optimal VM size can cause negative pricing ramifications and degraded performance and sometimes even both.
For domain controllers, it is very common to use a B-series machine since these machines provide significant value and will give you the performance a typical domain controller needs.
For file servers, this can be quite tricky as CPU, core, and memory aren’t the only thing to consider. Picking the right storage type and size is equally as important when optimizing performance on a file server (more on this in point in number 3 below). A typical VM size to select might be a D2asv4 or a DS3v2 for larger premium disks.
For application servers, referring to the recommended system requirements from your vendor is your best bet. Common VM families used here are the DASv4 or EASv4 types. There is also a difference between hyper-threaded cores and non-hyper threaded cores. For example, a DASv4 machine family uses hyper threaded cores while the DS2_v2 does not. Performance on the DS2_v2 would be better, since they will perform like physical cores rather than virtual cores. Checking with your application vendor to see what they recommend is the right thing to do.
WVD & RDS
For Windows Virtual Desktop, session hosts, or RDS servers, it’s a good idea to use a machine that has a higher CPU core count to allow some room for bursting. It is also a good idea but not absolutely required to use an E series machine. E series machines have double the memory for only 15% more cost. The memory will come in handy if you have users using a lot of browser tabs or opening a lot of Office documents. Even NV series VMs would offer a performance boost as NV VM’s have a GPU attached to the machine which could offset some load from the CPU allowing you the ability to put more users on a session host.
2. Using a Deprecated Virtual Machine Family
When we look at partners that inherit an Azure environment from another MSP, it is very common to come across an environment that is on the Azure Classic platform rather than the modern Azure Resource Manager (ARM) model. When we see that, there is a high likelihood that the VMs were configured a long time ago and no maintenance has been done to resize the machine to use modern hardware. Azure does deprecate VMs over time by either not offering them anymore or making the cost increase, which incentivizes you to resize to a more modern, better performing VM that actually costs less.
If you are inheriting an Azure environment or reviewing an Azure environment that has been built a few years ago, you may find VMs running on older VM SKUs. It is a good idea to resize them to the current VM SKUs. You’ll see much better performance and likely at a much lower cost. A win-win situation!
3. Using Premium SSDs on VMs That Can’t Handle the Full Potential of the Disk
Oftentimes when reviewing a quote or build that a partner brings to us, it’s common to see that premium SSDs are used everywhere. While premium SSDs are best in class in terms of speed and SLA, it is also important to consider the VM SKU being paired with the premium disk. Not all VM sizes can take full advantage of the premium disk you give it. If you look at Microsoft’s premium SSD documentation, you will notice that the larger the premium disk is, the more IOPs and MB/s throughput that disk is capable of. However, what most people don’t know is that each VM SKU can only handle a maximum IOPS and MB/s throughput. This means that if you assign a very large premium disk—let’s use a 4TB premium SSD (7500 IOPS) as an example--and pair it with a D2sv3 VM, the VM documentation shows that the VM can only take advantage of a disk with IOPS that will max out at 3200 IOPS. The VM would never be able to take full advantage of the full capability of that premium disk and you are therefore wasting money if higher performance is what you are looking to achieve.
Make sure you select a VM that is properly sized to take full advantage of the premium disk you assign to it by picking a VM that has greater IOPs and MB/s throughput than all the combined disks assigned to that VM.
4. Using Standard HDDs for Heavy Production Workloads
Quite the opposite can also happen. We will see mission critical workloads being assigned standard HDs or standard SSDs. All mission critical workloads should be using a premium SSD disk. Your workload performance will certainly increase compared to a standard SSD or standard HDD. The rule of thumb is that if the disk serves data to an end user, make it premium. With that said, make sure you follow #3 above and size your VM appropriately for the disk.
5. Selecting the Wrong Tier or Azure Files and Not Allocating Enough Storage
When using Azure files for mission critical workloads such as hosting FSlogix profiles for RDS or WVD, I see the use of standard tier Azure files used. The challenge will always be the speed of WVD if you select anything but premium tier storage for Azure files. However, just selecting premium is not good enough. You also must allocate decent quoting size to get the IOPS you are looking for. Azure files’ formula for IOPs is 400 IOPS, +1 IOPS per GB you assign to the Azure files share. This means that if you want more IOPS (up to 100,000) you must allocate more GBs to the share. Performance degradation can come from not using premium tier storage and not allocating enough storage quota to your Azure files share.
6. Forgetting to Order Reserved Instances on Virtual Machines
Reserved Instances are an absolute must when it comes to cost control and saving money in Azure. To read more about Reserved Instances, read this article. A very high percentage of partners do not opt-in for Reservations for their VMs. Without Reserved Instances, your Virtual Machines are running at the pay-as-you-go rate, which is the absolute most expensive way to pay for Azure. I believe partners are so busy that they either forget to do it, or don’t know how to do it. If you are working with a CSP Distributor, you need to contact them to order and lock in your Reserved Instances and make sure every running VM is covered by a Reserved Instance. Here are some instructions how to do this: How to Increase Your Margins with Azure Reserved Instances
7. Forgetting to Toggle Azure Hybrid Benefit
Equally as important is purchasing the licenses required for Azure Hybrid Benefit and not forgetting to TOGGLE the switch on each VM to take advantage of AHB. Read more about Azure Hybrid Benefit here. Similar to Reserved Instances, partners often forget to do this as well. Renting an OS or SQL license from Azure is by far the worst way to acquire the necessary Windows licensing for your VM.
Purchasing the licenses isn’t all you need to do. You must tell Microsoft that you own a compatible license for Azure for them to give you the appropriate discount. See this article on how to apply your AHB license.
8. Improperly Licensing Microsoft SQL Server
If you have applications using SQL on Azure VMs, it is very important to understand how SQL can be licensed in Azure. Unlike on-premises where you can license SQL by the User and CAL model, you cannot do this in Azure. SQL can only be licensed under the Core model, and you must purchase a minimum of 4 cores per SQL Standard instance regardless of if your machine is under 4 cores. Core license are sold in packs of 2.
There are currently two supported models of purchasing SQL licenses under the Core model in Azure:
- CSP Software Subscription SQL Server 2 Core Pack (1 year or 3 years)
- OPEN license for SQL Server per Core model with Software Assurance
If you don’t have either of these two types of licenses, you may not use this in Azure. The licenses will need to be repurchased under the correct licensing program.
It is also important to take advantage of Azure Hybrid Benefit for SQL Server licensing. Over a 3-year term, renting the SQL Server license under the Pay as you Go model will cost you over $3,000 for a 4 Core SQL Server compared to bringing your own license under the CSP or OPEN license with Software Assurance program and taking advantage of Azure Hybrid Benefit. The drawback is that it is an upfront payment vs renting it month to month.
9. NSG Inbound Outbound Rules
Understanding how Network Security Groups (NSG) work is important to the security of your Azure environment. NSGs are like your stateful firewall. They can be set to ALLOW or DENY traffic to your virtual network in Azure. Most NSG’s are misconfigured, thereby giving full access to the outside world on all ports or specific ports such as 80, 443 or 3389. Hunker down and learn how NSG’s work as getting it wrong can pose a huge security risk to your network and frustrate you when traffic does not flow, you cannot connect, and cannot seem to figure out why.
10. Not Patching your VMs Running Azure
Believe it or not, when VM’s are deployed in Azure, there is a high likelihood the VMs aren’t patched like machines that are running on-premises. A Virtual Machine running in Azure is no more secure or less secure than a VM running on premise. It is very important to install your RMM tools and anti-virus software on VMs running in Azure as well. Treat them the exact same way and put them on the same patch schedule as a VM running on premise. Do not neglect your VMs in Azure as they too need to be safe and treated with care.
Azure even has a Windows Update Manager service that you can enroll your VMs to that will help patch your machines if you don’t feel like using your RMM tool to do the job. Here is how to enroll your VM and use Update Manager.
These are the 10 most common Azure mistakes we see MSPs make. Keeping these points in mind when you are working with Azure will help you be more successful. And, of course, we are always here to help assist you.
Click here to try Nerdio Manager for MSP free for 30 days!