Welcome back. In this lesson, we are going to walk through the process of creating an application gateway. Now, if you remember from the lesson previously an application gateway is essentially a load balancer that's built for load balancing web traffic specifically. So that's what we're going to do here.

We have two VMs called VM1 and VM2. Both have IIS installed. What we're going to do is deploy a gateway and load balance that web traffic to both of those VMs through the use of a backend. So to begin the process of deploying our application gateway, we'll go ahead and select the hamburger and Create a Resource. And then we'll search the marketplace for application gateway. We'll go ahead and select it and we'll begin the creation process.

Now, when we create the application gateway, we have, looks like six different tabs here that we need to configure information for. Some of them will require more information than others. This basics tab, as you would expect is where we configure some of the basic information for our application gateway, the name, the subscription it's going to, the resource group some of that information here. So what we're going to do for this application gateway is deploy into our lab subscription and then into the resource group called LBLab.

Now in this application gateway name box we need to give our gateway a name. So I'll just call it MyAppGateway. And what we'll do here is we'll deploy into East US since that's where my other resources are here. And then in this teardrop down we can select the standard Standard V2 or web application firewall web application, Firewall V2. If we hover over the icon here we can see that the V2 tier offers performance enhancements over that of the standard original tier.

Now, if we hover over the, go back here. If we hover over the Learn more link here and open it up, we can see the information about the different features of the application gateway V2. The enhancements include like auto scaling, zone redundancy, you can even do a static virtual IP, header rewrites, all of this cool stuff that the V2 offers over the standard. So I encourage you to take a look at, that this page here and take a look and see what the application gateway enhancements are for the V2 SKU.

So we'll bounce back over here and we'll leave this set to standard V2 it is default, and then we'll keep auto scaling enabled. Now, this minimum scale units here, if we hover over the icon here, this little black box will tell us that the minimum scale units refers to additional reserve capacity which is always maintained regardless of what traffic is hitting the gateway.

Now by selecting zero here, what this does is signify a purely auto-scaling application gateway and it doesn't have any additional reserve capacity while still maintaining that high availability. So we'll leave this at zero and then the maximum scale units again, we go up to 10. We'll leave the default there. If we select the drop down for availability zone, we can see, we can select an availability zone to provide high availability for our application gateway.

If we hover over the icon on here, we can see that some regions will support the ability to put this application gateway into zones for availability or availability zones. Since we're in East US that is a region that supports availability zones. We're not going to do anything with high availability here so we'll leave this set to None. Hovering over HTTP2 shows us that the application gateway does support HTTP2 protocols for clients that are going to connect to application gateway listeners only. We're not doing anything with HTTP2, so we'll leave that off.

Now, the tricky thing here with an application gateway is the virtual network. If we hover over the icon here for virtual network, we can see that we need to provide a virtual network for our application gateway to connect to. Now that being the case, the next sentence here the second sentence in this box is critical. The virtual network that we use needs to have either an empty sub-net or a sub-net that only contains application gateways. If we don't have one of those two, we have to create a new virtual network and sub-net for that specific gateway.

Now for this exercise, I'm going to select the LBLab vnet where my virtual machines are installed. Now, if I select this, the default sub-net automatically appears because that's the only sub-net there. And it turns red here. And this is because it's not an empty sub-net because I have VMs on it and it's not a sub-net that contains just application gateways.

So what I need to do here is create an empty sub-net on that virtual network. And to do that, I select the manage sub-net configuration here. And this takes me out to the LBLab vnet virtual network, where I can create another sub-net here. So I'm just going to call this AGSubnet.

Now the address range for the subnet needs to fall under the umbrella of the address space for the virtual network. The address space for this virtual network is 10000/16. The existing default sub-net as 10010/24. So what I'll do here is call this 10020/24. We're not doing anything with Nat gateways, nothing with sub-net delegation or anything. We just need a dumb sub-net here. So we'll okay it and if we refresh this, we can see we now have the AGSubnet.

So we'll go back to the Create application gateway here, and what we'll do here is select the AGSubnet. At this point, we need to configure the frontends. So we'll go ahead and click Frontends here. Now the frontend is where traffic will enter the gateway to access whatever web application you have running. You can have a public frontend type, a private or both. For this exercise, we're going to have a Public Frontend IP address and I can either use the existing IP, which in this case I only have two defined and it's one for each of my VMs. So what I'll do here is I'll create a new one and I'll just call this AGPublicIP.

Now you can see the SKU and assignments are great out because I can't change those. The SKU is going to match that of my gateway and then the assignments going to be static. So, okay at here. At this point we have our frontend configured and now we can move on to the backends. We can see here, we have no backend pool and this obviously the backend pool is the pool of resources that the application gateway is going to send traffic to.

If you look at the note here you can see a backend pool can contain virtual machines, VM scale sets, app services, IP addresses, or even FQDNs. For this exercise, we're going to build that pool from two virtual machines. So we'll go ahead and add the backend pool. And I'm just going to call this AGBackend. Now this option here for adding backend pool without targets, if we don't have targets already defined, we could select Yes here, Create the pool and then come back and add our backend targets later. But since we already have our VMs created, we just leave this at No and then in the target type, we select the dropdown for Virtual machine. Now from Virtual machine next to it for target, we go ahead and select VM1 and VM2.

Now you'll notice I'm not even selecting VMs here, I'm selecting the NIC for each of those VMs. And there you go we go to VMs, we'll add them in and we have two targets. So we'll go ahead and Next here to Configuration. Now on this configuration tab what we're going to do is connect the front end to the backend, using a routing rule.

We can see under frontend, we have the new AGPublic IP and we can have our backend here defined as AGBackend. What we need to do here is add a routing rule. I'm just going to call this rule RoutingRule. Now the very first thing we have to do is define a listener.

Now that listener is a component that listens on the specific port and IP address for any kind of traffic. If that traffic matches the traffic that we specify here the application gateway applies the rule. So I'll just call this MyListener. Now we have to tell the listener where it needs to listen.

So in this dropdown here, we select the Public Frontend IP because this is the frontend IP that we created for it and then we're going to listen for HTTP traffic which is Port 80. Now, if we hover over Listener type here this is where we can define whether we're using a single site behind the gateway or if we're using multiple sites. We're not using multiple sites, so we'll leave this at Basic Listener type and we don't have an error page URLs. So we'll leave this set to No. And then what we wanna do is go to the Backend targets tab here.

Now, since we have a backend pool we're going to specify the backend pool target type and then we're going to select our AGBackend that we defined. Now, this HTTP settings option here. This is what defines the behavior of the rule. It's where we'll specify ports, protocols, backend settings, affinity, that kind of fun stuff. Now we don't have an HTTP setting defined yet, so we'll go ahead and click Add new. And for the name, we'll just call it myHTTPSettings.

Now we're not balancing HTTPS traffic, we're doing HTTP. So we'll leave HTTP set and the backend port at 80. Now Cookie-based affinity is a way to ensure that the application gateway forces a user session to a specific backend server or instance for the duration of the session. We're not doing any kind of a Cookie based affinity here, so we'll leave this disabled. And then for connection draining here what this does is allow you to more gracefully remove backend pool members during planned service updates.

I'm not worried about connection draining for this simple demonstration, so I'll leave this disabled as well. Hovering over the Request time-out, what this is, this is the number of seconds that the application gateway will wait for a response from the backend pool before it comes back and says there's a connection time out, or any kind of error message that it has to return to the end user. The default here is 20 seconds, so we'll leave that there. That works for me. And then this override backend path, this allows you to override the path in the URL so any requests for a specific path can get rerouted to a different path. 

So if we read what's noted in this box, we can see that for example, if he wants to route requests for contoso.com/images to the default path, we enter a forward slash here and then attach this HTTP setting to the rule associated with contoso.com/images. We're not doing any redirections or overrides here so we can leave this blank. And then under host name here, we can override with new host names. These are more advanced features we don't need to do anything with overrides here.

So we'll go ahead and click Add and we'll go ahead and finish up here. So now we have the Frontend, the Routing rule, and the Backend configured. And then if we're going to do any tagging, we can click Next for tags but we're not gonna do any tagging here. And then we'll Review and Create. And what Azure will do here is look at our configuration and validate it. Everything looks good. We get the green check mark. We can go ahead and Create the application gateway. We can see our deployment is now complete.

So we'll bounce back to our Resource group here. Now to test our gateway, what we need to do is identify the public IP address for it. And to do that, you can see here, we're in our LBLab Resource group. If we select the public IP that we created, we can see the IP address of it. So this is the public IP of our application gateway.

If we copy that and open up a new incognito window, we can paste and go. We can see that the gateway has defaulted at least on this load to VM2. If we refresh here a few times, we may be able to get it to hit VM1. Maybe we'll try to open an incognito window, do it again and we still hit VM2. Now, the reason for this is because there's really no load on these. So it's just gonna pick whatever is working and it's gonna go with it. 

So what I can do to confirm that the gateway works, is I'll bounce out of this and what I'll do is I'll go back into my LBLab Resource group here and what I'll do is I'll shut down VM2. Let's Refresh. So let's go ahead and open our incognito window and we can see we hit VM1. So the application gateway knows VM2 is no longer available, so it's now sending traffic to VM1.

If we close this out, we can go back to our application gateway here and there you have it. That's how you deploy an application gateway and how you load balance web traffic using the application gateway.