Azure docs have a great page on the various load balancing options in Azure that even has an awesome flowchart summing up the choices. However, not being from a networking background, combined with Microsoft’s “special” naming, combined with some sort of memory issue recalling these names from memory meant that even if I had to rely on rote memory when in conversations with customers, I would often mix up the names. For instance, confuse traffic manager and load balancer. So, I decided to understand some of the basics behind cloud load balancers to help become a more interesting conversationalist in this topic: “well actually, you should be using an app gateway there, John”.
You have 4 major options for load balancer in Azure (if you’re reading this in the year 2136, please exit now because this post is outdated af):
Some important concepts:
What is Cloud Load Balancing?
Load Balancing in the cloud is the process of distributing traffic and requests to multiple backend servers. The Load Balancer which does this activity sits between the Internet and cloud servers, listens to incoming requests and can distribute them on a variety of criteria including server load, geography, url route and so on.
Level 4 versus Level 7 Load Balancing
When reading about Load Balancers you will see references to Level 4 and Level 7. These are based on the OSI Model where Level 4 (L4) represents the transport layer and Level 7 (L7) represents the application layer. But what does this mean for us?
Well, L4 load balancers being able to operate at a transport layer means they will be able to handle L4 protocols like TCP and UDP. L7 being the application layer is focused on protocols built on top of these protocols (for instance: HTTP, SMTP). And since they’re at an application level, L7 load balancers can also handle “fancy” operations like security, routing, performance, and so on.
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
L7 | n/a (DNS-based routing service) | L7 | L4 |
Application Delivery – Controllers, Network and such
In the world of networking, application delivery is the process of making an online application (global, regional, local) highly available, secure and reliable. \
Load Balancing in the cloud is not just about distributing packets but also dealing with other issues like handling high transactions with minimal delay, enabling high availability and fault tolerance, and ensuring security. Application Delivery Controller (ADC) is a load balancer that performs a subset or all of these and more. ADCs can be hardware-based (F5 Big IP, Citrix Netscaler) and/or software-based (NGINX Plus, Azure Application Gateway). Based on the features, it stands to reason that ADCs are L7 load balancers.
While ADCs are capable of handling load balancing at a datacenter/regional level, global distribution requires an additional layer of complexity. Enter Application Delivery Network (ADN). An ADN is comprised of a WAN optimization controller (WOC) and one or more ADCs.
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
ADN | ADN | ADC | n/a |
Global versus regional:
Global: indicates presence across regions and, even, on-prem.
Regional: resources usually within VNETs and restricted to zonal/zone-redundant
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Global | Global | Regional | Regional (see note below) |
Note: There is a service in preview Cross-Region Load Balancer that uses a global frontend public IP address that is advertised across most Azure regions, and a backend pool that contains regional load balancers
Protocols
Protocol | Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|---|
HTTPS | Supported | Supported | Supported | Supported |
HTTP | Supported | Supported | Supported | Supported |
HTTP/2 | Supports HTTP/2 but backend is HTTP/1.1 only | No | Supports Websocket and HTTP/2 | Supports gRPC and HTTP/2 |
TCP | 80 and 443 only | All ports | 80 and 443 only | All ports |
UDP | Not supported | Not supported | Not supported | Supported |
Web Application Firewall (WAF)
SQL injection and cross-side scripting type vulnerabilities are the most exploited ones even in “whenever you’re reading this in the future”. WAF is a security service that protects web applications from these common exploits and vulnerabilities, such as SQL injection and cross-site scripting. It inspects (L7) the incoming traffic and can block or allow requests based on predefined or custom rules. Front Door and Application Gateway can function as WAFs
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Yes | No | Yes | No |
SSL Termination
SSL/TLS termination is the process of decrypting the encrypted HTTPS traffic at the load balancer level, before sending it to the backend servers. This reduces the CPU load on the backend servers and improves performance, which is useful in high volume processing scenarios. Since Front Door and Application Gateway are L7, they can perform SSL termination.
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Yes | No | Yes | No |
Path Based Routing
If my application had /images or /videos in the url, I want to route the request to the appropriate services/servers. Again these are L7 operations, hence supported by Front Door and Application Gateway.
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Yes | No | Yes | No |
Caching and Acceleration
Again this is an L7 operation but since caching depends on geography, only Front Door can achieve this
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Yes | No | No | No |
Health Probes
This indicates routing based on the health and availability of backend servers and all of the above services are capable of this.
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Yes | Yes | Yes | Yes |
Session Affinity
Once a connection is established, it’s more cost effective to keep it open for an extended duration. This can be achieved with usage of cookies, IP addresses and other techniques. Traffic Manager can achieve this by using IP addresses of the client, and Front and Application Gateway use user sessions.
Front Door | Traffic Manager | Application Gateway | Load Balancer |
---|---|---|---|
Yes | Yes | Yes | No |
Useful Rules of Thumb
- For PaaS web applications, Front Door is probably the best (and often the only) load balancing option.
- For global non-HTTP(s) like IoT, start by considering Traffic Manager.
- Front Door and Traffic Manager are mutually exclusive and will never (I’m sure some “well actually” will chime in here) be used together.
- Application Gateways are the best fit for AKS due to Application Gateway Ingress Controller (AGIC), a service that acts as a monitor for services in the AKS cluster and updates the Application Gateway when it detects changes.
- Most global architectures end up putting a Load Balancer or Application Gateway behind a Front Door or Traffic Manager.
- Get comfortable mixing and matching options to best suit your need with rule 3 in mind.
- Traffic Manager and Load Balancer can handle HTTPs traffic, they’re simply ot the best fit.
- Cost: Front Door >> Application Gateway >>>> Traffic Manager >>> Load Balancer
Official Azure Flowchart of selecting load balancing services
Azure Guidance on load balancing options
Top comments (0)