Azure Load Balancer Standard overview
Azure Load Balancer allows you to scale your applications and create high availability for your services. Load Balancer can be used for inbound as well as outbound scenarios and provides low latency, high throughput, and scales up to millions of flows for all TCP and UDP applications.
This article is focused on Standard Load Balancer. For a more general overview for Azure Load Balancer, review Load Balancer Overview as well.
What is Standard Load Balancer?
Standard Load Balancer is a new Load Balancer product for all TCP and UDP applications with an expanded and more granular feature set over Basic Load Balancer. While there are many similarities, it is important to familiarize yourself with the differences as outlined in this article.
You can use Standard Load Balancer as a public or internal Load Balancer. And a virtual machine can be connected to one public and one internal Load Balancer resource.
The Load Balancer resource's functions are always expressed as a frontend, a rule, a health probe, and a backend pool definition. A resource can contain multiple rules. You can place virtual machines into the backend pool by specifying the backend pool from the virtual machine's NIC resource. In the case of a virtual machine scale set, this parameter is passed through the network profile and expanded.
One key aspect is the scope of the virtual network for the resource. While Basic Load Balancer exists within the scope of an availability set, a Standard Load Balancer is fully integrated with the scope of a virtual network and all virtual network concepts apply.
Load Balancer resources are objects within which you can express how Azure should program its multi-tenant infrastructure to achieve the scenario you wish to create. There is no direct relationship between Load Balancer resources and actual infrastructure; creating a Load Balancer doesn't create an instance, capacity is always available, and there are no start-up or scaling delays to consider.
Azure provides a suite of fully managed load balancing solutions for your scenarios. If you are looking for TLS termination ("SSL offload") or per HTTP/HTTPS request application layer processing, review Application Gateway. If you are looking for global DNS load balancing, review Traffic Manager. Your end-to-end scenarios may benefit from combining these solutions as needed.
Why use Standard Load Balancer?
Standard Load Balancer enables you to scale your applications and create high availability for small scale deployments to large and complex multi-zone architectures.
Review the table below for an overview of the differences between Standard Load Balancer and Basic Load Balancer:
New designs should consider using Standard Load Balancer.
|Standard SKU||Basic SKU|
|Backend pool size||up to 1000 instances||up to 100 instances|
|Backend pool endpoints||any virtual machine in a single virtual network, including blend of virtual machines, availability sets, virtual machine scale sets.||virtual machines in a single availability set or virtual machine scale set|
|Availability Zones||zone-redundant and zonal frontends for inbound and outbound, outbound flows mappings survive zone failure, cross-zone load balancing||/|
|Diagnostics||Azure Monitor, multi-dimensional metrics including byte and packet counters, health probe status, connection attempts (TCP SYN), outbound connection health (SNAT successful and failed flows), active data plane measurements||Azure Log Analytics for public Load Balancer only, SNAT exhaustion alert, backend pool health count|
|HA Ports||internal Load Balancer||/|
|Secure by default||default closed for public IP and Load Balancer endpoints and a network security group must be used to explicitly whitelist for traffic to flow||default open, network security group optional|
|Outbound connections||Multiple frontends with per rule opt-out. An outbound scenario must be explicitly created for the virtual machine to be able to use outbound connectivity. VNet Service Endpoints can be reached without outbound connectivity and do not count towards data processed. Any public IP addresses, including Azure PaaS services not available as VNet Service Endpoints, must be reached via outbound connectivity and count towards data processed. When only an internal Load Balancer is serving a virtual machine, outbound connections via default SNAT are not available. Outbound SNAT programming is transport protocol specific based on protocol of the inbound load balancing rule.||Single frontend, selected at random when multiple frontends are present. When only internal Load Balancer is serving a virtual machine, default SNAT is used.|
|Multiple frontends||Inbound and outbound||Inbound only|
|Management Operations||Most operations < 30 seconds||60-90+ seconds typical|
|SLA||99.99% for data path with two healthy virtual machines||Implicit in VM SLA|
|Pricing||Charged based on number of rules, data processed inbound or outbound associated with resource||No charge|
Standard Load Balancer backend pools expands to any virtual machine resource in a virtual network. It can contain up to 1000 backend instances. A backend instance is an IP configuration, which is a property of a NIC resource.
The backend pool can contain standalone virtual machines, availability sets, or virtual machine scale sets. You can blend resources in the backend pool and it can contain any combination of these resources up to 150 total.
When considering how to design your backend pool, you can design for the least number of individual backend pool resources to further optimize the duration of management operations. There is no difference in data plane performance or scale.
Standard Load Balancer supports additional abilities in regions where Availability Zones are available. These features are incremental to all Standard Load Balancer provides. Availability Zones configurations are available for public and internal Standard Load Balancer.
Non-zonal frontends become zone-redundant by default when deployed in a region with Availability Zones. A zone-redundant frontend survives zone failure and is served by dedicated infrastructure in all of the zones simultaneously.
Additionally, you can guarantee a frontend to a specific zone. A zonal frontend shares fate with the respective zone and is served only by dedicated infrastructure in a single zone.
Cross-zone load balancing is available for the backend pool, and any virtual machine resource in a vnet can be part of a backend pool.
Standard Load Balancer provides multi-dimensional metrics through Azure Monitor. These metrics can be filtered, grouped and provide current and historic insights into performance and health of your service. Resource Health is also supported. Following is a brief overview of supported diagnostics:
|VIP availability||Load Balancer Standard continuously exercises the data path from within a region to the Load Balancer front-end all the way to the SDN stack that supports your VM. As long as healthy instances remain, the measurement follows the same path as your application's load-balanced traffic. The data path that is used by your customers is also validated. The measurement is invisible to your application and does not interfere with other operations.|
|DIP availability||Load Balancer Standard uses a distributed health probing service that monitors your application endpoint's health according to your configuration settings. This metric provides an aggregate or per endpoint filtered-view of each individual instance endpoint in the Load Balancer pool. You can see how Load Balancer views the health of your application as indicated by your health probe configuration.|
|SYN packets||Load Balancer Standard does not terminate TCP connections or interact with TCP or UDP packet flows. Flows and their handshakes are always between the source and the VM instance. To better troubleshoot your TCP protocol scenarios, you can make use of SYN packets counters to understand how many TCP connection attempts are made. The metric reports the number of TCP SYN packets that were received.|
|SNAT connections||Load Balancer Standard reports the number of outbound flows that are masqueraded to the Public IP address front-end. SNAT ports are an exhaustible resource. This metric can give an indication of how heavily your application is relying on SNAT for outbound originated flows. Counters for successful and failed outbound SNAT flows are reported and can be used to troubleshoot and understand the health of your outbound flows.|
|Byte counters||Load Balancer Standard reports the data processed per front-end.|
|Packet counters||Load Balancer Standard reports the packets processed per front-end.|
Standard Load Balancer supports a new type of rule.
You can configure load balancing rules to make your application scale and be highly reliable. When you use an HA Ports load balancing rule, Standard Load Balancer will provide per flow load balancing on every ephemeral port of an internal Standard Load Balancer's frontend IP address. The feature is useful for other scenarios where it is impractical or undesirable to specify individual ports.
An HA Ports load balancing rule allows you to create active-passive or active-active n+1 scenarios for Network Virtual Appliances and any application which requires large ranges of inbound ports. A health probe can be used to determine which backends should be receiving new flows. You can use a Network Security Group to emulate a port range scenario.
If you are planning to use a Network Virtual Appliance, check with your vendor for guidance on whether their product has been tested with HA Ports and follow their specific guidance for implementation.
Review detailed discussion of HA Ports.
Secure by default
Standard Load Balancer is fully onboarded to the virtual network. The virtual network is a private, closed network. Because Standard Load Balancers and Standard public IP addresses are designed to allow this virtual network to be accessed from outside of the virtual network, these resources now default to closed unless you open them. This means Network Security Groups (NSGs) are now used to explicitly permit and whitelist allowed traffic. You can create your entire virtual data center and decide through NSG what and when it should be available. If you do not have an NSG on a subnet or NIC of your virtual machine resource, we will not permit traffic to reach this resource.
To learn more about NSGs and how to apply them for your scenario, see Network Security Groups.
Load Balancer supports inbound and outbound scenarios. Standard Load Balancer is significantly different for Basic Load Balancer with respect to outbound connections.
Source Network Address Translation (SNAT) is used to map internal, private IP addresses on your virtual network to public IP addresses on Load Balancer frontends.
Standard Load Balancer introduces a new algorithm for a more robust, scalable, and predictable SNAT algorithm and enables new abilities, removes ambiguity, and forces explicit configurations rather side effects. These changes are necessary to allow for new features to emerge.
These are the key tenets to remember when working with Standard Load Balancer:
- the completion of a rule drives the Load Balancer resource. all programming of Azure derives from its configuration.
- when multiple frontends are available, all frontends are used and each frontend multiplies the number of available SNAT ports
- you can choose and control if you do not wish for a particular frontend to be used for outbound connections.
- outbound scenarios are explicit and outbound connectivity does not exist until it has been specified.
- load balancing rules infer how SNAT is programmed. Load balancing rules are protocol specific. SNAT is protocol specific and configuration should reflect this rather than create a side effect.
If you want more SNAT ports because you are expecting or are already experiencing a high demand for outbound connections, you can also add incremental SNAT port inventory by configuring additional frontends, rules, and backend pools to the same virtual machine resources.
Control which frontend is used for outbound
If you want to constrain outbound connections to only originate from a specific frontend IP address, you can optionally disable outbound SNAT on the rule which expresses the outbound mapping.
Control outbound connectivity
Standard Load Balancer exists within the context of the virtual network. A virtual network is an isolated, private network. Unless an association with a public IP address exists, public connectivity is not allowed. You can reach VNet Service Endpoints because they are inside of and local to your virtual network. If you want to establish outbound connectivity to a destination outside of your virtual network, you have two options:
- assign a Standard SKU public IP address as an Instance-Level Public IP address to the virtual machine resource or
- place the virtual machine resource in the backend pool of a public Standard Load Balancer.
Both will allow outbound connectivity from the virtual network to outside of the virtual network.
If you only have an internal Standard Load Balancer associated with the backend pool in which your virtual machine resource is located, your virtual machine can only reach virtual network resources and VNet Service Endpoints. You can follow the steps described in the preceding paragraph to create outbound connectivity.
Outbound connectivity of a virtual machine resource not associated with Standard SKUs remains as before.
Load Balancer supports multiple rules with multiple frontends. Standard Load Balancer expands this to outbound scenarios. Outbound scenarios are essentially the inverse of an inbound load balancing rule. The inbound load balancing rule also creates an associate for outbound connections. Standard Load Balancer uses all frontends associated with a virtual machine resource through a load balancing rule. Additionally, a parameter on the load balancing rule and allows you to suppress a load balancing rule for the purposes of outbound connectivity, which allows the selection of specific frontends including none.
For comparison, Basic Load Balancer selects a single frontend at random and there is no ability to control which one was selected.
Standard Load Balancer resources exist on an entirely new infrastructure platform. This enables significantly faster management operations for Standard SKUs and completion times are typically less than 30 seconds per Standard SKU resource. Note that as backend pools increase in size, the duration required for backend pool changes also increase.
You can modify Standard Load Balancer resources and move a Standard public IP address from one virtual machine to another much faster.
Migration between SKUs
SKUs are not mutable. Follow the steps in this section to move from one resource SKU to another.
Review this document in its entirety to understand the differences between SKUs and have carefully examined your scenario. You may need to make additional changes to align your scenario.
Migrate from Basic to Standard SKU
Create a new Standard resource (Load Balancer and Public IPs, as needed). Recreate your rules and probe definitions.
Create new or update existing NSG on NIC or subnet to whitelist load balanced traffic, probe, as well as any other traffic you wish to permit.
Remove the Basic SKU resources (Load Balancer and Public IPs, as applicable) from all VM instances. Be sure to also remove all VM instances of an availability set.
Attach all VM instances to the new Standard SKU resources.
Migrate from Standard to Basic SKU
Create a new Basic resource (Load Balancer and Public IPs, as needed). Recreate your rules and probe definitions.
Remove the Standard SKU resources (Load Balancer and Public IPs, as applicable) from all VM instances. Be sure to also remove all VM instances of an availability set.
Attach all VM instances to the new Basic SKU resources.
There are limitations regarding use of the Basic and Standard SKUs.
HA Ports and Diagnostics of the Standard SKU are only available in the Standard SKU. You can't migrate from the Standard SKU to the Basic SKU and also retain these features.
Both Basic and Standard SKU have a number of differences as outlined in this article. Make sure you understand and prepare for them.
Matching SKUs must be used for Load Balancer and Public IP resources. You can't have a mixture of Basic SKU resources and Standard SKU resources. You can't attach standalone virtual machines, virtual machines in an availability set resource, or a virtual machine scale set resources to both SKUs simultaneously.
Load Balancer Standard is currently available in all public cloud regions.
Standard Load Balancers are available with a 99.99% SLA. Review the Standard Load Balancer SLA for details.
Standard Load Balancer is a charged product based on number of load balancing rules configured and all inbound and outbound data processed. For Standard Load Balancer pricing information, visit the Load Balancer Pricing page.
- Load Balancer backend instances cannot be located in peered virtual networks at this time. All back-end instances must be in the same region.
- SKUs are not mutable. You may not change the SKU of an existing resource.
- A standalone virtual machine resource, availability set resource, or virtual machine scale set resource can reference one SKU, never both.
- Azure Monitor Alerts are not supported at this time.
- Move subscription operations are not supported for Standard SKU LB and PIP resources.
- Learn about using Standard Load Balancer and Availability Zones
- Learn more about Availability Zones.
- Learn about Standard Load Balancer Diagnostics.
- Learn about supported multi-dimensional metrics for diagnostics in Azure Monitor.
- Learn about using Load Balancer for outbound connections
- Learn about Standard Load Balancer with HA Ports load balancing rules
- Learn about using Load Balancer with Multiple Frontends
- Learn about Virtual Networks.
- Learn more about Network Security Groups.
- Learn about VNet Service Endpoints
- Learn about some of the other key networking capabilities in Azure.
- Learn more about Load Balancer.