Azure Load Balancer could load balance any TCP/UDP traffic to the backend servers; however, Azure Application Gateway is designed to distribute the incoming web requests to a web application. Unlike Azure Load Balancer, which operates at layer 4, or the Transport layer, Application Gateway uses layer 7, or the Application layer, routing to route the traffic to the backend web applications. Since Application Gateway is operating at layer 7, the IP addresses of the backend servers are not considered; rather, hostnames and paths are used for routing. Application Gateway supports virtual machines, VMSS, Azure App Service, and even on-premises servers.
Requests are routed in a round-robin fashion to the backend servers. If you would like to implement session stickiness, Application Gateway supports that as well. Using session stickiness, you can override the default round-robin fashion, and client requests in the same session will be routed to the same backend server. Let’s understand the features of Application Gateway:
- Supported protocols: It supports HTTP, HTTPS, HTTP/2, and WebSocket.
- WAF support: Web Application Firewall can be incorporated with Application Gateway to protect web applications.
- Encryption: It supports end-to-end request encryption.
- Autoscaling: You can dynamically scale Application Gateway to handle traffic spikes.
- Redirection: Traffic can be redirected to another site or from HTTP to HTTPS.
- Rewrite HTTP headers: It allows passing additional information with the request or response.
- Custom error pages: Instead of using the default error pages, you can use custom error pages.
Now you are familiar with the features of Application Gateway. Let’s see how Application Gateway deals with client requests.
Request Handling Process
The architecture contains front-end, listener, backend, and WAF (optional). You have already seen how front-end and backend works in the case of a load balancer. In Figure 5.8 you can see how the traffic is getting routed from the front end to the backend.
FIGURE 5.8 Working of Application Gateway
The following is the end-to-end process that happens when a request hits the Application Gateway:
- The users will be accessing the web application by sending the request to the front-end IP address of the Application Gateway. In real-world scenarios, you would be mapping the IP address of the Application Gateway to a DNS name, and the client reaches the Application Gateway by resolving that DNS name.
- Once the DNS returns the IP address of the Application Gateway, the request will be sent to the front-end IP address of the application.
- Application Gateway uses listeners to accept incoming traffic. As the name suggests, the listener listens or checks for connection requests. You can have multiple listeners configured with the front-end IP address, protocol, and port number.
- Optionally, you can add the web application firewall (WAF) to check the request headers of the body (if present) against the WAF rules. WAF can be used to determine if the incoming request is a legitimate one or a security threat.
- If the request is valid, based on the rules configured, the request will be routed to the backend pool.
Similar to an internal and public load balancer, you can use Application Gateway for internal applications and for Internet-facing applications. When you configure the Application Gateway as a public-facing one, you will have a public IP address mapped to the Application Gateway. Throughout this section, we mentioned routing; however, we haven’t covered the routing methods in Application Gateway. Let’s take a look at the routing methods available in Application Gateway.
