Microsoft recently announced the availability in Azure of Standard Load Balancer. They are load balancers Layer-4, for TCP and UDP protocols that, compared to Basic Load Balancer, introduce improvements and give you more granular control of certain features. This article describes the main features of the Standard Azure Load balancers, in order to have the necessary elements to choose the most suitable type of balancer for your needs.
Any scenario where you can use the SKU Basic of Azure Load balancers, can be satisfied using the Standard SKU, but the two types of load balancers have important differences in terms of scalability, functionality, guaranteed service levels and cost.
Scalability
The Standard Load balancers have higher scalability, compared to Basic Load Balancer, as regards the maximum number of instances (IP Configuration) that can be configured in the backend pool. The SKU Basic allows you to have up to 100 instances, while using the Standard SKU the maximum number of instances is equal to 1000.
Functionality
Backend pool
With regard to the Basic Load Balancer, in the backend pool, can reside exclusively:
- Virtual machines that are located within an availability set.
- A single standalone VM.
- Virtual Machine Scale Set.
Figure 1 – Possible associations in the Basic Load Balancer backend pool
In Standard Load Balancer instead, it is allowed to enter into backend pool any virtual machine attested on a particular virtual network. The integration scope, in this case, is not in fact the availability set, as for the Basic load balancer , but it is the virtual network and all its associated concepts. A requirement to consider, in order to insert into the backend pool of Standard Load Balancer the virtual machines, is that these should not have associated public IP or must have Public IP with Standard SKU.
Figure 2 Standard Load Balancer backend pool association
Availability Zones
Standard Load Balancers provide integration scenarios with Availability Zones, in the regions that include this feature. For more details you can refer this specific Microsoft document, that shows the main concepts and implementation guide lines.
Ports High Availability
The load balancers with Standard SKU, of type "Internal", allow you to balance the TCP and UDP flows on all ports simultaneously. To do that, in the rule of load-balancing, there is the possibility to enable the "HA Ports" option:
Figure 3 - Configuring the load balancing rule with "HA Ports" option enabled
The balancing is done for flow, which is determined by the following elements: source IP address, source port, destination IP address, destination port, and protocol. This is particularly useful in scenarios where are used Network Virtual Appliances (NVA's) requiring scalability. This new feature improves the tasks that are required for NVAs implementations.
Figure 4 - Network architecture which provides the use of LB with "HA Ports" option enabled
Another possible use for this feature is when you need to balance a large number of ports.
For more details on the option "HA Ports" you can see the official documentation.
Diagnostics
Standard Load Balancer introduce the following features in terms of diagnostic capability:
- Multi-dimensional metrics: You can retrieve various metrics that allow you to see, in real time, usage status of load balancer, internal and public. This information is particularly useful for troubleshooting.
Figure 5 – Load Balancer metrics from the Azure Portal
- Resource Health: in Azure Monitor you have the opportunity to consult the health status of Standard Load Balancer (currently only available for Standard Load Balancer, type Public).
Figure 6 – Resource health of Load Balancer in Azure Monitor
You can also consult the history of the health state :
Figure 7 – Health history of Load Balancer
All details related to diagnostics, of the Standard Load Balancer, can be found in the official documentation.
Security
The Load Balancer with standard SKU are configured to be secure by default in fact, in order to operate, you must have a Network Security Group (NSG) where the traffic flow is explicitly allowed. As previously reported, the Load Balancer standards are fully integrated into the virtual network, which is characterized by the fact that it is private and therefore closed. The Standard Load Balancer and the public Standard IP are used to allow the access to the virtual network from outside and now by default you must configure a Network Security Group (closed by default) to allow the desired traffic. If there is no a NSG, on the subnet or on the NIC of the virtual machine, you will not be allowed the access by the network stream from the Standard Load Balancer.
The Basic Load Balancers by default are opened and the configuration of a Network Security Group is optional.
Outbound connections
The Load Balancer on Azure support both inbound and outbound connectivity scenarios. The Standard Load Balancer, compared to the Load Balancer Basic, behave differently with regard to outbound connections.
To map the internal and private IP address of the virtual network to the public IP address of the Load Balancer it uses the Source Network Address Translation technique (SNAT). The Load Balancer Standard introduce a new algorithm to have stronger SNAT policies, scalable and accurate, that allow you to have more flexibility and have new features.
Using the Standard Load Balancer you should consider the following aspects with regard to outbound scenarios:
- Must be explicitly created to allow outgoing connectivity to virtual machines and are defined on the basis of incoming balancing rules.
- Balancing rules define how occur the SNAT policies.
- If there are multiple frontend, It uses all the frontend and for each of these multiply the preallocated SNAT ports available.
- You have the option to choose and control whether a specific frontend you don't want to use for outbound connections.
Basic Load Balancers, in the presence of more public frontend IP, it is selected a single frontend to be used in outgoing flows. This selection can not be configured and occurs randomly.
To designate a specific IP address, you can follow the steps in this section of the Microsoft documentation.
Management operations
Standard Load balancers allow enabling management operations more quickly, much to bring the execution times of these operations under 30 seconds (against the 60-90 seconds to the Load Balancer with Basic SKU). Editing time for the backend pools are also dependent on the size of the same.
Other differences
At the moment, Public Standard Load Balancer cannot be configured with a public IPv6 address:
Figure 8 – Public IPv6 for Public Load Balancer
Service-Level Agreements (SLA)
An important aspect to consider, in choosing the most appropriate SKU for different architectures, is the level of service that you have to ensure (SLA). Using the Standard Load Balancer ensures that a Load Balancer Endpoint, that serve two or more instances of health virtual machines, will be available in time with an SLA of 99.99%.
The Load Balancer Basic does not guarantee this SLA.
For more details you can refer to the specific article SLA for Load Balancer.
Cost
As for Basic Load Balancer are not expected cost, for Standard Load Balancer there are usage charge provided on the basis of the following elements:
- Number of load balancing rules configured.
- Number of inbound and outbound data processed.
There are no specific costs for NAT rules.
In the Load Balancer cost page can be found the details.
Migration between SKUs
For Load Balancer is not expected to move from the Basic SKU to the Standard SKU and vice versa. But it is necessary to provide a side-by-side migration, taking into consideration the previously described functional differences.
Conclusions
The introduction of the Azure Standard Load Balancer allows you to have new features and provide greater scalability. These characteristics may help you avoid having to use, in specific scenarios, balancing solutions offered by third party vendors. Compared to traditional Load balancers (Basic SKU) change operating principles and have distinct characteristics in terms of costs and SLAS, this is good to consider in order to choose the most suitable type of Load Balancer, on the basis of the architecture that you must accomplish.
