A bit of history

When you talk about Cloud Computing, you cannot avoid talking about networking, it is the glue that maintain everything together, and permit users to access their resources, and services to talk each other. At the core of Azure networking, since the very beginning, it is the Azure Load Balancer. If you probably remember the early days of Web and Worker roles in Azure PaaS v1, and the first version of IaaS Virtual Machines, probably you don’t Azure Load Balancer (LB) itself: in front of these resources, you had this piece of networking technology that allowed traffic to be balanced over a set of multiple compute instances.

At that time, LB was invisible and not configurable, with few exceptions. There was also a distinction between Azure Software Load Balancer (SLB) and Azure Internal Load Balancer (ILB), reflecting the first wave of improvement to this part of the platform. Even if ILB term continue to exist in the documentation, we generally talk about “Azure Load Balancer” (LB), it doesn’t matter if the front-end IP address is internal (ILB) or external (SLB). Within the scope of this article, I will refer to Azure Layer-4 Load Balancer as “LB”, Layer-7 Azure Application Gateway is not considered. Additionally, there is no more Azure Service Management (ASM) improvements for LB, all new features, and what discussed here, will be referred to Azure Resource Manager (ARM) API model.

Introduction of a new Load Balancer SKU

Azure is now approaching this 10^th birthday, and a new massive wave of improvements is coming under the name of “Azure Standard Load Balancer” (Standard LB) :

Load Balancer Standard

https://azure.microsoft.com/en-us/updates/public-preview-load-balancer-standard

Azure Standard LB will incorporate massive improvements in performance, scale, resiliency and covering new scenarios that previously was not possible to implement. Before proceeding, let me clarify the new naming and the introduction of SKU separation: new improved Azure LB type will be the “Standard” SKU, while the previous LB version will go under “Basic” SKU, that is the current one not in preview. NOTE: There is no retirement announced for “Basic” SKU. Just to emphasize more that these SKUs are different, and that Standard has been built from the ground up in a new stack, it is not possible to dynamically upgrade from one to the other, at least today. Even if SKUs are not mutable, a procedure is provided to change, but will cause some downtime, you can check here. Before talking more in depth about technical features, let me highlight two important differences between these two SKUs:

• Pricing

Standard and Basic SKUs have very different pricing. The Basic LB is free of charge, while the standard Azure Load Balancer has a charge associated with it. That pricing will be based on the number of rules configured (load balancer rules and NAT rules) and data processed for inbound originated flows. However, there will be no hourly charge for the standard load balancer itself when no rules are configured. Additionally, ILB scenario is not charged at all. You can check pricing details here.

• Subscription Limits

Standard SKU comes with greater capacity and scalability, then some of the max thresholds per region per Azure subscription are different. In this article, please note the different values for the number of rules, front-end configurations, and backend pool size:

Introduction of a new IP Public Address SKU

Azure “Standard” SKU for Load Balancer is not coming alone, we are also going to have a “Standard” SKU for Public IP addresses (now still in preview). These are strictly related, new IP SKU is necessary and tightly bound to the Load Balancer used: concept here is reflected in the rule that dictate the usage of “Standard” IP with “Standard” LB, not possible to mix. All public IP addresses created before the introduction of SKUs are Basic SKU public IP addresses. With the introduction of SKUs, you have the option to specify which SKU you would like the public IP address to be. You may wonder why this has been created, I have my idea on that, not officially confirmed, but if you look at the feature list, it seems to be related to the (upcoming) introduction of Azure Availability Zones (AZ):

IP address types and allocation methods in Azure

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-ip-addresses-overview-arm

I will talk more in depth about “Availability Zones” (AZ) later in this article. In the meantime, let me ask your attention on four important points:

• SKU choice: Azure LB Standard SKU does require Azure IP Standard SKU.
• Standard public IP SKU is static only: this will have an impact on cost and maximum number of IPs you will be able to deploy, as you can read at this and this links.
• Availability Zones: if you want to use LB in AZ scenario, you must use Standard SKU.

Creating it in PowerShell requires only an additional parameter “Sku” to be specified with value “Standard”:

New-AzureRmPublicIpAddress -Name $pubIpName -ResourceGroupName $rgname -AllocationMethod Static -Location $location -Sku Standard -IpAddressVersion IPv4

NOTE: Azure Public IP address Standard SKU cannot be used with VPN Gateway nor Application Gateway.

New LB Standard SKU features

During the past years, for several of my Azure projects, I faced several kinds of issues and limitations for the now named Azure “Basic” Load Balancer SKU. Looking at the list of improvements for “Standard” SKU in the article below, I’m impressed and glad that now almost everything has been finally solved. Let me report the list below along with my comments and experiences from those projects.

Azure Load Balancer Standard overview

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-standard-overview

Backend Pool

The Backend pool is essentially the pool of “compute” instances that the LB will forward the traffic to. During one of my project in the past, I faced two distinct issues, here are the descriptions and how Standard SKU is aiming to solve now:

• Scalability: max limit of 100 VM instances. Now with Standard SKU the limit has been raised 10x up to 1000.
• Flexibility: only configurations with VMs (or VM Scale Sets – VMSS) into a single Availability Set (AS) were possible. Now with Standard SKU you can include every VM instance inside the same VNET, standalone or in multiple AS.

Frontend Configuration

Multiple Frontend IP configuration: in reality, this is possible also with Basic SKU (see here), but with Standard SKU it has been enhanced. You can now use these multiple IPs to scale on the number of ephemeral ports for SNAT. If you had problems in the past with SNAT port exhaustion, you should use LB Standard SKU with additional front-end Standard SKU IPs. Read carefully here on scenarios and how to solve potential issues.

Availability Zones

AZ is a very important feature that will become available soon, currently in preview in selected regions. Without this feature, is not possible to have fault-isolated locations within an Azure region, providing redundant power, cooling, and networking. Availability Zones allow customers to run mission-critical applications with higher availability and fault tolerance to datacenter failures, using synchronous data replication, to achieve zero data loss in case of single zone failure. With AZ, Azure will be able to provide 99,99% HA SLA for its Virtual Machines. If you want to use a Load Balancer and a Public IP that is zone-resilient, you must use Standard SKU for both these objects.

It is worth noting the following notes about “zonal” and “zone-redundant” concepts:

1. Azure “Load Balancer”, “Virtual Network” and “Subnet” are region wide objects, that is regional, and never zonal.
2. Both public and internal Load Balancer support zone-redundant and zonal scenarios.
3. “Public IP” address can be created local to a zone (zoned) or regional, that is zone-resilient: in the former case, you need to specify a zone when creating the object, in the latter instead, you should not.

For additional details you can read the article below:

Standard Load Balancer and Availability Zones

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-standard-availability-zones

If you want to know more on Azure Availability Zones, you can read my blog post below:

Why Azure Availability Zones

https://blogs.msdn.microsoft.com/igorpag/2017/10/08/why-azure-availability-zones

HA Ports

This feature is available only with Standard LB SKU and in internal load balancing scenarios (ILB), cannot be used with internet facing public IP. Mechanic is very simple: you can write a simple single rule that will balance *all* TCP or UDP ports and protocols. Without this feature, you need to explicitly write a load balancing rule for each port, with a maximum threshold of 250 using Basic SKU internal load balancing.

High Availability Ports overview

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ha-ports-overview

Which kind of scenarios can have benefits from this? First usage is for Network Virtual Appliances (NVAs). With (HA) Ports is easy to configure a single load balancing rule to process and distribute VNet traffic coming across any Layer 4 port to your NVAs increasing reliability with faster failover and more scale-out options.

You can create such rule easily using the Azure Portal or PowerShell (ARM template and Azure CLI 2.0 are also available following these instructions):

New-AzureRmLoadBalancerRuleConfig -Name "HAPortsLBrule” -FrontendIpConfiguration $FEconfig -BackendAddressPool $BEPool -Protocol "All" -FrontendPort 0 -BackendPort 0

In the cmdlet above, please pay attention to the usage of “FrontEndPort”, “BackendPort” and “Protocol” switches.

Monitoring and Diagnostics

Using Basic SKU for Azure Load Balancer (LB), once enabled as described here, three different type of loggings are available: Audit, Health Probe and Alerts. The last one is particularly useful to troubleshoot potential issues on the LB, such as SNAT port exhaustion. All these logs can be collected and stored on an Azure storage account, and then analyzed using tools like PowerBI. What is new in Standard SKU is the possibility to retrieve important metrics and counters that will give you a much better insight on how your LB is working. You can get the list of metrics available for an Azure Standard LB resource using the Azure Portal (via Azure Monitor integration) or PowerShell cmdlet “Get-AzureRmMetricDefinition” from “AzureRM.Insights” module:

The first two “counters” will tell you about effective availability of frontend IP (VIP) and backend internal IP (DIP), the other counters are self-explanatory. For the description of each item, please see this article. This functionality is an addition to diagnostics already available in the Basic SKU that you can still leverage:

High-availability SLA

I personally love SLAs, as something that permits you to build your architecture on solid bases, and “resell” to your final customers an application that they can rely upon.  Standard LB SKU comes with a new brand high-availability SLA of 99,99%, Basic SKU is not covered here. Very useful and nice improvement.

SLA for Load Balancer

https://azure.microsoft.com/en-us/support/legal/sla/load-balancer/v1_0

The new metric monitoring feature, will allow you to easily assess availability, and other counters, from the Azure Portal with nice customizable diagrams.

Breaking changes in Azure LB Standard SKU

I decided to dedicate a section to this topic because there are two breaking changes in the behavior of the Azure Load Balancer Standard SKU, compared to the previous Basic SKU. If you are already using the latter, and planning to move to the former, please read carefully my notes below and associated documentation links:

• Network Security Group (NSG): When you assign a standard SKU public IP address to a virtual machine’s network interface, you must explicitly allow the intended traffic with a network security group. Communication with the resource fails until you create and associate a network security group and explicitly allow the desired traffic. This is for obvious security reasons.
• VM outbound connectivity: if a VM is part of a Standard LB backend pool, outbound connectivity is not permitted without additional configuration. This is totally different from Basic LB, where a VM has totally open outbound connectivity to the Internet. To permit the VM outbound connectivity, a load-balancing rule (NAT rule is not sufficient) must be programmed on the LB Standard SKU, as explained in the article below (see “Scenario 2: Load-balanced VM without an Instance Level Public IP address”):

Outbound connections in Azure

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections

NOTE: There is an exception to the rule I just gave you, I will explain you in a minute.

The article above is a very interesting piece of Azure networking architecture, I strongly recommend you read entirely if you want ot have a complete understanding of Azure LB behavior. What is worth reading is the list of scenarios for outbound VM connectivity:

Regarding the exception I mentioned in the previous note, as you can read for the first scenario, if you add an additional IP configuration to your VM, with an Instance Level Public IP, your VM will be able to reach outbound Internet.

What is still missing?

As I said at the beginning of this article, Azure Load Balancer (LB) Standard SKU solved most of the problems I faced in the past, an amazing work from Azure Networking team. As a Cloud Architect for my customers and partners, there are still a couple of “nice to have” details I would like to know:

1. Load Balancer latency: officially, there is no mention on how much overhead the traffic will get flowing through the load balancer. I have done my tests in the past and have my idea, and you can do easily your own, but there is no SLA on that.
2. Load Balancer throughput: how many Gbit/s or Pps (Packets per second) an Azure load balancer can sustain? There is no capacity guidance around this, I suspect because Azure load balancers run on a multi-tenant infrastructure, then numbers may change.

Regarding the second point, in the past was rare to hit throughput cap, other limits kicked in before. But now you can scale the backend pool to 1000 VMs, then will be interesting to do some performance tests at scale. Anyway, let me close my article with the sentence contained in the overview article for Azure Standard Load Balancer:

....Low latency, high throughput, and scale are available for millions of flows for all TCP and UDP applications.....

Examples on GitHub

Since the Standard SKU Load Balancer is new, and some behaviors are different from the past, I created some very simple samples using PowerShell you can play with and customize. You can find at this link on GitHub. Please be aware that these are NOT production ready, I created them only for learning purpose. Additionally, the code in the samples is not intended to be launched all in once. Instead, you should carefully review each commented section, understand the effects, then run it to observe the outcome.

1. SAMPLE[1]: Create a simple zoned VM with an instance level Standard IP (ILPIP). Look how to create a VM in a specific Azure Availability Zone (AZ), then create a new Standard SKU type Public IP and use it to expose the VM. A Network Security Group (NSG) is necessary to permit traffic through the Standard Public IP, differently from Basic Public IP as done in the past, where all the ports were open for VM access.
2. SAMPLE[2]: Create a new type Standard SKU Load Balancer (LB), and use it in conjunction with a new Standard SKU type Public IP. Then, create two "zoned" VMs with Managed Disks, each one hosted in a different Azure Availability Zone (AZ). Worth noting that the two VMs will be in the same subnet and Virtual Network, even if in different AZs. Finally, will be demonstrated how Standard Load Balancer will transparently redirect to the VM in Zone[2] if VM in Zone[1] will be down. In this sample, the necessary NSG will be created and bound to the subnet level, not at the specific VM NIC as in the previous example.
3. SAMPLE[3]: Create a Standard SKU internal Load Balancer (ILB) with HA Port configured and 1 zoned VM behind it. You will see how the publishing rule for this feature is different, and how it works with VM created in a specific Zone.
4. SAMPLE[4]: You will see here how to retrieve metric definitions and values for Standard SKU Load Balancer (LB), using PowerShell.

Conclusions

Azure new Standard SKU for Load Balancer has been officially released yesterday. It is a key component for many new Azure scenarios, most important for Azure Availability Zones (AZ). Additionally, it provides greater scalability and new diagnostic and monitoring capabilities that were missed in the Basic SKU release.  Hope you enjoyed my article, feel free to send me your notes and feedbacks. You can follow me on Twitter using @igorpag. Regards.