All the client requests will be hitting the front-end IP address of the Application Gateway. As discussed earlier, you can configure private IP address, public IP address, or both. You cannot have more than one public IP address and one private IP address.
Listeners
Listeners are responsible for accepting the incoming traffic based on the combination of protocol, port, host, and IP address. The listener listens for the selected traffic and routes the requests to the backend pool. You can configure basic or multisite listeners; we will cover this later in the chapter. You can also configure the certificates in the listener for HTTPS connections.
Routing Rules
Routing rules act like a bridge between the listener and the backend pools. Basically, the rule identifies how to interpret the hostname and path elements in the incoming URL request and direct the traffic to the backend pool. HTTP settings are also associated with the rule. HTTP settings imply whether the traffic is encrypted between the Application Gateway and the backend servers. HTTP settings also cover other configurations such as protocol, session stickiness, connection draining, request timeout period, and health probes.
Backend Pools
In Application Gateway, the backend pool refers to a set or collection of web servers. You need to provide the IP addresses of each web server that needs to be part of the backend pool. Application Gateway supports a set of virtual machines, VMSS, Azure App Service, or a collection of on-premises servers. The incoming requests are distributed across the backend pool.
Health Probes
As you saw in the case of Load Balancer, health probes are used to determine the health of the application and to decide whether the traffic should be routed to the server. If the response code is between 200 and 399, the server is considered as healthy. If the consecutive failures reach the threshold, the server will be marked as unhealthy. Application Gateway makes sure that the requests are not routed to the unhealthy servers. If you don’t create a health probe, Application Gateway will create a default probe for checking the health of the server. The default threshold value is 30 seconds.
Web Application Firewall
Web Application Firewall (WAF) is an optional component that can be included in the Application Gateway. In Figure 5.11, you might not see the WAF component; however, it’s visible in Figure 5.8. If you are using WAF, the incoming requests are scanned or validated before it reaches the listener. WAF relies on Open Web Application Security Project (OWASP) for checking the requests for threats. Identified threats include SQL injection, cross-site scripting, command injection, HTTP request smuggling, HTTP response splitting, remote file inclusion, bots, crawlers, scanners, and other HTTP protocol violations and anomalies. You can enable WAF on Application Gateway by selecting the WAF or WAFv2 SKU of Application Gateway.
Enough with the theory part, let’s perform an exercise to implement Application Gateway and load balance the request between the web servers.
