Reviewing Azure Application Gateways
Azure Application Gateways are an alternate load balancing solution provided by Azure, which differs from the load balancers covered earlier in this Lab in several meaningful ways to provide more customized support for both public and private web applications. While the load balancers covered earlier route traffic purely based on IP address and port information, application gateways can take this a step further and route based on things like URIs. This means that an application gateway can route traffic sent to "some-ip-address/admin" differently than, say, traffic sent to "the-same-ip-address/general" This allows for much more detailed control of your routing.
Application Gateways also have the ability to accept traffic for more than one site using multiple site hosting. In a previous Lab Step, you learned how load balancers route traffic to backend pools. Application Gateway Multiple Site Hosting works by sending traffic from examplesite1.com to backend pool 1, traffic from examplesite2.com to backend pool2, and so on. This allows for the management of up to 100 sites using a single Application gateway.
Application Gateways offer many other very useful features such as SSL termination, connection draining and request redirection. While this Lab Step will cover the fundamentals of Azure Application Gateways, it's highly worth it to learn more about application gateways in depth.
1. On the dashboard of the Azure Portal, click the portal menu > All resources:
2. In the All resources blade, click calabs-appGateway:
3. On the Overview blade, notice a couple of things:
- The application gateway is deployed into the Virtual network/subnet, calabs-vnet/calabsappgatewaysubnet. Recall that this is the same VNet you have seen other resources deployed into, and a new subnet that you haven't seen. Recall from a previous lab step that because the application gateway is deployed into its own subnet, it has a level of isolation from other resources deployed into the same VNet.
- The application gateway can have both a Frontend private IP address and a Frontend public IP address.
4. In the menu to the left, click Backend pools and then click appGatewayBackendPool:
Notice that similar to the load balancer covered in a previous Lab Step, this application gateway has a single backend pool with two targets.
5. Click Cancel:
6. In the menu to the left, click Listeners:
Notice that there is a single listener. Currently, it listens to connections on port 80 and sends that request to a rule, rule1:
7. In the menu to the left, click Rules:
8. Notice that there's a single rule, rule1, which you saw a moment ago. Click it:
You'll see that the rule is sending traffic to the backend pool you saw earlier, appGatewayBackendPool.
9. Click calabs-appGateway - Rules at the top of the page:
10. At the top of the Rules blade, click + Request routing rule:
Note: You don't have to create any resource. This is just to show you how to proceed in case you want to create it.
In this Lab Step, you navigated to an Azure Application Gateway in the Azure Portal. You learned what an application gateway is and how it differs from a traditional load balancer. You also learned why companies might choose to use one, as well as how they are configured and how they handle traffic.