1. Create an Application Gateway DEMO
Let’s look at the differences between setting up an application gateway compared to setting up that load balancer. So if I type “application gateway” into the marketplace, it comes up as the first result, and I can say that it’s poorly rated for some reason. So an application gateway is a web traffic load balancer. So remember, this is a layer 7 load balancer, which means it does operate at the application layer. It understands URLs, domain names, and paths. You can actually create separate rules for different paths. So I’m going to put this into my resource group here and give it a name. AZ 700 app gate In this case, put it in the western United States. Now, much like the load balancer, we do get different SKUs. There is the standard load balancer. And remember that I said that you have the option of getting what’s called a web application firewall. Now it does cost more, but this actually does some filtering on your traffic based on some internet standards for bad web traffic. So if we wanted to block SQL injection, cross-site scripting, and things like that, we could have auto scaling.
So the application gateway comes with this concept of having instances and growing the number of instances. I’m going to say no to that for now, and we’ll start with the two instances, and we can also tell it what we want in terms of our firewall. So this web application firewall is turned on by default because I’ve chosen the web application firewall tier. And do we want to just detect it, log threats, or actually start blocking traffic? I’m going to say that, for prevention, WestUS does not have availability zones. But if I put this in a region supporting availability zones, then I can actually put these application gateways in specific zones. And we’re going to put this on a virtual network. This is one of those things, okay, and where do we want this? I’m going to put this on the application gateway, which requires its own subnet. As a result, I can say manage subnet. I can create it; it doesn’t require a specific name, but I’m going to call it the Apgy subnet. Now the size of the subnet is kind of relevant because application gateways are scalable. And so if you create a very small subnet like this, then you’re ending up with only eleven IP addresses. That kind of limits your scalability.
So Microsoft actually recommends you get a larger subnet than you might think. So 26 being a good size, you could make it smaller or larger, up to you. So I’m not going to select any of these other options, and we will create a subnet for it. We will need to recreate our application gateway so that I can put this in its own subnet. Now, unlike the load balancer, we do get to set up the front end, the rules, and the back end, right within the wizard here. So if I click next, we’re going to now configure the front end. Now you see some IPS; I have them associated with this, so I’m going to create a new IP for it. So, once again, we have the option of public or private front ends, as well as both. So again, the application gateway is a more sophisticated type of load balancer. So that’s our front end, and now we’re going to set up the back ends.
Now one of the unique things about the application gateway compared to the load balancer is that it does support other things besides virtual machines and virtual machine scale sets. You could even just direct this to an IP address. And so that means that the application gateway can be the load balancer for computers that are hosted outside of Azure. So if you have AWS instances that have public IP addresses, you could use the Azure load balancer in the application gateway to do load balancing for those external servers. Now, I’m not sure about the latency and other issues, but that means you could mix some Azure servers with some on-premises servers, all running the same application. The application gateway does the load balancingbetween on Prem and your Azure.So a lot more options in terms of this.So I’m going to add the backend pool, and we could create the backend pool just like with the load balancer blank. But in actual fact, I’m going to point it to the virtual machine. We created a special server that already has the web server installed. So I’m going to point it to the web server and type add.
Now again, we could put multiple web servers on VMs, and I could do the individual VMs. It doesn’t require the VMs to be on an availability set, for instance. So I can just pop in all my VMs here, and the application gateway will load balance between them. not going to do that. Now we’ve got the front end, we’ve got the back end, and now we’re talking about the rules, or, yeah, the routing rules. And we can see this screen here that allows us to create rules that connect the front end and the back end. So I’m going to call it rule number one. And now for the listener. Now we’re going to choose our front end, our public IP address, because it only supports HTTP and HTTPS. So those are your only two options, and this is going to be a basic load balancer. That’s the listener side. And then, when it comes to the back end, we just point it to the backend pool. Because we don’t have these HTTP settings configured here, http one is the port 80 back end pool. We will not have cookie-based affinity. So, like the load balancer, session affinity allows any client to be directed to any server connection draining is a cool feature in that, let’s say you’ve grown your back end to have several servers and you want to shut down one of them to save money.
Well, instead of just shutting it down, you can actually wait until the server no longer has any traffic and then shut it down. And so no customer ends up being disturbed. All right, we’ll leave all of the defaults here. So that’s the HTTP settings, and one of the other unique features of the application gateway is that you can have path-based rules because it understands HTTP. And so if you wanted to have your images on one server, your videos on another server, and your JPEGs on another server, you could create rules based on specific paths in your URL. Now we only have one back in the pool. It’s not a multiple target situation. And so all traffic is going to our backend pool, and that’s it. Creating the load balancer, you see, is a unique experience. I’m going to say “review and create.” Hit create. This is going to take some time because this is an actual instance that’s being spun up here. It’s got a firewall. And when we get at the end of this, we’re going to end up with an application gatewayload balancer, and very much similar to when we did our load balancer just a few videos ago.
2. Test the Application Gateway
Alright, so the public IP and the application gateway have been created. If we look at the details, it did take around 7 minutes, so a little longer than the load balancer. It should basically just work. If I click on go to resource, we are in the application gateway, and it is running. If I copy the public IP address of this, I’m going to paste this into a web browser here, and it worked. So I can actually go to the Open Web Application Security Project. It’s an open-source foundation, and they do publish a set of rules.
And so the web application firewall is following the CRS 3.0 standard, and you can choose to upgrade to 3.23.1 or downgrade. And we can see the types of attacks that it protects against: IS, SQL injection, cross-site scripting, other types of HTTP protocol attacks, missing host and user agent, certain missing headers, bots and crawlers, and some of the common misconfigurations of your back end. So it’s definitely worthwhile. It does cost money, but if you’re seeing public traffic, you want to avoid some of the basics.
3. Rewrite HTTP Headers
The application gateway has some other cool features. And in this video, we’re going to talk about a feature called rewrites. Now the application gateway actually stands between the client, who’s requesting the web page, and the web server. And so, in effect, it can actually rewrite request and response headers and make modifications to things such as the path of the request. So, if you go to rewrites, you’ll see this for the time being empty space. And what we’re going to do is create what’s called a “rewrite set.” And a rewrite set is just a collection of rules, and those rules have priorities. We will observe how we create those rules. I’ll call it “rewrite set 1,” and it’s associated with an existing routing rule. And we only created one routing rule because we only have one server back end. So we’re adding a rewrite rule set for the only rule that we have. Now we have this canvas. It kind of reminds me of logic apps.
Where you can have actions and they connect to each other, you can have conditions. So we give it a name; we’re going to call it “add header.” Now, sequence is like priority. It’s going to be done in numerical order. The lower priorities get executed first. So you might have to order things the correct way. Now in this example, what I’m going to do is add a new header to the response that didn’t get set by the application. So if I wanted to make it conditional on something, there’s this “add condition” button. But at this current time, we’re just going to add action. And by clicking “add action,” I’ve now made two, but that’s okay. So what I’m going to do is modify the response, and we have the ability to remove headers or add headers. And so I’m going to set a header and take a list from the common set of headers. Or you can write your own headers; scrolling down, you can see a bunch of them. The one I’ll focus on is called “x powered by.” And you see this sometimes in various apps. I’m going to change “powered by” to “Scott spring.”
And so what we would expect is that anytime we call the application gateway, we’re going to see this response header added to it. Okay, so it’s pretty easy. Sometimes you need to do this for various reasons. Again, you can also remove headers if you don’t want information to leak. And so it says expired by Scott Spring, and I can say, “Okay, I’ll remove the excess one.” Now I can actually hit the create button, which will actually implement the rule, and then we can test to see how that goes. So I opened a browser and went to the web application through the application gateway. And if I look at the traffic in the developer mode for Chrome, I can actually see the response headers and the X powered by Scott’s brain sent back to the client from this request. So as soon as we created this rule, the application gateway is now adding a new header to the response. And if that’s what you needed to do, you can do it. We could also, as I previously stated, remove if we didn’t want to leak this server tag, for example. We could certainly ask the application gateway to remove its add-on rule. Here’s another one.
We’ll give it a unique number called “remove server.” And on the response header, we’re going to delete it, and we’ll see if the server one is there’s the server.So if I update this rewrite rule, it should remove the server header from the response. So I’m going to go back to my browser, and I’m going to hit refresh. I did make sure that the log didn’t get cleared, and it looks like the server tag did come. I cleared the cache, hit reset, and the response headers do not send a server tag anymore. That is exactly what we expect, even for images sent via my X. So this is a way of rewriting the headers. Now the other thing that you can do is if we had some type of URL structure—let’s say there was a path here—and it was like articles 1, 2, and 3. If that was my URL structure and I didn’t like it, I could write a rule that rewrites how this path appears in the browser so that the location variable could be changed. So if it’s coming back from the server in a method that you don’t like, there’s such a thing as a URL rewrite that allows you to format this in a more pleasing manner.
4. Application Gateway Scaling
Let’s talk about application gateway scaling. If we go under Settings and Configuration, we can see that we can switch between the Standard and Web application firewall editions. We can’t go back to basics, and we have the choice of manual or automatic scaling. But what does it mean to have manually scaled or auto-scaled the application gateway itself?
After all, it is the servers that are doing the work for your application. So it’s not the scaling of the application gateway that’s going to give you that benefit; it’s the scaling of the contents of the pool. So right now, we just have one server. And if we had two, three, four, or five, that would certainly improve performance in the area of high demand. Well, because of this, you may want to have your application gateway scaled as well. As we saw at the standard level, we created this with two running instances. So in our application gateway, there’s actually a redundant application gateway. There’s the primary one, and then there’s a redundant one. So if one of them were to fail, then the other one would become the primary and could continue doing the load balancing work. So this is not a single-point failure because you have two of them. But if you find that the application gateway is not keeping up with the traffic, So let’s say you’ve got hundreds or even 1000 servers doing the work behind the scenes doing the work.Well, you might want to end up having multiple application gateways to deliver the traffic.
Now, it would seem like an interesting design. I don’t want to say it’s bad, but if you have your application in a single region and you’re not taking advantage of availability zones, there’s only so much you can do to scale this for redundancy when you’re not even taking advantage of availability zones or other regions. So when you’re dealing with something at this level where you’re creating multiple application gateway instances, you may want to set yourself up in a multiregion configuration where you have your application running in a couple of different regions of the world, and then you have another type of redundancy. And we’ll talk about traffic manager and the front door shortly. But having your application gateway and then having something in front of that is certainly not an uncommon design. And we saw, as I’m going to pull in this diagram at the beginning of this section, that we were talking about combining the application gateway with another solution in terms of the Azure front door in the examples. So if we do want to use an application gateway, you could put the front door in front of it, and that will load balance it across regions. So there’s an additional redundancy option. So manual scaling is pretty simple. You just come in here, you change the number, and you drag the slider. As you can see, I have the option of running up to 125 instances of the application gateway, all of which are redundant with one another.
Essentially, the traffic comes in and goes to different application gateways to distribute the demand. The other option we have is to have this autoscaling, and so that allows Microsoft Azure to take care of basically starting with two instances and working its way up to ten or whatever number you set based on demand. If you do want to look into scaling, again, available at the standard tier level, you can do something like auto scale so that, based on demand, you’re not paying for things that you’re not going to use. But like I said, this type of setup is going to be in conjunction with multiregional availability zones and using something like Azure Front Door, which we’re going to talk about next.
