When to use Azure Load Balancer or Application Gateway
- Published on
- Reading time
- Simon Waight
One thing Microsoft Azure is very good at is giving you choices - choices on how you host your workloads and how you let people connect to those workloads.
In this post I am going to take a quick look at two technologies that are related to high availability of solutions: Azure Load Balancer and Application Gateway.
Application Gateway is a bit of a dark horse for many people. Anyone coming to Azure has to get to grips with Azure Load Balancer (ALB) as a means to provide highly available solutions, but many don't progress beyond this to look at Application Gateway (AG) - hopefully this post will change that!
The OSI model
A starting point to understand one of the key differences between the ALB and AG offerings is the OSI model which describes the logical layers required to implement computer networking. Wikipedia has a good introduction, which I don't intend to reproduce here, but I'll cover the important bits below.
TCP/IP and UDP are bundled together at Layer 4 in the OSI model. These underpin a range of higher level protocols such as HTTP which sit at the top of the stack at Layer 7. You will often see load balancers defined as Layer 4 or Layer 7, and, as you can guess, the traffic they can manage varies as a result.
Load balancing HTTP using a Layer 4 capable device works, though using Cookie-based session affinity is out, while a pure Layer 7 solution has no chance to handle TCP or UDP traffic which sit below at Layer 4.
Clear as mud? Great!
You might ask what does it mean to us in this post?
I'm glad you asked! :)
The first real difference between the Azure Load Balancer and Application Gateway is that an ALB works with traffic at Layer 4, while Application Gateway handles just Layer 7 traffic, and specifically, within that, HTTP (including HTTPS and WebSockets).
Anything else to know?
There are a few other differences it is worth calling out. I will summarise as follows:
- Load Balancer is free (unless you wish to use multiple Virtual IPs). Application Gateway is billed per-hour, and has two tiers, depending on features you need (with/without WAF)
- Application Gateway supports SSL termination, URL-based routing, multi-site routing, Cookie-based session affinity and Web Application Firewall (WAF) features. Azure Load Balancer provides basic load balancing based on 2 or 5 tuple matches.
- Load Balancer only supports endpoints hosted in Azure. Application Gateway can support any routable IP address.
It's also worth pointing out that when you provision an Application Gateway you also get a transparent Load Balancer along for the ride. The Load Balancer is responsible for balancing traffic between the Application Gateway instances to ensure it remains highly available :)
Using either with VM Scale Sets (VMSS)
The default setup for a VMSS includes a Load Balancer. If you want to use an Application Gateway instead, you can either leave the Load Balancer in place and put the Application Gateway in front of it, or you can use an ARM template similar to the following sample to swap out the Load Balancer for an Application Gateway instance instead.
The key item to ensure is that the Network Interface Card (NIC) is configured for each VM in the Scale Set to be a part of the Backend Address Pool of the Application Gateway.
So there we have a quick overview of the Azure Load Balancer and Application Gateway offerings and when to consider one over the other.
Either the Azure Load Balancer overview or the Application Gateway introduction provides a good breakdown of where you should consider using one or the other.
Happy (highly available) days! :)