Azure Load Balancing Solutions

Welcome in this segment, where I discuss different Azure load balancing solutions as part of the broader Azure Networking Fundamentals video here at Apress. Overall when we look at the Azure solutions around load balancing, we can differentiate four solutions. The first one is Azure Load Balancer, which is a typical layer for more traditional load balancing solution.

The second one is Azure Application Gateway, bringing in some additional features besides the technical load balancing itself, where the solution is known as Azure Application Gateway. And that one is active on the application layer, also known as Layer 7. Besides the Azure built in services, one can also deploy a Network Virtual Appliance, which we already talked about in a previous video but mainly from a firewalling perspective.

Now think of popular brands like KEMP, Barracuda, F5. So similar to the on-prem physical appliance solutions you deploy, you could achieve the same in Azure using virtual machine-based deployments. And then lastly we have Azure Traffic Manager and Azure Front Door service, providing load balancing across multiple Azure regions, as well as in a hybrid topology between Azure and your on-prem center.

Now as a starting point, probably one of the most-used scenarios is external load balancer. An external load balancer means that the load balancer has an internet-facing public IP address, which can be dynamic or static. All incoming traffic will be routed through this load balancer, which means that the web virtual machines, for example, Standalone VMs or in this scenario as part of a broader availability set, is going to help you in load balancing traffic to all virtual machines in that availability set.

And in a more complete network diagram, we could distinguish two tiers in the application. This solution could be set up as follows, still having an external Azure load balancer for the front end web servers but then extending it with another internal load balancer, where this one only has an internal IP address, and load balancing happens for the back end, for example, database servers.

Now the core message out of this light is that Azure Load Balancer,, as the load balancing service, must be one or the other. So it can’t ever combine with two in the same service. And then the other solution is Azure Application Gateway. Now, Azure application gateway is another service, so you don’t need to deploy any infrastructure. And it’s only active on the external configuration, which means that it has an internet-facing IP address, which, again, can be a dynamic or a static one.

All incoming traffic will be routed again through the load balancer to the web virtual machines in the back end. Now, compared to external Azure Load Balancer in the previous diagram, Application Gateway doesn’t load balance all traffic protocols, because it only supports HTTP, HTTPS web traffic.

Now, the advantage here is that you can choose for a version that also has web application firewall built in, giving you additional protection of your web workloads, running behind the load balancer and allowing you to scan and detect any malicious web traffic. On top of that, it also comes with other load-balancing capabilities not existing in Azure Load Balancer, where Session Cookie affinity, URL based routing, and SSL Offloading are probably the most interesting ones.

I will now let me move over to another demo, where I’m not really going to show you how to deploy to load balancers this time, but walking you through the different configuration settings of an already deployed Azure Load Balancing service. So as mentiones, I’m not going to show you the full deployment of a load balancer. It’s similar to any other Azure resource, but at least walking you through some of the configuration parameters.

So let me go to my resource where I have my network components deployed already, and opening up this load balancer. So what I have here is a pretty basic load balancer. As you can see here, there’s a load balancing rule, load balancing port 80. It has a public IP address, so it’s internet external-facing load balancer, where my public-facing website would run on that specific IP address.

And then going through some specific settings– so first of all, my load balancer front end, so the public-facing internet address– the back-end pool, and this would basically be a list of back-end resources, where in this scenario I’m using virtual machines, VM 1, 2, and 3, where the virtual machines are using internal IP addresses.

Another important configuration setting in the Load Balancer Configuration is the Health Probe. The Health Probe is basically a signal where the load banancer is checking back to the back-end pool if the machines are still there. Because basically in this setup, what I have is three virtual machines, where obviously if one of those virtual machines are down, then they should be removed from the Little Balancing Pool. And that’s mainly managed by the Health Probe. So it’s some kind of intelligence-checking mechanism out of the Load Balancers.

And the most important is the Load Balancing Rule, where I’m going to define as being the Load Balancing Configuration, what do you actually need to load balance. Where for this one, I’m using HTTP on port 80. So all other traffic that’s being routed to my virtual machines will not be routed through the load balancer. That’s really the important message here. Outside of that, it’s acting like any other load balancing mechanism you might already be familiar with from your on-prem environment.

And then a second solution I have is my Application Gateway, where you can see that although it’s a different service, there is a lot of similarities. So I also have my front-end public IP. So the 23.97 is the public IP of this application gateway.

Next I’m going to define some configuration parameters, like the tier giving me the version without web application firewall or the one including web application firewall and SKU size, which mainly provides you better performance and better throughput. If I enable Web Application Firewall, it’s also giving me this WAF tier option.

So I first need to enable it here, saving the settings, and then I can switch and enable my specific Web Application Firewall Operation Mode, where I can run it in a detection mechanism or in a prevention mechanism. So it’s a little bit and in detail. Detection is mainly going to block off any suspicious activity, and prevention is working on a similar level but acting in a different way.

And next I can specify my rule based on what I want to block off if anything that’s coming already out of the default detection mechanism should not be good enough. Then similar to a typical layer 4 load balancer is the back-end pool, where the back-end pool in this scenario would point to internal virtual machines, but could also be Azure Web Apps. For example, we’re going to define some HTTP settings, since I’m a load balancing HTTP. It could be the same for HTTPS on port 443.

And then the specific load balancing functionalities– so I’m going to use– SSL encryption would be another option here and recognizing different SSL encryption cipher. Then similar to the load balancer before, App Gateway also works with different rule sets, and also using the health probes as the mainly detection mechanism. So two different load balancing solutions, pretty similar in configuration options, but somehow totally different in the effective load balancing capabilities.

In this video, you learned about several load balancing solutions available in Azure, talking about Azure Load Balancer as the first one, allowing you to load balance external and internal traffic. Next we also talked about Azure Application Gateway, another load balancing solution, mainly used for internet-facing traffic and only supporting HTTP, HTTPS as domain services.