This course will provide you with a foundational understanding of the different ways you can load balance traffic in Microsoft Azure. It includes guided walk-throughs from the Azure platform to give you a practical understanding of how to implement load balancing in your Azure environments.
We start by introducing the different types of load balancers, their components, and their use cases. You'll learn how to deploy a load balancer on Azure. Then we'll dive into Application Gateway and you'll learn about its features and components. You'll also learn about Azure Front Door and how to create a Front Door instance.
We'll then take a look at Web Application Firewall, when it's used, and how to use it in conjunction with Application Gateway, Azure Front Door, and Azure CDN. Finally, you'll learn about Traffic Manager, how it works, and when to use it, as well as how to create a Traffic Manager profile.
- Get a solid understanding of load balancing on Azure
- Deploy a load balancer
- Understand the features and components of Application Gateway and how to deploy it
- Learn about Azure Front Door and how to create a Front Door instance
- Learn about Web Application Firewall and how to deploy it on Application Gateway
- Learn how to use Traffic Manager and how to create a Traffic Manager profile
This course is intended for those who wish to learn about the different ways of performing load balancing in Azure.
To get the most out of this course, you should have a basic understanding of the Azure platform.
Welcome back. In this demonstration, we're going to walk through the process of configuring Azure Front Door so that it directs user traffic based on lowest latency between two web apps. Now, what I've done here to prepare for this demonstration is deploy two different web apps in my environment, within the LBLab, Resource group I created a web app called BlueWidget1. This application is hosted in Central US.
In the LBLab2 resource group that I've spun up, I created a web app called BlueWidget2. This application runs in East US. What we're going to do is configure front door to front end both BlueWidget1 and BlueWidget2. So let me bounce back into LBLab which is my primary resource group here for some of my labs. And to create our front door, what we're going to do is go to the hamburger and create a resource. And then from here, we can search for front door or we could browse it by going into Networking and then finding front door down here in the feature or if we See all, we could find it down in here.
So for this demonstration, we'll search for front door, we'll select it and we will deploy our Front Door. When we create a front door we need to tell Azure what subscription to deploy to and into what resource group. So we'll go into LBLab for this. Now we can see the Resource group location is greyed out because we can't change that.
Next, we'll go into the configuration of the door and we can see here that this configuration happens in three steps. We create the Front end, we create the Backend, and then we create the Routing rules. So let's go ahead and click the plus sign here to create a frontend. Now this frontend is going to be where traffic enters. This host name here is upended with this domain of Azure FD for front door. It's Azurefd.net. So the name I give it needs to be globally unique across the entire landscape. So I'm going to call this bluewidgetFD.
So, for our host name, we'll call it bluewidgetFD which stands for bluewidget front door. So the complete host name will be bluewidgetFD.azure.net. Now for this demonstration we're not going to configure session affinity. Now that session affinity would allow us to direct traffic from a specific user session to the same application backend for the duration of the session. I'm not worried about affinity right now, so we'll leave that alone nor am I going to configure web application firewall this time.
So at this point, we can click Add. At this point we have our front end configured for our front door. Now we need to tell Azure what the backend is going to be where are we going to send our traffic to. So we'll go ahead and plus it up here and we'll just call this MyBackend. Actually we'll call it MyBackendPool.
We'll go ahead and add a backend and the backend host type allows us to define what that backend is. In our case here, it's an app service. So we'll select App service. We can see it fills in the backend host name, the backend host header. All of this HTTP information is automatically filled in. We'll go ahead and add this backend and then we'll add the second backend bluewidget2 and we add.
These health probes here allow the front door to check the status of our backends. These can be left at their defaults. And then the load balancing settings down here are used as it says here to define what sample set we need to call the backend as healthy or unhealthy. We'll go ahead and add. And now we have our front end and our backend defined.
At this point, we need to add a routing rule. Now this routing rule is going to map the front end host to a backend pool. So let's go ahead and create a routing rule here and we'll just call this MyRule. Now for this demonstration we can accept the default settings here because the accepted protocol is HTTP and HTTPS which is what we're going to send to our backend. And we can see the front end is already free filled with the front end that we defined earlier.
The pattern to match is the default URL path and then the route details here tell front door what to do. For example, with the forward setting, if we hover over this, we tell the front door to forward traffic to the backend rather than redirect it. We can see the backend pool is configured. If we hover over URL rewrite, we can take a look here and see that by enabling this, we can configure a path to use when constructing this request for the URL and use a rewrite to forward that to the backend. And the same thing with caching here. We can enable caching for this particular routing rule.
Now for this demonstration, we're not going to do any rewriting or caching so we can go ahead and add our rule. At this point, we have our front end configured, our backend and our routing rule. So we'll go ahead and create our front door here, we get the validation and then we can create.
Now once this deployment completes, we'll go in and I'll let you see what happens with Azure front door here by viewing it in action here. Now what Azure front door is going to do for us is perform pretty much an instant global fail over. Remember one of our apps is in the East region and the other one is in Central.
So let's go ahead and open up an incognito window and browse to our front door. And now the bluewidgetfd.azurefd.net is directing to our app service. And what front door will do is keep track of which application is running and if one of them goes down, front door will ensure that traffic instead of being sent to the down instance is sent to the instance that remains up. And that's pretty much it. I mean, setting up the front door service, isn't terribly complicated, you simply set up a frontend, a backend and your rule to route that traffic. That traffic is then directed to each of your backends that you've configured behind that front door service.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.