Hello and welcome to Azure load balancers! In this brief lecture, you will learn what Azure load balancers are and what they are used for.

In the context of networking, the term “load balancing” refers to the process of distributing incoming network traffic across multiple backend resources. Such backend resources are typically virtual machines that are deployed in a “backend pool” but can also be instances in a virtual machine scale set.

The Azure Load Balancer operates at the Transport Layer, which is layer 4 of the OSI model. When you place a load balancer in front of an application running on VMs or on a scale set, the load balancer serves as the single point of access for that application. As users hit the load balancer to access the application, the load balancer balances that incoming traffic across however many backend VMs or resources you’ve deployed in the backend pool.

Azure load balancers come in two varieties. There are public load balancers and internal load balancers, which are also known as private load balancers.

A public load balancer is used when you need to load balance incoming Internet traffic to your virtual machines. This type of load balancer requires you to assign a public IP address to the frontend of the load balancer. It’s also important to note that public load balancers can provide outbound connections to the Internet for VMs that are located inside your Azure virtual network. To make this happen, what public load balancers do is translate the private IP addresses of the virtual machines to public IPs. This allows them to communicate externally even though the VMs themselves have no public IP addresses.

Internal load balancers can be used in situations where only private IP addresses are required on the frontend. This means that internal load balancers are limited to use cases where you only need to load balance traffic within your Azure virtual network, or from an on-prem network that has been connected to your virtual network through a VPN or ExpressRoute connection.

The image on your screen depicts a typical use case for both internal and public load balancers.

When you deploy a load balancer, you’ll have a choice of two SKUs: Basic and Standard. The standard load balancer can support any scenario that a basic load balancer can support – and then some.

For example, while the basic load balancer can support up to 300 instances, the standard load balancer can support up to 1000 instances. Another benefit of the standard load balancer over the basic load balancer is the support for availability zones. While the standard load balancer supports zone-redundant and zonal frontends for inbound and outbound traffic, basic load balancers do not offer any support at all for availability zones.

The table on your screen shows the key differences between Basic and Standard load balancers.

So, why would you ever use a load balancer? Well, there are many use cases for load balancers, both public and internal. The most common use case for a load balancer is when you wish to increase availability of your application by distributing it across multiple VMs and across multiple zones. You might also want to deploy a load balancer if you wish to provide outbound connectivity for your VMs without assigning them their own public IP addresses.

As far as security goes, while the basic load balancer is open to the Internet by default, the standard load balancer is built upon the zero-trust model. This means that the standard load balancer is inherently secure. As a matter of fact, the standard load balancer is part of your virtual network.  Unless you explicitly allow inbound traffic via a network security group, traffic is not allowed.

Because of the built-in security and better features Microsoft recommends using standard load balancers over basic load balancers whenever possible.