What is Azure Dedicated Host?

This month, Microsoft announced the introduction of a new method of running your Windows and Linux VMs within Azure. Dedicated Host is a new service that provides you with a single-tenant-host to run your workloads on. Or to phrase that more simply, your very own physical server in an Azure datacentre.

Azure Dedicated Host Groups (DHG) can be created within a region, availability zone, and fault domain. Your Dedicated Host is then created as part of a DHG and you can have multiple Dedicated Hosts per DHG. A Dedicated Host is a representation of a physical server in an Azure Datacenter. As your VMs are directly provisioned into your hosts, you can choose whatever configuration is required and available from the parent resources.

View of the new resources for dedicated hosts.

Two benefits from making use of Dedicated Host are:

Increased Control

As your Dedicated Host is allocated directly to your tenant, you have more granular control of placement configuration for all of your provisioned VMs. Also, you now control the timing of all platform-initiated maintenance operations, such as OS patching, or hardware or software reboots. This means you get the option to skip the regular platform update schedule, and then apply it when it suits within a 35-day rolling window.

Compliance Requirements

Azure Dedicated Host offers hardware isolation at the physical level which means your Azure VMs run on an isolated and dedicated physical server. No other VMs can run on your Dedicated Host. This can drastically help meet corporate compliance guidelines and standards. While also gaining visibility into the underlying cores to meet server-based software licensing requirements.

Configuration Options

Dedicated Hosts come in several configuration options. Each options allow for different VM series deployment combinations you are already familiar with. A table outlines an example for the Dsv3 Series:

Physical CoresAvailable vCPUsAvailable RAMVM Size# of VMs
4064256GBD2s v3
D4s v3
D8s v3
D16s v3
D32s v3
D48s v3
D64s v3

So at a quick glance, you can see there are several combinations of VMs that can be run on any single Dedicated Host. For example, 2 D16s v3 VMs + 1 D32s v3 VMs. However, bear in mind you will pay for the full Dedicated Host, regardless of VMs being run on it. You can read the full details for more information on pricing.

One nice note on pricing; the usual Azure Hybrid Benefit options are available for VMs running on Dedicated Host.

DHGs use Availability Zones and Fault Domains to give the greatest High Availability possible. So both need to be taken into consideration when designing your Dedicated Host deployment. The Dedicated Host docs, give good guidance on this already.

If Dedicated Host sounds like something you could make use of, why not give it a try. But remember, it’s still in preview so be careful and be aware of the limitations below:

  • Virtual machine scale sets are not currently supported on dedicated hosts.
  • The preview initial release supports the following VM series: DSv3 and ESv3.
  • During the preview, you won’t be able to resize a virtual machine deployed to a dedicated host.
  • Control over maintenance capabilities is in a limited preview. Start by taking this nomination survey to try them out.
  • During the preview we won’t be offering the option for reserved capacity.

How to – Reduce your Azure IaaS Costs

A regular starting point for most people when first using Azure, or any public cloud, is a virtual machine. Depending on your environment, VMs can be one of the most expensive resources. It’s no surprise that this can be a strong negative when considering a move to cloud.

Before anything is deployed, it’s important that you are aware of the tools that Microsoft make available to help you estimate your costs in advance. This can help both understand and avoid unwanted surprises with your bill.

First up is the Azure Pricing Calculator, with a bit of work, you can achieve an acceptably accurate cost estimate for an environment. I normally choose the default settings when it comes to pricing options (such as PAYG) as it gives me the most expensive and therefore safest estimate for a quick quote. If you have access to other consumption offers, ensure you are signed in so you can access their rates.

For this post I’m going to use a single VM estimate to display cost and changes. As it’s a single VM I have chosen a beast – M128m

Once you have your worst case estimate, it’s time to start making some adjustments to get that price down as low as possible. To do this, I recommend the following three options.

  1. Reserved Instances
  2. Automation
  3. Hybrid Benefit

First up, and most straight forward – Reserved Instances. They are a billing object that allows you to save money over a fixed period of time by paying for the usage up-front. From the screen grab you can see the savings can be approx. 64% for a three-year reserved instance. I have an old post that is still valid on RIs over here.

Again, you will pay the entire price up front, but look at the difference it makes to the monthly rate for our beast:

Next, modifying your usage hours using Automation. Now, this doesn’t have to be using Azure Automation and its Start/Stop solution as there are alternative like over on Azure MVP, Gregor Suttie’s blog. Whatever method you choose, update your usage hours in the cost calculator to see your savings, for this post I’m going to first remove weekends (average 8 days a month = 192 hours) and cut the remaining workdays in half (538/2). So instead of 730 hours, we get 269 hours and the appropriate reduction in price to our beast:

One thing to note at this point, if you’re using Reserved Instances, there is no point in using Automation to save on costs. RIs cover the full usage for the period.

Finally, the simplest to implement but arguably most complex option, Azure Hybrid Benefit. This is a licensing option that allows you to reuse your on-prem licenses in Azure. This is an option that can only be used in Azure and therefore a unique cost saving method. Applying it is simply a tickbox within your VM blade. Microsoft have a calculator to help you work out the licensing side of things, I’d recommend leaning on your LSP for this part as it can be a bit complicated and you need to make sure you’re compliant. You can see the savings below for our beast:

You’re probably already thinking it, can I layer these together and save even more? Absolutely.

Check out the reduction to the price of the beast if we apply AHB and a three year RI:

So what are you waiting for, head over to your Azure tenant and start saving some money on those VMs ASAP. As always, if there are any questions, get in touch!

What is Azure B-Series Compute?


Back in 2017, Microsoft announced the introduction of B-Series compute. Since then, the service offering hasn’t changed a huge amount but it is one of the most consistently misunderstood VM SKUs available.

Part of this is how they are displayed on the portal. Classed alongside the D series as “General purpose” but with a much more attractive price point, the B-Series appears to be a winner for all your workloads.

B and D series in VM size selector

Comparing a B2ms and a D2s_V3, there is a clear saving oper month regardless of your consumption offer. You can see they have the same amount of vCPU and RAM. Which is the most common deciding factor when sizing a VM. However, the B-Series has some unique features.

The B-series VMs are designed to offer “burstable” performance. They leverage flexible CPU usage, suitable for workloads that will run for a long time using as small a fraction of the CPU performance as possible and then spike to needing the full performance of the CPU due to incoming traffic or required work.

There are currently 10 different SKUs available, although not in all regions. yet. I’ve listed the current specs as available below:

SizevCPUMemory: GiBTemp storage (SSD) GiBBase CPU Perf of VMMax CPU Perf of VMInitial CreditsCredits banked / hourMax Banked Credits
Standard_B12ms 124896202%1200%3601212909
Standard_B16ms 1664128270%1600%4801623888
Standard_B20ms 2080160337%2000%6002034860

So the the ability to burst sounds great for certain workloads, however, it obviously isn’t unlimited. While B-Series VMs are running in the low-points and not fully utilizing the baseline performance of the CPU, your VM instance builds up credits. When the VM has accumulated enough credit, you can burst your usage, up to 100% of the vCPU for the period of time when your application requires the higher CPU performance.

Here is a great example from Microsoft Docs of how credits are accumulated and spent.

I deploy a VM using the B1ms size for my application. This size allows my application to use up to 20% of a vCPU as my baseline, which is .2 credits per minute I can use or bank.

My application is busy at the beginning and end of my employees work day, between 7:00-9:00 AM and 4:00 – 6:00PM. During the other 20 hours of the day, my application is typically at idle, only using 10% of the vCPU. For the non-peak hours I earn 0.2 credits per minute but only consume 0.l credits per minute, so my VM will bank .1 x 60 = 6 credits per hour. For the 20 hours that I am off-peak, I will bank 120 credits.

During peak hours my application averages 60% vCPU utilization, I still earn 0.2 credits per minute but I consume 0.6 credits per minute, for a net cost of .4 credits a minute or .4 x 60 = 24 credits per hour. I have 4 hours per day of peak usage, so it costs 4 x 24 = 96 credits for my peak usage.

If I take the 120 credits I earned off-peak and subtract the 96 credits I used for my peak times, I bank an additional 24 credits per day that I can use for other bursts of activity.”

So, there was quite a bit of maths there, what are the important points?

  • Baseline vCPU performance – This dictates your earn/spend threshold so if current vCPU is under the baseline you’re increasing your credits. If it’s over, your decreasing them. If it’s the same, you will earn and spend credits at an equal rate with no change to credit balance.
  • Peak utilisation consumption – If this is not allowing you to bank credits, you will eventually end up in a situation where you cannot burst so you might need to size up your VM.
  • Automation – Doesn’t work here, you only earn credits when the VM is allocated. Re-allocating your VM will cause you to lose your credits banked and start again from the starting allocation.
  • Starter Credit – You are allocated a starting credit which is (30 x “number of cores”)

You can monitor your credit spend and usage via Azure Monitor using specific Credit metrics. This will allow you to fire metric alerts relative to your VM. Very handy if you want to make sure you’re not pushing the performance consistently by mistake and therefore burning credits accidentally.

B-series compute, once understood correctly, is a great option to maximise cost efficiency in your environment. Once you’ve mastered the different approach required, you can make significant savings with relatively little effort.

There is a Q&A on some common topics here.

How to – Connect to an Azure VM

If you’ve just created your first Azure VM and are struggling to connect to it, this post should offer some help. I’ll cover connecting to both a Windows VM and a Linux VM, so RDP and SSH.

Connect to a Linux VM in Azure

To connect over SSH, you’ll need a client. A commonly used client is Putty, but you can use whichever you like. The first step is to know the details of your VM that are required to make a connection. When you built your VM, you would have created an administrator username and either a password or SSH key, ensure you have those to hand.

Next, you will need the IP or DNS name of the VM to connect to it. You can get this via the Azure Portal. If you click on the VM you want to connect to, it will by default open the Overview blade. From here, you will be able to copy the IP or DNS as required.

VM Overview settings

Then, using Putty, or a similar client, you can use that IP or DNS name, and port 22, to access SSH

PuTTY terminal settings

Once your session opens, you’ll be prompted for the credentials mentioned earlier.

Connect to a Windows VM in Azure

To connect via RDP, you’ll need to be using a machine that has an RDP client. This comes built into Windows. Next, you need to know the details of your VM that are required to make a connection. When you built your VM, you would have created an administrator username and a password, ensure you have those to hand.

Next, login to the Azure Portal, click the VM you want to connect to. This will open the Overview blade. From here you can click the Connect button. This will generate an RDP file for you to download and use.

Open the RDP file once downloaded. You may see some warnings relative to certificates, these can be ignored. Click connect.

Screenshot of a warning about an unknown publisher.

You will be prompted for credentials, these are the credentials as mentioned earlier. Once entered, you may see some warnings relative to certificates, these can be ignored.


If you’re having problems establishing a connection to your VM, first check if there is an NSG assigned to the VM or subnet the VM resides in. If there is, this NSG will require a rule to allow RDP/SSH access. By default, all connections via Public IP are blocked.

How to – Resize an Azure VM

When using VMs in Azure, one of the important things to get right is the sizing. Azure offers several VM series and multiple sizes within each that have fixed allocations of resource such as vCPU and RAM. There are also speciality series that offer additional capabilites like vGPU. Below is a table that covers the majority of series available and their recommended purpose.

There are many reasons you may need to resize a VM, but this post is about how to do it, rather than why. A quick tip, make sure you check out Azure Advisor for some help with this! Regardless of if you run a Windows VM or a Linux VM the below steps are accurate.

The first thing to note, you can resize a VM using any of the ARM tools you like. Such as CLI, Templates etc. However, for this post, I’m going to explain how to do it via the Portal. I would recommend that if you are new to Azure, this is also where you start, until you are familiar with the series and sizes as well as their respective costs.

Azure VMs are deployed on physical servers within an Azure datacenter. These servers are grouped together into hardware clusters. By design, each cluster does not support all VM series that are available. So if you are currently running a DSv3 series you may not be able to resize to a different series, such as an NCv2 immediately. You will however, always be able to resize within your current series.

Basic steps to resize

  • Login to the Azure Portal
  • Select the VM you need to resize
  • Click the Size option under Settings
  • Click the size you would like
  • Click Resize

NOTE: Your VM will need to restart, be wary of Dynamic Public IPs – the Portal should flag this.

Some things to note with the above process, when the VM is active and you click on Size, you will be displayed with a table of series and size currently available in the active cluster, as mentioned earlier. So for my VM, when active I see the below screengrab, note the highlighted number of sizes available.

If I Stop my VM before choosing the Size blade, I am now given the option to choose from the entire range available in the current region. Again note the highlighted number available in the below screengrab.

So, as I am sure you’ve guessed, to resize to any series VM, you must first Stop your VM. This ensure that the VM instance can be moved to a different hardware cluster when it’s started. Changing to a different series obviously takes slightly longer as you have to Stop your VM first etc. However, there is nothing else you have to do for this change.

Hopefully this post has helped understand how to resize and some of the series options you may need to address.

As always, if there are any questions please get in touch!