Azure Load Balancing Solutions: A guide to help you choose the correct option

Developer Support

In this post, Sr. App Dev Manager Fidelis Ekezue explain Azure Load Balancing options and highlight considerations for choosing a solution.

Azure Load Balancing Solutions: When to choose which one?

Microsoft Azure provides customers with many ways to load balance traffic requests to their environments. Customers have the options to choose Traffic Manager, Azure Load Balancer, Azure Application Gateway or the combination of all three in their Azure solutions. With the rate of web traffic increasing at a faster rate, no distributed solution is complete without the use of a load balancer to direct traffic and distribute workloads to ensure availability, better scale and sometimes to meet governance requirements. This blog provides a concise summary of the different load balancing solutions available in Microsoft Azure Cloud. The goal is to help customers make decisions on what load balancing solution to use with their applications. Although, each of these load balancing options can be used independently, there are scenarios where a combination of two or more are needed to meet business and regulatory requirements.

Azure Load Balancer

Azure Load Balancer is the first generation Load Balancing solution for Microsoft Azure and operates at layer 4 (Transport Layer) of the OSI Network Stack, and supports TCP and UDP protocols. Azure Load Balance comes in two SKUs namely Basic and Standard. The Standard Load Balancer is a new Load Balancer product with more features and capabilities than the Basic Load Balancer, and can be used as public or internal load balancer. One major difference between the Basic and the Standard Load Balancer is the scope. While the Basic Load Balancer is scoped to an availability set, the Standard Load Balancer is scoped to the entire virtual network. While the Basic supports up to 100 instances, the Standard support up to 1000 instances. See the linked articles for more detailed comparison between the Basic Load Balancer and Standard Load Balancer.

As of the time of writing, the Standard SKU is in Preview, so the focus of this blog is on the Basic SKU. Traffic is distributed to healthy instances (Virtual machines) using hash-based distribution mode. The Hashing algorithm uses a 5-tuple (source IP, source port, destination IP, destination port, protocol type) such that traffic from the same source IP are forwarded to the same instance, hence stickiness is ensured within the transport session. When an application requires connection from the same client to go to the same destination IP regardless of the port number, Azure Load Balancer uses a different distribution algorithm based on 2-tuple hash (Source IP and Destination IP) or 3-tuple hash (Source IP, Destination IP and Protocol). This is referred to as Source IP Affinity or Session Affinity. Some of the usage scenarios include

• Applications that need to load balance requests to internal resources in the private network.
• Applications that require source IP affinity or session affinity.

Azure Application Gateway

Azure Application Gateway is highly scalable and highly available service from Azure that offers layer 7 (Application) load balancing capabilities to distribute requests from clients to Azure backends. Some of the key features of the Application Gateway is the ability to offload TLS (aka SSL) and hence improve performance of web applications, Web Application Firewall to provide additional security to application, and multi-site hosting. Visit the following link for full list of the features of the Application Gateway. Some of the usage scenarios for Azure Application Gateway include:

• Applications that require the use of different criteria like URL path or domain header. The Application Gateway may be configured to forward requests to different folders in the web server, for example, images forwarded to a different backend pool and videos to another.
• Applications requiring extensive use of TLS (SSL) for encrypting and decrypting traffic may negatively impact the web server performance. Application Gateway offers a means to offload these encryption/decryption tasks by terminating TLS connection at the gateway. Prior to 2017, TLS Offload was recommended, however, Microsoft changed its internal security controls requirements for the use of TLS for all connections from recommended to mandatory. Hence TLS Offloading is not the recommended best practice and should be avoided.
• Web applications that require protection of the common exploits and vulnerabilities such as SQL injection attacks, cross site scripting (XSS) attacks and cross site request forgery (XSRF) attacks. Azure Application Manager provides these protections via the Web Application Firewall (WAF) which is based on rules from the OWASP core rule sets.
• Web applications that require real-time monitoring of attacks can also use this WAF feature of the Application Gateway. It can integrate with the Azure Security Center to enable Security personnel to full view of the security of their Azure resources.
• For applications that span both the Azure cloud and on-premise resources, Application Gateway does not apply to just Azure cloud resources, it can be used for applications running on-premise.
• Applications that requires some affinity can leverage the Application Gateway because of its support for cookie-based affinity.

Azure Traffic Manager

Unlike the Application Gateway and the Azure Load Balancer that routes traffic using the TCP/IP protocol, the Traffic Manager uses DNS to direct traffic to the appropriate backend pool. The backend pool supports any public DNS CNAME, hence it is suitable for scenarios where requests are targeted to both the on-premise application and cloud application. Because the Azure Traffic Manager operates at the DNS level, there is no concept of “IP Address” for Traffic Manager, in order word, the Traffic Manager is not aware of the IP address of the endpoint because it works with DNS CNAME records. The CNAME record does not map to IP addresses, instead it maps to one DNS name to another. A better description from Jonathan Tuliani is the forum post that described Traffic Manager as follows:

“Traffic Manager provides DNS-level traffic routing. It works using ‘CNAME’ records. A ‘CNAME’ record is like an ‘alias’, it maps one DNS name to another. It does not map names to IP addresses (that is done by DNS ‘A’ records). Therefore, when using Traffic Manager with Azure services, the name resolution path is typically configured like this:

1. Your service domain name in your vanity domain, e.g. www.contoso.com, CNAME to:
2. The Traffic Manager domain name, e.g. contoso.trafficmanager.net, CNAME to
3. The ‘A’ record for each service endpoint, e.g. contoso-eu.cloudapp.net and contoso-us.cloudapp.net, which are A records pointing to their respective service IP addresses

Traffic Manager doesn’t directly consume the IP address (static or not). It is only configured with the DNS name of the A record which points to the service IP address. From a Traffic Manager viewpoint, it makes no difference whether the IP address behind that A record is static or not”

Unlike the Azure Load Balancer and the Application Gateway that operates at layer 4 and layer 7 respectively of the OSI Network Stack, the Azure Traffic Manager uses DNS resolver to determine how to distribute requests. Hence, changes to the DNS records may be impacted by how fast the DNS cached records are refreshed. This time is determined by the DNS TTL (Time-To-Live) value. Typical customer scenarios where the Azure Traffic Manager are used include:

• Applications that require traffic distributions across Azure regions.
• Applications that require users from specific geographical region to be serviced by a different application to meet regulatory or sovereignty requirements.

The following is a concise summary of the features and capabilities of all three load balancing solutions described above.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.

Developer Support App Dev Customer Success Account Manager, Microsoft Developer Support

Follow