Using Microsoft Azure B-series VMs: recommendations

I have some tips I’d like to share about the performance of Microsoft Azure B-Series burstable VMs. You’re reading this page served by one…what do you think? Not bad?

Recently, I decided that it was time to rebuild from scratch the newbie VM I’d been running on Azure in the old service model for more than four years. That meant it was time to rethink which cloud VM to use.

Azure (and AWS) offer families of VMs that allow the architect to precisely match the workload to cost and performance parameters. Many architects simply compare cost, memory and CPU specs when selecting which families and members in those families to use.

But it’s a bit of an art to select the correct cloud VM family and size. It’s important to consider CPU internals, including processor family, number of cores and cache size. This is why DevOps should be engaged with application architects: when you are building a cloud infrastructure, you need to know how the app works.

On the old VM, I used a Basic.A2 VM (yes, that old). For this rebuild, I chose Standard_B2s B-series VM. Given that the OS, disk type, file system and patch level was held constant, the much improved performance noted in this VM had to be attributable to the change in virtual processor. (And, possibly to the hypervisor’s approach to dispatching these VMs.)

The burst algorithms vary between Azure and AWS, but the concept is the same: you bank CPU usage until you need it. But there’s an issue: initial performance is unacceptable in a burstable VM that’s just stared because it’s got no credit in the bank. Depending on the rate that credits are applied, you might have to run the VM for hours to reach an acceptable level of performance, especially if the VM’s baseline CPU allocation is small. Baseline CPU allocation is the percentage of the CPU your burstable Azure VM or EC2 instance can get 100% of the time it’s running.

Both AWS and Azure overcome the start-up challenge by providing initial credits so you can get going. AWS’s design actually offers two different kinds of credits with a separate baseline bucket in its T2 burstable EC2 instances. What Azure does isn’t as clear but it’s a good bet it’s doing something similar.

After you’ve picked the B-series VM size in Azure (or for your EC2 instance) it’s very important to monitor it. In Azure, two metrics are specific to B-series VMs: CPU credit consumed and CPU credits remaining. It’s a snap to add a graph of these two metrics on your Azure portal dashboard. This is something you should do as soon as you start the VM.

In the image below, you can see a VM that was launched about 24 hours ago. Note that it was started on a Friday night, local time, to give it the chance to build a bank of credits for Monday morning. Why pick a specific launch time to allow for credit collection? It’s simple: the initial credits you receive when you start the VM are likely to be used to get everything up and going.

Azure burstable CPU consumed and remaining
Azure burstable CPU consumed and remaining (click to enlarge)

This makes burstable instances unlikely to be useful for containers. Think about it: if you use your initial bank up getting the container launched, the app will not perform acceptably.

On the other hand, when you are running a website like this VM does, where arrival rates spike when a new post becomes available or newly popular on Google, having that bank of credits delivers better performance than a fixed CPU size will.



, ,




2 responses to “Using Microsoft Azure B-series VMs: recommendations”

  1. jerome Avatar

    Hi Alex,


    is there a real advantage?

    I can see a difference of only 10$ a month for a 4vCPU VM.

    so for 10$ less, I have a slower VM which can perform normally hen I banked enough credit.


    or does the price of a B VM is lower when you consume less than the X% for the VM?

    like if I consume less than 90% of my 4vCPU B serie VM, does the cost will be lower?

    and I pay the full price only when I’m in burst mode?

    1. Alex Neihaus Avatar
      Alex Neihaus

      Hi, Jerome.

      No — the cost for a burstable VM is fixed on a per-minute (Azure) or per-hour (AWS) basis.

      I don’t doubt that a fixed-allocation Azure VM or EC2 instance might not cost “that much more,” depending on how many of them you need and what your preferences are for any given workload.

      But the one thing you can’t get from a fixed-allocation VM or EC2 instance is the ability to run “hotter” for a period of time. When you need it, you can burst beyond your apparent allocation for short periods of time (until your credits are used up).

      Looked at this way, burstable VMs or EC2 instances not only save money — they save your butt when you have periods of out-sized demand. In short, they are useful for uneven workloads that have valleys long enough to accumulate credits.

Leave a Reply

Your email address will not be published. Required fields are marked *