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.