What is Azure B-Series Compute?

images

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_B1ls110.545%100%30372
Standard_B1s11410%100%306144
Standard_B1ms12420%100%3012288
Standard_B2s24840%200%6024576
Standard_B2ms281660%200%6036864
Standard_B4ms4163290%400%120541296
Standard_B8ms83264135%800%240811944
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.

What is Azure Bastion?

Microsoft released an introduction video to Azure Bastion a couple of days ago and today a new post has gone live giving us all the details of Azure Bastion in its preview state.

First up, what is a Bastion? Often referred to as a jumpbox, jumphost or bastion host, it’s a server which provides access to a private network from an external network, most commonly the Internet. As it’s exposed to potential attack, bastion hosts must be designed to minimize risk of penetration. As this connectivity function is so widely used, bastions are quite common in the majority of environments. The alternative is to increase your perimeter exposure by allowing public access to your private resources directly. Little tip from me, please don’t do this!

However, management and administration of these hosts can be a complex and time consuming task. Thankfully, Microsoft have introduced a new PaaS based service – Azure Bastion. Which allows managed, seamless access to VMs in your private network via RDP and SSH over SSL.

Azure Bastion

Azure Bastion is provisioned directly into a virtual network, which allows bastion host and integrated connectivity to all virtual machines within that vnet using RDP/SSH directly from and through your browser via the Azure Portal.

Microsoft list the following as key features available right now as part of the preview:

  • RDP and SSH from the Azure portal: Initiate RDP and SSH sessions directly in the Azure portal with a single-click seamless experience.
  • Remote session over SSL and firewall traversal for RDP/SSH: HTML5 based web clients are automatically streamed to your local device providing the RDP/SSH session over SSL on port 443. This allows easy and securely traversal of corporate firewalls.
  • No public IP required on Azure Virtual Machines: Azure Bastion opens the RDP/SSH connection to your Azure virtual machine using a private IP, limiting exposure of your infrastructure to the public Internet.
  • Simplified secure rules management: Simple one-time configuration of Network Security Groups (NSGs) to allow RDP/SSH from only Azure Bastion.
  • Increased protection against port scanning: The limited exposure of virtual machines to the public Internet will help protect against threats, such as external port scanning.
  • Hardening in one place to protect against zero-day exploits: Azure Bastion is a managed service maintained by Microsoft. It’s continuously hardened by automatically patching and keeping up to date against known vulnerabilities.

And they list the following as on the roadmap for future release:

The future brings Azure Active Directory integration, adding seamless single-sign-on capabilities using Azure Active Directory identities and Azure Multi-Factor Authentication, and effectively extending two-factor authentication to your RDP/SSH connections. We are also looking to add support for native RDP/SSH clients so that you can use your favorite client applications to securely connect to your Azure Virtual Machines using Azure Bastion, while at the same time enhance the auditing experience for RDP sessions with full session video recording.

There are a couple of things to note as the service is in preview. As always, be wary deploying for production, there is no SLA yet.

The preview is limited to the following Azure public regions:

  • West US
  • East US
  • West Europe
  • South Central US
  • Australia East
  • Japan East

You have to register the resource provider manually to make use of the preview, instructions on how to do that here.

To use the Azure Bastion service, you need the following roles:

  • Reader role on the virtual machine
  • Reader role on the NIC with private IP of the virtual machine
  • Reader role on the Azure Bastion resource

Once you’re OK with all of the above, you can simply click connect on any of your VM resources and a new Bastion tab is available. From here you can launch your session to the VM right in the browser, which is pretty slick as it provides copy and paste and full screen functionality already.

RDP via Azure Bastion within the browser

One item I noticed from the FAQ is that you may need to use the preview link to access the resource deployment blade from the portal – https://aka.ms/BastionHost

Also of note, pricing! On the FAQ it states you will be billed partially. Not 100% sure what that means, so watch those usage rates. The pricing page is live however so check it out in advance here.

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!

Understanding Azure Reserved Virtual Machine Instances

One of the main benefits of Azure’s billing model is that it offers per minute billing. This means that if you have an application/service/environment that isn’t required 24/7 you can reduce your costs by using Automation so that you will only pay for what you consume.

However, if your environment requires you run a VM constantly, the cost can start to mount up. To help alleviate this, Microsoft offer a solution in the form of long-term fixed price Virtual Machine instances.

These Reserved Instances (RI) help save money by allowing you to pre-pay for a one-year or three-year VM size. The fact that you pay up front, allows you to make significant savings on the Pay-As-You-Go pricing.

RIexample

The most common subscription offers have the ability to purchase RIs, but there are some restrictions in terms of how it is approached. The options are the below:

  • Enterprise agreement subscriptions. To purchase reservations in an enterprise enrollment, the enterprise administrator must enable reservation purchases in the EA portal.
  • Pay-As-You-Go but you must have the “Owner” role on the subscription to buy a reservation.
  • Cloud Solution Provider subscriptions. However, the providing partner must make the purchase on behalf of the customer.

Once purchased, the discount is then applied to the resource usage that matches up with the RI capacity purchased. For example, if you purchase a one-year RI for a DS4v3 size VM, and you are using a DS4v3 the discount will apply against that usage.

A good strategy is to determine the sizing before purchasing the RI. So my advice would be to run your VMs without an RI for a few months to ensure your sizing is suitable and therefore correct. However, if this is something that is proving difficult, there is a range of flexibility offered within your RI scope.

With instance size flexibility, you don’t have to deploy the exact same VM size to get the benefit of your purchased Azure Reserved Instances (RI) as other VM sizes within the same VM group also get the RI discount. As a rough example, see the below table from the Microsoft announcement.

VM name VM group Ratios

Standard_D2s_v3

DSv3 Series

1

Standard_D4s_v3

DSv3 Series

2

Standard_D8s_v3

DSv3 Series

4

Standard_D16s_v3

DSv3 Series

8

Standard_D32s_v3

DSv3 Series

16

Standard_D64s_v3

DSv3 Series

32

This means that if you buy an RI for a D2sV3, it would cover half of an D4sV3 instance etc. More on how this can be applied and options available to you are here.

In general, I think an RI purchase is something that most deployments should be taking advantage of. Once sized correctly and with the ability to leverage flexibility, there are huge savings to be made with relatively low amounts of administrative effort.

More on how to buy an RI here

More on how the discount is applied here