Azure Network EP5 – Basics of Azure Application Gateway

Hello Friends,

Let’s continue with Azure Network in this article. Today in this article we will start with a very important topic of Networking is Azure Application Gateway. In this article, we will discuss more on the basics of Azure Application Gateway components.

If you have missed our previous articles on networking, please check them in the following links.

EP1 – Basics of Azure Networking

EP2 – Azure Virtual Network (VNet)

EP3 – Subnet in Azure Network

EP4 – Network Security Group (NSG)

Next Article: Part 6 – Azure Application Gateway Features

Azure Application Gateway

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. (Referenced: Official Docs)

We can consider Application Gateway as an advanced version of Load balancer which, comes with some extra useful features. The traditional load balancer supports OSI layer 4 with the TCP/UDP. But Application Gateway supports OSI layer 7 and it works only with HTTP/HTTPS protocols (port 80 and 443). With Application Gateway, we can be more specific about the route to be followed and the destination to be reached. we can route the traffic based on the incoming URL. For example let’s consider one scenario, where our environment configured two different destinations to handle different requests like one will handle Image file requests and the other one will handle Video file requests. So here Application Gateway is smart enough, by taking the help of Listener and rules, route the traffic to the correct and accurate destination.

Figure 1: Azure – Application Gateway components

Application Gateway limits

The following table applies to v1, v2, Standard, and WAF SKUs unless otherwise stated. (Referenced: Official Docs)

In the case of WAF-enabled SKUs, we recommend that you limit the number of resources to 40 for optimal performance.

Core Components of Azure Application Gateway

Front-End IP :
Front-End IP is the entry point to an Application Gateway. Application Gateway can be configured with two front-end IP. One is for Public and the other one is for Private. it means we can configure one IP to handle all Public traffic as shown in the following figure and also can be configured with an Internet-facing VIP or with an internal endpoint that is not exposed to the Internet (by using a private IP for the front-end IP address), also known as an internal load balancer (ILB) endpoint.

Figure 2: Azure – Application Gateway FrontEnd IP

Listener:
A listener is the most important part of Application Gateway. It listens to the traffic that comes for a particular domain. The application gateway has the capability to listen to multiple traffic. every traffic will be handled by a separate Listener. We can add multiple listeners for a host to support traffics from the different protocols (HTTP/HTTPS) and for different ports. At the time of creation, we should upload a certificate, if the listener has created to listen to HTTPS traffic.

When Listener receives the traffic, it tries to communicate with the associated rule, to decide, where to redirect the traffic. If the listener doesn’t find any custom rule associated with it then it will use the default rule. One Application Gateway has the following two types of Listener.

Basic: A listener which listens to a single domain site where it has a single DNS mapping to IP address of the Application Gateway.
Multi-site: A listener which listens to a specific domain site(host). e.g production.mstech.in ,development.mstech.in ,QA.mstech.in etc.

Figure 3: Azure – Application Gateway Listener

Backend Pool:
Backend Pool is one or collection of resources that will serve the incoming traffic/requests. It refers to the hostname or public IP of our app, which will address traffics. Backend shouldn’t be confused with our database tier, storage tier, and so on. It should be viewed/considered as the public endpoint of our application.

Figure 4: Azure – Application Gateway Backend pool 1

Figure 5: Azure – Application Gateway Backend pool 2

HTTP Settings:

HTTP Settings helps in validating the request if it is going to the correct backend pool or not. When we are creating a new HTTP Settings, we need to provide input like, Name, protocol, port, if it supports cookie base affinity and custom probe, etc. At the time of healthy instance selection, this information takes a vital role. It is tied up to a custom domain URL and the backend pool. When creating an HTTPS setting — backend certificate is required in “.cer” format.

Figure 6: Azure – Application Gateway HTTP Settings

Rules:
The most important component of the application gateway, which deciding what to do and when. Rules help Application Gateway to route traffic to the correct back-end pool. The rule works as a coordinator/bridge among, Listener, HTTP settings, and Backend pool. It binds all of them in a string. So that every part of Application Gateway can communicate with each other to share required information.

Default Rule: For a listener (Eg: mstech.KJ.com/*) which backend pool should serve the request with the associated HTTP Setting.
Path-Based Routing: Usually used in case of specific requests(Eg: mstech.KJ.com/Image/*). This rule gives us the flexibility to route the request to a specific backend pool based on the routing URL.
Note: One Rule can be associated with one Listener.

Figure 7: Azure – Application Gateway Rules

Figure 7: Azure – Application Gateway Rules 1

Health Probe:

By default, Azure Application Gateway monitors the health of all resources in its back-end pool and automatically removes any resource considered unhealthy from the pool. Application Gateway continues to monitor the unhealthy resources and adds them back to the healthy back-end pool once they become available and respond to health probes.

If there is any specific requirement, we can add a custom health probe otherwise default health proof can be used. If there is no health proof configured for HTTP Settings, then the default health proof will be used. The default health probe is configured automatically with the creation of an application gateway. Health probe reports determine which backed pool instances will receive new flows.

An HTTP/HTTPS request to the back-end server configured for the back-end pool to monitor the health of the servers.

For example: Let’s consider our back-end pull has 3 servers server -1, server-2, and server-3 to receive HTTP network traffic on port 80. The health monitoring tests the three servers every 30 seconds for a healthy HTTP response. A healthy HTTP response has a status code between 200 and 399. If the status code doesn’t fall in between 200 and 399, then the response will be considered unhealthy and the server will be out of pull till it returns a healthy response.

If there is a network security group (NSG) on an application gateway subnet, port ranges 65503-65534 must be opened on the application gateway subnet for inbound traffic. These ports are required for the backend health API to work (Referenced: Official Microsoft Docs)

Figure 8: Azure – Application Gateway Health Probe

Figure 9: Azure – Application Gateway Health Probe 1

SUMMARY

So What I understood here, After traffic is received by Application Gateway, the Listener route the incoming traffic to the healthy instance from the right Backend pool by taking the information from Rule ( Http Setting info) and HTTP Settings (Health prove, cookie-based infinity, protocol, port, etc …). After the application gateway finalizes the backend server, it opens a new TCP session with the backend server based on HTTP settings. HTTP settings specify the protocol, port, and other routing-related settings that are required to establish a new session with the backend server ( From MS Doc). Once a healthy instance of the backend pool receives the traffic, it processes the request and sends back the response in the same way as it came.

Useful Reference: https://docs.microsoft.com/en-in/azure/application-gateway/how-application-gateway-works

I hope this article gives a basic understanding of Application Gateway and In my next article, we will discuss the features provided by Application Gateway. My next article of this series is EP6 – Azure Application Gateway Features.

Thanks for reading 🙂

Keep reading, share your thoughts, experiences. Feel free to contact us to discuss more. If you have any suggestions/feedback/doubts, you are most welcome.

Stay tuned on the blog, will come up with more such articles.

Manas KJ