Various types of Microsoft Azure Load Balancers (LB)
In this article, we discuss the various types of Microsoft Azure Load Balancers (LB) available for architecting a solution and key the differences amongst each of them. We would also emphasize the right approach to identify an applicable Azure Load Balancer for your respective cloud environment use case.
Let’s start with the definition of what is a load balancer?
So, the load balancer is a type of service that acts as a front gate to distribute network or application traffic (i.e. across two categories OSI layer 4 or layer 7). We would discuss both these aspects in this deep dive article. The LB is generally capable of evenly distributing the traffic load across a group of backend resources or servers – fulfilling requests while optimizing the speed, capacity utilization and ensuring the server’s status is healthy to avoid any performance degradation.
Load balancer ensures using probe mechanism that the backend pool of servers or server farm is available to handle relevant requests so as to distribute the traffic efficiently across multiple servers. This would ensure high availability and service reliability ensuring the traffic is only directed to healthy services/servers.
What are the various types of Azure load balancers?
In Microsoft Azure – the following types of LBs are currently available – Azure application gateway, Azure front door, Traffic Manager, and Azure load balancer.
Azure Load Balancer (layer 4)
The Azure load balancer is OSI layer 4 LB (which means that it works on TCP and UDP). It acts as a single point of contact for client traffic and can be either internal or external. The distributed algorithm leveraged by this LB uses clustered hash (from Source and Destination IP, Source and Destination port along with protocol type) to direct the incoming traffic to available servers providing stickiness only within a transport session. This means the packets in the respective TCP/UDP session would be directed to the same DIP (Datacenter IP) behind the LB endpoint. Only when a client closes and re-open the connection/starts a new session from the same source IP (the source port changes) and directs the traffic to go to a different DIP.
There are 2 types of Azure load balancers:
External LB: In this case, the public IP and incoming traffic are mapped to the private IP/port of the VM. A specific type of traffic can be distributed across multiple VMs or services via leveraging load balancing rules (for instance public web requests can be handled across multiple web servers).
Internal LB: In this case, the internal LB distributes the traffic to resources that are inside a virtual network – i.e. traffic from the internet to internal endpoints, is not feasible via using ILB.
Azure Application Gateway (APGW) (layer 7)
An application gateway is a web traffic LB, which is intended to use for web application or internet-based service which provides HTTP/S LB (which primarily works on OSI Layer 7). It can be used for external and internal traffic on the same instance.
Application Gateway is a regional azure managed service controller which is highly scalable and available that is fully managed by Azure. It supports TLS termination and cookie session-based affinity along with many other flexibilities. This also comes with an additional layer of WAF, which provides centralized protection for web applications – from common application-related exploits and vulnerabilities (OWASP standard) and provides prevention/detection mode which could easily be monitored to gain comprehensive visibility and insight.
The following features are supported in the application gateway service:
- Secure Sockets Layer (SSL/TLS) termination
- Autoscaling
- Zone redundancy
- Static VIP
- Ingress Controller for AKS
- URL-based routing
- Multiple-site hosting
- Redirection
- Session affinity
- WebSocket and HTTP/2 traffic
- Connection draining
- Custom error pages
- Rewrite HTTP headers and URL
- Sizing
Azure Front Door (Layer 7)
Azure front door or “AFD” is a web traffic load balancer and scalable entry-point which uses anycast protocol and leverages Microsoft's global edge network. AFD and APGW work in the same technique but there’s a few difference between them – the main differentiator being that APD is a global-scale service. This signifies that the service need not be deployed inside a virtual network wherein, application gateway is deployed inside a virtual network. It also illustrates that AFD service would resolve and use origins that are publically resolvable whereas application gateway will leverage the backend services with public and non-public access.
The following features are instrumental with AFD as per Microsoft:
- Accelerated application performance by using split TCP-based anycast protocol.
- Intelligent health probe monitoring for backend resources.
- URL-path-based routing for requests.
- Enables hosting of multiple websites for efficient application infrastructure.
- Cookie-based session affinity.
- SSL offloading and certificate management.
- Define your custom domain.
- Application security with integrated Web Application Firewall (WAF).
- Redirect HTTP traffic to HTTPS with URL redirect.
- Custom forwarding path with URL rewrite.
- Native support of end-to-end IPv6 connectivity and HTTP/2 protocol.
Azure Traffic Manager:
Azure traffic manager is DNS based load balancer that manages traffic distribution to the most relevant and suitable service endpoint via leveraging the DNS.
This service works with a different routing method that provides enhanced capabilities for DNS load balancer allowing the requests to be directed to the most suable service by using the following route criteria’s:
- Priority: This mode needs to be selected when you may want to have a primary service endpoint for all traffic. It is recommended to also provide multiple backup endpoints in case, the primary endpoint is unavailable.
- Weighted: this mode can be selected in case the traffic needs to be distributed based on the weight – i.e. the weight can be set to the same value to distribute evenly across all endpoints.
- Performance: This mode is to be selected when the endpoints are available in various geographic locations and the expectation is to have end users get the close endpoint to reduce network latency.
- Geographic: This mode needs to be selected in case users are to be directed to a specific endpoint (Azure/External or Nested) – based on where the DNS queries originate geographically. This helps the client with data sovereignty requirements and to handle situations wherein the content needs to be localized/measured across different regions.
- Multivalue: This mode needs to be selected for traffic manager profiles that have only IPv4/IPv6 address as endpoints.
- Subnet: This needs to be selected to map sets of end-user IP address ranges to a specific endpoint. In this situation, the response will be the endpoint mapped to the request's source IP address.
This illustration would help you identify the right flow to identify the most feasible solution.
Conclusion:
In this article, we went through various mechanisms and feature sets that provide the flexibility to select the right type of load balancer. This would optimize the performance of the applications, along with increasing the efficiency and security posture.
Thus, to decide the apt load balancer for your environment or relevant use cases – multiple factors discussed in this write-up need to be considered. For instance, from what kind of traffic is intended to reach the application, if the application needs to be internal or external, which types of backed should be load balanced, etc.
It is also crucial to ensure a comparative analysis is done across all the LBs, with identified pros/cons for each architecture pattern leveraging these load balancers.
