Load Balancer frequently asked questions

Internal load balancers, which load balance traffic within a virtual network.

External load balancers, which load balance external traffic to an internet connected endpoint. For more information, see Azure Load Balancer Types.

For both of the types, Azure offers a Basic SKU and Standard SKU that have different functional, performance, security and health tracking capabilities. For more information about the different load balancer SKUs, see SKU Comparison.

For more information about an automated script and guidance on upgrading a load balancer SKU, see upgrade from Basic to Standard.

For the available load-balancing services and recommended uses for each, see the load balancer technology guide.

See the list of Azure Load Balancer quickstart templates for ARM templates of common deployments.

Inbound NAT rules are used to specify a backend resource to route traffic to. For example, configuring a specific load balancer port to send RDP traffic to a specific VM. Load-balancing rules are used to specify a pool of backend resources to route traffic to, balancing the load across each instance. For example, a load balancer rule can route TCP packets on port 80 of the load balancer across a pool of web servers.

The virtual IP address for the host tagged as the Azure infrastructure load balancer where the Azure health probes originate. Traffic must be allowed from this IP address to successfully respond to health probes when backend instances are configured. This rule doesn't interact with access to your load balancer frontend. If you're not using the Azure Load Balancer, you can override this rule. You can learn more about service tags here.

No. Basic load balancer doesn't support global virtual network peering. You can use a standard load balancer instead. See the upgrade from Basic to Standard article for information about the upgrade.

There are many ways to determine the public source IP address of an outbound connection. OpenDNS provides a service that can show you the public IP address of your VM. By using the nslookup command, you can send a DNS query for the name myip.opendns.com to the OpenDNS resolver. The service returns the source IP address that was used to send the query. When you run the following query from your VM, the response is the public IP used for that VM:

nslookup myip.opendns.com resolver1.opendns.com

Adding a VM from the same availability set to different backend pools isn't possible if the load balancer is NIC based. However, with IP-based load balancer, this constraint is lifted.

Azure Load Balancer is a pass-through network load balancer. Throughput limitations are determined by the type of virtual machine in the backend pool. To learn about other network throughput related information, see Virtual Machine network throughput.

Azure's internal network infrastructure keeps traffic between Azure services in the same region stays within the Azure network, by default. This means when Load Balancer and Azure Storage account are in the same region, the traffic between them doesn't traverse the internet by remaining on the internal Azure network backbone. However, the exact behavior can depend on the specific configuration of your Azure services, including network security group rules, routing, and any other network controls you have in place.

For connectivity to storage in other regions, outbound connectivity is required. The source IP address in the storage diagnostic logs is an internal provider address, and not the public IP address of your VM when connecting to storage from a VM in the same region. To restrict access to your storage account to VMs in one or more virtual network subnets in the same region, use Virtual Network service endpoints. Don't use your public IP address when configuring your storage account firewall. When service endpoints are configured, you see your virtual network private IP address in your storage diagnostic logs and not the internal provider address.

No, Azure Load Balancer doesn't currently support termination as it's a pass through network load balancer. Application Gateway could be a potential solution if your application requires termination.

Follow these instructions to configure your load balancer with an Azure Firewall.

Yes, this scenario is supported. You need to create a public IP prefix and public IP address from your custom IP address prefix before using it with your load balancer. To learn more, visit Manage a custom IP address prefix.

Follow these Portal or PowerShell instructions to configure your load balancer with an Azure SQL Server Always On availability group.

No, Azure Load Balancer doesn't support this scenario. To learn more, visit our troubleshoot page.

Standard load balancer and standard public IP introduce abilities and different behaviors to outbound connectivity. They aren't the same as basic SKUs. If you want outbound connectivity with standard SKUs, you must explicitly define it either with standard public IP addresses or a standard public load balancer. Standard internal load balancer must have outbound connectivity defined. It's recommended you always use outbound rules on a standard public load balancer. When an internal standard load balancer is used, you must take steps to create outbound connectivity for the VMs in the backend pool if outbound connectivity is desired. In the context of outbound connectivity, a single standalone VM, all the VMs in an Availability Set, all the instances in a Virtual Machine Scale Set behave as a group. If a single VM in an Availability Set is associated with a standard SKU, all VM instances within this Availability Set now behave by the same rules as if they're associated with standard SKU even if an individual instance isn't directly associated with it. This behavior is also observed in a standalone VM with multiple network interface cards attached to a load balancer. If one NIC is added as a standalone, it has the same behavior. Review this entire document to understand the overall concepts, review Standard Load Balancer for differences between SKUs, and review outbound rules. Using outbound rules allows you fine grained control over all aspects of outbound connectivity.

Azure Load Balancer will use IPs as needed based on available ports. It will only use the next frontend IP once the connections cannot be made from the one IP.

To view the traffic sent to each backend instance from the health probe you can use IP stack statistics with a tool such as netstat. The health probe traffic originates from 168.63.129.16.

When enabled on the frontend IP for a load balancer, DDoS Protection applies protection for all backend pool resources that are accessible through that public IP. For more information, see Azure DDoS Protection Reference.

The following ports are restricted for HTTP health probes: 19, 21, 25, 70, 110, 119, 143, 220, 993. These ports are blocked for security reasons by WinHTTP, meaning that Load Balancer health probes are unable to use these ports. For more information, see What's New in WinHTTP 5.1.

Yes, you can ping the frontend of your Standard Public Load Balancer. For more information, see how to ping the frontend of your load balancer.

No, Azure Load Balancer does not support the direct addition of On-premises IPs to its backend pool. The load balancer employs a platform-specific IP address (168.63.129.16) for health probes, limited to communication within Azure's virtual network. Consequently, it cannot probe resources located on-premises.

Next steps

If your question is not listed above, please send feedback about this page with your question. This will create a GitHub issue for the product team to ensure all of our valued customer questions are answered.