I just had an interesting discussion around the use of the Azure Application Gateway (AppGW) and the built-in load balancer (LB) it has. Be aware that when you deploy the Azure Application Gateway, by default it will create 2 instances of it, as seen below:
You then may be wondering.. what’s the mechanism behind the scenes that will make the traffic go to one AppGW or the other?? Well, this is how we explain the concept of AppGW as a PaaS offering. You as an end user will consume and manage the AppGW service, not the underlying components. The truth is that Azure will use the Load Balancer to balance traffic among AppGW instances. This is all configured when you deploy the Application Gateway, and you don’t need to worry about it! Behind the scenes, the Azure LB will use a hashing algorithm to decide which AppGW will get the packet.
So what’s the virtual server address of the Load Balancer that sends traffic to the AppGW? When you assign a fronted IP to your AppGw you are actually assigning an ALB/ILB (public/private) so the IP address in question belongs in reality to the LB
In summary, to describe this architecture in simple terms, we could say an Azure AppGW is a hybrid product comprising multiple parts, but just exposed as one. It comprises a load balancer, a set of backend Virtual Machines and a management API. The LB is a also a service built from other different services and not really a compute resource with an IP address forwarding traffic – even though that’s how it should look like from the outside for majority of cases
AppGW and Load Balancer are part of the Azure load balancer services and they also comprise Traffic Manager
Be aware that AppGW is not a superset of the Load Balancer, they are different products to cover different use cases! To find more information about differences between Azure Load Balancer and Application Gateway